做旅游平台的大模型问答系统最怕的不是模型不够聪明而是用户一句话背后藏着一堆没说出口的条件带老人小孩、预算五千、不想太累、下个月初出发……这种需求如果要靠人工客服慢慢盘效率低用户体验也差。某头部旅行平台最近上线的「问一问」智能答疑功能就是冲着这类复杂痛点去的。这篇我来拆一拆它背后的架构设计聊聊大模型到底是怎么在真实生产环境里把旅行问答这件事做扎实的。这次分享主要面向关注大模型落地的工程师、产品经理以及想了解Agent配上RAG这套组合拳怎么在垂直行业落地的人。我会从场景拆解、总体架构、检索改造、评测兜底、工程化取舍到复盘一路讲下来重点说清楚哪些是通用做法、哪些是旅行场景特有的改造。全文没有广告就是一次技术复盘希望能给正在做同类系统的朋友一些参考。1. 旅行问答的复杂度拆解为什么通用大模型直接上会翻车1.1 用户问题里的隐性约束与冲突目标旅行咨询和普通知识问答最大的区别在于用户的一句话里往往藏着大量没有明说的约束条件。比如“帮我规划一下云南七天游”表面上只有目的地和天数但实际可能还包含带着两个老人一个小孩、每天的步行不能太多、预算总共一万五、希望少换酒店、最好有两天海边行程。这些约束如果靠模型自己猜猜错一个整份行程单就废了。更麻烦的是很多需求是互相冲突的。“想玩得轻松一点”和“想把热门景点都走一遍”天然矛盾“预算八千”和“想住海景套房”也不兼容。通用大模型能给出一个看起来合理的答案却很难自己主动追问这些关键约束。它更像一个很博学的朋友而不是一个会做需求分析的旅行顾问。所以我们在设计产品时第一件事就不是堆模型能力而是把“问一问”定义成一个会主动澄清、会用结构化槽位记录需求的系统。每一轮用户表达后系统都要尝试抽取目的地、日期、人数、预算、偏好等关键槽位发现关键槽位缺失时触发反问而不是硬答。这跟对话式CRM、销售线索管理的逻辑很像只不过槽位定义完全围绕旅行场景来设计。1.2 实时性要求政策、价格、库存、天气都在不停变动旅行信息有很强的时效性。用户问“今天杭州到北京的高铁还有没有票”“三亚这两天天气适合下水吗”“这个酒店下周还有没有家庭房”这些都是必须在回答时点实时查询的问题。通用大模型的知识截止时间无法覆盖这些信息它甚至可能根据过时的政策给出误导性回答。我们踩过一个非常典型的坑最开始让模型直接基于Prompt回答签证政策问题模型给出的材料清单和办理时长是准确的但漏掉了“某地新增了一个必须提前预约的环节”这种最新变化。用户照着旧信息去办现场被卡住。从那之后凡是涉及时效性信息一律不走模型记忆必须走工具调用查询后再让大模型整理成自然语言答案。数据源没有返回模型就不能编。1.3 结构化与半结构化数据的规模接入旅行平台背后是大量结构化数据POI信息、航班班次、酒店房型、订单状态、价格日历、景点开放时间。这些数据不可能塞进向量库然后靠相似度检索搞定它们有明确的字段关系、筛选条件和权限边界。举个例子用户问“从上海出发、本周六走、下周一回的机票有哪些”这本质上是一次带条件的数据库查询或API调用。大模型要做的不是直接回答而是把自然语言转成可执行的查询参数交给机票服务查询再把返回结果组织成答案。同时还要处理用户权限某些低价协议价库存不能展示给普通用户某些订单信息只有本人才能看。这就要求问答系统处在一个安全可控的调用链路上而不是让模型自由发挥。1.4 多轮对话中的上下文管理旅行规划天然是多轮对话。用户会先问一个大致方向然后反复追加限制“去年我们去过成都了这次去重庆吧”“火车票有没有没有的话就换成周五晚上出发”“预算从四千加到五千”。如果系统只把聊天记录拼在一起塞给模型模型很容易记混槽位。我们在实践中采用了一种偏传统的对话状态管理方案每一轮用模型抽取槽位抽出来的结果写进结构化状态里再和用户当轮消息一起作为下一步决策的输入。这个状态就是事实来源答案生成只认这个状态。这样做的效果比纯靠大模型“自己记住”要稳定得多也方便我们做错误恢复和人工接管。2. 「问一问」整体架构意图路由、Agent编排与工具层2.1 架构分层入口层、编排层、能力层「问一问」的整体架构可以拆成三层每层都做得不重但边界清晰。第一层是入口层主要负责会话管理、用户身份识别、限流和简单的输入预处理。这一层不调用大模型接到用户消息后先做基础校验然后根据会话状态判断是继续上一次对话还是开启新会话。第二层是编排层核心是意图路由和Agent调度。它要决定当前问题该走哪条路是走轻量级的FAQ检索还是走需要多工具调用的复杂问答还是走到敏感内容兜底。确定走复杂问答后编排层会把任务拆解成多个步骤维护一个待办列表逐步调用工具直到拿到所有必要信息最后交给生成模块产出回答。第三层是能力层统一封装旅行平台内部的各种数据能力和外部信息源。对上层只暴露工具Schema每个工具都有明确的参数定义、调用方式、返回格式。这一层屏蔽了底层系统的异构性让大模型不需要关心某条数据究竟在哪个服务里。2.2 意图路由不是所有问题都要交给大模型做一个大模型产品最忌讳的就是“什么请求都往大模型里塞”。我们统计过线上流量大约有40%的问题是“怎么退改签”“积分怎么用”“某些订单入口在哪”这一类有标准答案的FAQ还有一部分是“你能不能帮我骂一下平台”这种情绪宣泄。这两类问题用大模型来处理既贵又慢还容易让用户觉得指标不稳定。所以我们在入口层和编排层之间放了一个轻量级的意图路由。它用一个小规模分类模型加规则组合把问题分为几大类实时查询类、攻略规划类、订单服务类、FAQ类、闲聊情绪类。分类置信度足够高时才直接走快捷路径置信度低的才送到更大的模型去做更细的判断。对于情绪类和敏感类内容直接走安抚话术和人工客服绝不让它进入复杂Agent流程。2.3 Agent工具集像搭积木一样接第三方能力Agent的能力上限很大程度上取决于工具集的质量。我们第一批接入的工具并不多优先围绕用户高频痛点POI搜索、天气查询、机票/火车票余票查询、酒店房态查询、订单状态查询、退改签政策查询、签证政策查询。每一个工具都定义成JSON Schema模型只需要学会“什么时候调用哪个工具参数填什么”剩下的路由和并发执行交给编排层处理。工具集不是说越多越好。工具一旦超过十几个模型的选择正确率就会下降调用参数也更容易出错。我们当时做了不少取舍砍掉了一些低频且边界模糊的工具比如“附近停车场推荐”“宠物友好场所查询”。这些功能不是没有价值而是模型在长尾场景下判断不准反而拉低了整体准确率。2.4 会话状态与记忆管理前面说过我们把槽位状态放在Agent之外这里展开讲一下。槽位是全局共享的目的地、出发地、出行日期、出行天数、人数、预算区间、同游人群标签、交通偏好、住宿偏好。每轮用户消息进来先做槽位更新更新的结果会反馈给编排层。比如用户改口说“预算加到六千”系统只更新预算槽位行程推荐和酒店筛选的后续逻辑都会基于新预算重新生成。长期记忆则谨慎很多。用户的历史订单和常去城市是可以调用的但涉及个人偏好和社交关系的信息必须在用户明确授权后才能使用而且只能用于当前会话的个性化回答。我们在记忆读取服务外围加了一层脱敏避免把用户订单详情原封不动地注入提示词。毕竟安全合规是底线不能因为追求效果去踩线。3. RAG与知识检索的工程细节混合召回、时效改写与重排3.1 知识库构建攻略、政策、POI信息不能只用一种检索方式很多人一提到RAG就默认“把文档切碎向量化然后相似度召回”。但旅行场景的内容形态非常杂官方政策是强结构化条目用户攻略是长篇自由文本POI描述是半结构化短文本开放时间、联系电话这类信息甚至可能藏在图片里。用单一向量库做召回效果一定不好。我们最终做的是一套混合检索体系。常见问题库用关键词加BM25攻略类内容用向量召回政策类内容用一个简单的知识图谱结构存储POI信息用文本召回加地理围栏过滤。所有召回结果统一进重排模块不提前限定条数。实测下来混合召回的Recall比纯向量检索高出不少尤其是政策条款和带具体地点的查询提升非常明显。3.2 时效性信息先查工具再让模型组织答案RAG并不适合处理所有问题。对于“今天”“现在”“下周”这类强实时需求我们明确不让模型依赖静态知识库而是走工具调用路径。具体策略是先让模型识别出需要实时数据的槽位然后通过工具获取结构化结果最后再把结果转化为自然语言。这个“先查后写”的模式整个链路是可控的。如果用户问“现在杭州西湖人多不多”模型会调用实时客流接口拿到一个数字然后说“目前西湖周边实时客流量约3.2万人属于偏多水平”而不是凭训练数据猜。为了避免模型在拿到实时数据之后还自行脑补我们要求生成模块只能引用工具返回的字段并在系统提示词里明确标注哪些字段可信、哪些字段禁止编造。3.3 查询改写与参数抽取把用户问题变成工具能理解的参数是工程里最容易被低估的环节。很多用户不会用标准地名比如“虹桥附近”到底是指虹桥火车站还是虹桥机场如果不做解析后面所有检索都白搭。我们做了一个独立的地名识别和标准化模块内部维护了一批别名表和父子关系比如“虹桥”会同时关联到“虹桥枢纽”“虹桥火车站”“虹桥机场”再结合用户上下文和POI搜索场景去消歧。参数抽取本身也分两种做法简单的实体识别用小模型或规则复杂意图用大模型Few-shot抽取。我们实际线上跑的是“小模型优先、大模型兜底”的混合策略。既保证大部分高频场景的响应速度又能在长尾表达上兜得住。3.4 重排与上下文压缩召回和重排是两个环节但在产品上经常被混为一谈。我们在检索后会有一个重排层综合文本相关度、信息时效性、来源可信度、用户画像匹配度几个维度打分。比如同一份攻略两周前更新过且携带“亲子”标签面对带孩子的用户时它的排序权重就会更高。重排之后还有一个被很多人忽略的上下文压缩。知识库检索出来的片段往往又长又杂直接全塞给大模型既浪费token又把关键信息淹没掉。我们会根据用户问题对Top片段做一次裁剪只保留命中关键词的句子和段落再把结构化数据精简成摘要。这样模型回答时更容易命中要点也不会被无关信息带偏。4. 生产环境的评测与兜底如何保证答案“靠谱”4.1 评测集按场景分类、按错误类型分层大模型问答系统最容易被怼的一句话是“离线评测一堆好看的数字上线就拉胯”。我们的经验是评测集不能只看总体准确率必须按场景和错误类型分层。所以团队把评测集拆成六个维度实时信息准确率、知识性问答准确率、推荐合理性、多轮状态跟踪率、安全合规率、回复友好度。每一维都有各自的评分标准。比如实时信息准确率要求模型必须正确触发工具调用且返回内容与结构化结果一致推荐合理性则更多看候选排序是否匹配用户隐性约束。评测集本身也分离线集和线上回流集。离线集是提前标注好的标准用例线上回流集则来自每天真实用户会话的脱敏采样。每次模型更新都要在这两套集子上同时跑分任何一个维度的指标下降都不能发布。4.2 客观性约束用结构化校验卡住模型幻觉大模型的幻觉问题在旅行场景里会直接变成订单投诉所以必须在生成链路里加一道客观性校验。我们对两类输出做了硬性约束。一类是数字信息输出比如价格、里程、评分、余票数模型不能生成一个不在工具返回结果里的数字。另一类是策略性输出比如退改签规则、签证材料要求必须引用权威数据源ID。如果生成模型试图输出这些信息但没有引用来源校验服务会直接拒绝并把问题转给人工。这套约束本质上是用代码逻辑给模型画了一条安全线效果立竿见影。上线后涉及价格和政策的回答90%以上的错误都能在线上被拦截。4.3 兜底策略不知道就承认不知道不能硬编再好的模型和检索也有覆盖不到的问题。早期系统一遇到没见过的表达就强行给一个“有可能”“大概”的模糊答案用户看了很焦虑不点取消也会不信任。后来我们明确改成了“低置信度就主动承认”。系统判断回答置信度低于阈值时会直接回复“这个问题我暂时无法准确回答需要转给人工客服”同时把用户会话内容和初步分析结果一并发给客服工作台。这样做的好处是用户体验反而比收到一个假答案要好得多。客服也能更快切入不用从头问一遍。5. 成本、延迟与稳定性大模型落地的工程化取舍5.1 延迟拆解一次复杂问答会跑几次模型推理用户感知到的延迟主要由整条Agent链路决定。一次复杂问答可能要经过意图路由、参数抽取、工具调用、答案生成四步其中每一步都可能触发模型推理。尤其是工具调用需要多轮反馈时延迟会成倍上升。我们做了三个优化。第一意图路由和参数抽取尽量并行不串行等待。第二工具调用阶段在模型规划好步骤后把能并发执行的工具一次全发出去而不是一个个排队。第三答案生成用流式输出首字返回时间压到1秒以内用户感知到“开始打字”后等待焦虑会明显降低。这三件事做完端到端平均延迟下降了接近一半。5.2 模型路由与降级贵的模型不要用在不值得的地方大模型不是越贵越好而是越合适越好。我们把模型使用分成三档简单FAQ和闲聊用7B级小模型知识性问答和单轮工具调用用百亿级模型复杂多轮规划、需要强推理的才动用更大规模模型。同时做了降级策略。当大规模模型服务超时或返回异常时系统会自动把请求降级到小模型加模板方案。紧急情况下甚至可以降级为纯检索式答案保证用户不会长时间等不到回复。牺牲一点效果但把可用性撑住了这在活动大促流量冲击时特别关键。5.3 成本控制缓存、蒸馏与按需调用大模型成本控制是长期工程。我们主要做了三件事。第一是缓存。高频问题、热门攻略问答可以有很高的缓存命中率我们按城市、日期、用户群组做了一层结果缓存很多雷同问题根本不用再调用模型。第二是蒸馏。从线上日志里把优质Agent路径收集起来清洗后用来微调一个规模小一级的模型让它学会直接走高频路线减少对大规模模型的依赖。这个效果是逐步累积的越跑越省。第三是按需调用。不是每个回答都需要全部工具数据我们会在规划阶段给工具调用附一个必要性阈值非必要信息不查、不生成。6. 落地复盘三个让我印象最深的坑6.1 坑一用户问题根本不是你以为的样子我们早期收到一条用户反馈是“去三亚玩一周要多少钱”系统回答了一个总价区间结果用户很不满。后来拉日志看对话才明白用户想知道的是“如果一家四口去包含机票、酒店、吃饭、景点每一项分别多少钱”他需要的是预算明细而不是一个总的估算数。这个case让我们反思自然语言理解不能只看表面字词还要理解用户提问背后的决策任务。从那以后我们对“报价类”问题统一拆分成“交通住宿活动餐饮”四个维度再按人数和天数重新组合满足率提升了不少。6.2 坑二工具一多模型就开始乱调有一段时间我们把工具数量从8个加到15个本意是覆盖更多问题结果线上错误率反而升高。模型会在POI搜索和攻略检索之间犹豫不决也会把“天气查询”和“出行建议工具”混在一起甚至出现重复调用同一个工具好几次的循环。最后我们不得不给每轮Agent任务设一个工具调用上限超过三次就强制收敛并增加参数校验非法参数直接重试或降级。经验是工具集要克制多不等于强模型的选择准确率才是第一位的。6.3 坑三离线评测全过线上被用户打脸离线评测集最怕分布偏差。我们的标准用例大多是编辑和运营同学写的表达规范、意图明确。真实用户里却有大量口语化、带错别字、信息来源不完整的问题。第一次做小流量灰度时离线F1很高线上满意度却难看。后来我们专门建了“真实日志回流”机制每天从已脱敏的用户会话里抽取500条真实问题人工标注后加入评测集持续迭代模型和槽位定义。之后每次上线前都要先看这批真实回流样本的指标。这套机制不能根治所有问题但至少让模型的能力短板越来越暴露在可控范围内。最后整个项目走下来我最大的感受是大模型在这个系统里更像是一个“会说话的调度员”真正扛事的是它背后的工具链路、检索体系和校验体系。纯靠模型记忆回答旅行问题既不可控也不可持续。如果现在让我从零再做一次我会更早地建立评测回流闭环更早地设计工具调用上限和降级策略也会更克制地挑选Agent工具集。架构设计不是一步到位的事但提前把成本、延迟、安全这些约束想清楚后面会少走很多弯路。也希望这篇拆解能给准备做垂直行业大模型应用的朋友带来一点启发。