企业官网建设流程全解析

大厂落地实战！深度拆解飞猪「问一问」架构设计，看大模型如何解决复杂旅行痛点！

我一直在关注大模型在具体业务里的落地形态，飞猪「问一问」这个项目算是国内旅行垂域里比较有参考价值的一个：它不是做了一个简单的 Chatbot 给你闲聊，而是把大模型、知识库、业务工具链、实时数据全部编到了一条完整的链路里。今天这篇不打算复述发布会上的漂亮话，我只想以一个做 AI 应用开发的从业者视角，把「问一问」背后的架构逻辑、核心链路和落地时踩过的那些坑拆开聊一遍。

先说结论：这类旅行问答系统真正难的地方，不是“让模型会说人话”，而是“让模型在正确的时间调用正确的工具、拿到正确的上下文、并给出可执行的答案”。你问“杭州西湖边适合带老人孩子住的酒店，预算 800 以内”，这里既涉及地理语义（西湖边）、人群偏好（老人孩子）、价格约束（800 以内）、实时库存查询，还涉及模糊意图的澄清。任何一个环节掉链子，用户感受到的就是答非所问。

这篇文章适合三类人：正在做垂直领域大模型应用的产品经理或工程师；想了解 RAG、意图识别、Agent 工具调用在真实业务中如何落地的同学；以及单纯对“大厂里面的复杂 AI 系统到底长什么样”感兴趣的读者。我会把架构分层、关键技术选型、以及我从类似项目和公开分享里总结的实操经验全部交代清楚。

1. 问题定义：为什么旅行场景的问答比想象中难得多

1.1 旅行需求的“结构化”与“非结构化”并存

旅行和闲聊式问答最大的区别是：真实旅行需求天然长在一堆约束条件上。用户说“我下周想去成都玩几天”，这句话本身非常模糊——下周是哪几天？一个人还是两个人？想要美食、人文、还是自然风光？预算多少？这些信息如果靠模型直接猜，大概率会给你一个通用攻略，看似合理但毫无落地价值。

飞猪这类平台做问答，面临的第一个架构挑战就是：怎么把用户的碎片化表达，映射成平台内部可执行的结构化字段。你可以把用户的一句话想象成一条 JSON 查询的前身：

• 目的地：成都
• 出行日期：下周（需要结合当前时间推断具体日期）
• 人数：未指定（需要澄清）
• 兴趣偏好：美食（可能从“想吃火锅”这样的表达里抽取）

这不是传统关键词匹配能解决的，因为用户的表达是开放式的。模型必须同时做三件事：理解意图、抽取槽位、识别缺失信息。这也是「问一问」和其他普通 FAQ 机器人的本质分水岭——它要对接的是一套交易系统，而不只是检索一段文案。

1.2 信息时效性：离线知识永远跟不上实时的世界

旅行决策里有一类信息极具时效性：天气、景区限流政策、航班取消、酒店是否满房、当地交通管制。你让模型基于 3 个月前的训练数据回答“明天云南丽江的天气怎么样”，就是瞎蒙。这也是“大模型 + 实时工具调用”在旅行场景里不可回避的原因。

架构上必须分清楚：哪些知识适合预先灌进知识库做成 RAG，哪些知识必须通过 API 实时查询。我在同类项目里的经验是，静态知识（景点介绍、游玩攻略、历史人文）占大概 70%，但用户真正觉得“哇这个回答有用”的时刻，几乎都来自那 30% 的实时信息命中。所以「问一问」这类系统在设计时，从来不是单一模型解决所有问题，而是多路召回 + 模型判别的混合架构。

1.3 决策型回答 vs. 信息型回答

旅行问答里有一种特别微妙的情况：用户问“去三亚还是北海比较好”，表面是信息咨询，实际上是要你帮他做决策。这种问题没有标准答案，但一个好的旅行助手应该能通过追问（“你有几天假期？带不带小朋友？更看重潜水还是美食？”）逐步收敛到个性化推荐。

这直接决定了对话管理模块的设计权重。如果你只做一个单轮检索问答，那用户的体验上限就是一篇攻略；只有把多轮上下文、用户画像、决策树结合起来，才能做真正意义上的“行程规划”。飞猪「问一问」架构里对意图的分类、澄清策略、以及推荐理由生成，实际上都是围绕“决策型回答”来设计的。

2. 整体架构拆解：分层设计如何支撑复杂旅行场景

2.1 接入层：多入口与统一会话管理

先看最外层。「问一问」不是单独一个 H5 页面里的玩具机器人，它嵌在机票、酒店、度假等不同的业务场景里，用户从哪个入口进来，决定了系统初始上下文。比如从酒店详情页进来的用户，大概率是想问这家酒店的具体问题；从首页进来的用户，则可能是完整的需求规划。

架构上需要一层统一的会话管理服务，负责：

• 承接不同端（App/小程序/H5）的对话请求
• 维护会话 ID 与上下文状态
• 将业务入口参数（当前页面的 POI ID、日期、价格）注入到初始 Prompt 中

接入层的核心难点不是 QPS，而是上下文的延续性。用户在酒店页面问了 A 酒店，然后滑到 B 酒店继续问，系统必须知道“这家”指的是 B。这需要会话 id 与业务页面 id 联动，我们内部叫“业务锚点”，是旅行问答区别于通用问答的关键设计。

2.2 智能体编排层：大脑所在的枢纽层

这一层是整个架构的核心，通常被称作 Agent 层或编排层。它的核心职责是把用户输入转换成一系列“行动计划”。我在项目里习惯把这一层拆成四个子模块：

• 意图识别与槽位填充：确定用户是查攻略、查天气、还是订酒店
• 对话状态跟踪（DST）：维护多轮对话的槽位和约束条件
• 策略路由：决定下一步走 RAG 检索、工具调用还是澄清反问
• 结果组装：把多个来源的信息整合成结构化 Reply，交由生成模型输出

飞猪这种量级的平台，编排层不会只用一个大模型裸跑，而是会把轻量任务和复杂任务分流。简单问句走一个快速的意图分类模型；复杂推理和行程规划才走大模型 Agent 链路。这种“快慢分离”的架构能明显降低平均响应时延，也更容易控制成本。

2.3 知识层：RAG 的领域改造

知识层负责供给“模型没学过但必须知道”的信息。旅行知识有两个特点：一是碎片化程度高，二是规则变动频繁（比如景区预约政策说改就改）。所以纯靠向量化文档、做相似度 Top-K 召回，在旅行场景里不够稳。

我观察到的成熟做法是“结构化知识 + 非结构化知识”混合：

• 结构化知识：POI 数据库（景点、酒店、餐厅的属性字段）、交通规则库、价格区间表
• 非结构化知识：攻略文章、游记、官方公告，经过清洗后切片做向量化

召回阶段采用混合召回：向量相似度召回一批、全文关键词召回一批、结构化属性过滤一批，最后通过 rerank 模型打一个综合分。这么做的好处是：当用户问“西湖边有没有不含早餐但允许加床的酒店”，向量召回能抓住语义，结构化过滤能精确卡条件，两者缺一不可。

提示：不要把所有业务数据都塞进向量数据库。向量召回适合长文本的语义匹配，对于强约束条件（价格区间、房型、日期），还是交给结构化查询更稳，否则你会在准确率上付出惨痛代价。

2.4 工具层：把模型从“聊天者”变成“办事员”

如果 RAG 解决的是“知识从哪里来”，那工具调用解决的是“服务怎么完成”。飞猪平台天生有海量业务 API——酒店搜索、机票查询、景点门票、优惠券计算、订单状态查询。

「问一问」架构里，这些 API 会被封装成标准的 Function/Tool Schema，以 JSON Schema 的形式提供给模型。模型不直接调接口，而是产出结构化调用参数，由编排层的执行器去真正的调用业务后端。这层解耦非常重要：模型只负责“决定要调用什么、参数是什么”，实际执行走平台的统一网关和限流熔断。

工具层落地的最大难点是 API 的返回结构非常复杂。一次酒店搜索返回的数据可能有几十个字段，如果全部塞回给生成模型，既浪费 token 又干扰判断。所以必须在工具层做“摘要归一化”，把复杂结果压成精简的、面向用户需求的文本片段，再交给模型组织答案。这个设计做好了，生成的稳定性会上一个台阶。

3. 核心链路详解：从一句话到一份可执行方案的旅程

3.1 意图识别不是分类，而是一个“决策过程”

很多入门项目把意图识别当成一个多分类任务：给一句问话贴个标签，然后走固定流程。但在真实旅行场景里这远远不够。用户说“帮我看看明天北京飞深圳的机票”，他到底是想要航班列表，还是想知道哪个航班最划算？“看看”这个动词在这里携带了比较和推荐的意图。

我把这种识别过程拆成三层：

• 领域识别：订票、酒店、攻略、售后、闲聊
• 动作识别：查询、比价、预订、取消、推荐
• 参数识别：目的地、时间、人数、预算、偏好

传统分类器对这种复合意图很吃力，大模型在少样本条件下反而表现更好。工程上常常把意图识别做成一个基于大模型的 Generation 任务，输出一个标准 JSON，而不是单纯输出一个 label。这就保证了后续槽位填充可以联动进行，减少一次模型调用，也降低延迟。

3.2 多轮对话状态管理：搅碎上下文还是保留压缩？

多轮对话最大的工程陷阱是“什么都要记”。旅行场景里用户会不断修正约束：“把目的地改成杭州”“不对，不是这周，是下周五”“两个人，但有一个是婴儿”。如果对话状态只顾着追加槽位，就会产生冲突——日期到底是哪个日期？人数是两人还是三人？

正确的做法是引入“槽位覆盖 + 冲突检测”。每一轮用户的表达都会触发槽位更新，更新前先做冲突分析：如果新信息与旧信息矛盾，系统需要决定是覆盖、合并还是澄清。这个看似很小的细节，直接决定了多轮对话的用户体感。

另外，上下文窗口是有限的，你不能把整本聊天记录每轮都塞进模型。工程上常用的方案是：

• 用摘要压缩早期会话内容
• 只保留近两到三轮完整原文
• 将已确认的约束（槽位）单独维护成结构化状态

这种“摘要 + 关键轮完整 + 结构化状态”的三级记忆，是我在实践里验证过最稳的多轮方案。

3.3 澄清策略：会追问的系统才是好助手

有一个细节很多团队会忽略：不是所有问题都必须正面回答。当用户的需求充满不确定性时，聪明的系统会反问。比如用户问“推荐一个有特色的酒店”，如果你不追问“是亲子、情侣、还是商务？预算范围呢？”，那推荐出来大概率是错的。

落地澄清策略要考虑两件事：

• 什么时候启动澄清：当置信度低或关键槽位缺失时
• 澄清什么：优先问对决策影响最大的槽位，其次才是补充偏好

飞猪这类平台的澄清文案也很有讲究——它不能像无情的表单工具一样把问题抛出来，而是要在一次回复里既给一个初步候选，又自然地问出缺失信息。这背后往往不是简单的规则模板，而是通过模型针对当前上下文动态生成引导语。好的引导语能让用户的下一步回复更结构化，从而加速槽位收敛。

3.4 检索增强生成：召回、重排、再生成

RAG 虽然已经是老生常谈，但在旅行场景里仍然有几个容易被忽略的细节：

第一，切片策略要“场景化”。通用的按字数切片在这里不够聪明。一个景点的知识文档可能同时包含“游玩时长”“门票政策”“交通方式”“亲子友好度”多维度的信息，如果切片恰好把关键信息拦腰截断，召回效果就很差。我建议先按语义段落切分，再对长段落做重叠切片，重叠量大概在 10%-15%。

第二，重排是必选项，不是可选项。向量检索召回 Top 50 后，如果直接取前 5 个片段进 Prompt，很容易被强相关但老旧的攻略片段带偏。重排模型（跨编码器）能够结合用户的查询和片段做精细匹配，把真正符合“当前约束”的内容挑出来。

第三，引用标注。生成内容一定要附上来源引用——这不仅是为了对用户负责任，还是知识库迭代的抓手。哪条攻略被引用得最多、哪类问题召回总落空，通过引用的打点分析就能持续优化知识库的覆盖度。

4. 工具选型与落地经验：大模型、向量库与评测体系

4.1 模型选型的现实考量

大模型的选择在整个架构里确实重要，但它没有媒体报道里那么玄乎。我见过不少团队花大力气比较各个模型的“文科能力”，最后发现业务瓶颈根本不在模型智力，而在工程链路。

选型时真正要考虑的因素排序：

• 延迟：旅行问答对交互实时性要求高，单轮超过 3 秒用户就明显不耐烦
• 工具调用能力：模型必须稳定输出符合 JSON Schema 的工具参数，这是 Agent 链路的核心
• 上下文长度：要支撑多轮记忆和摘要压缩机制
• 成本：QPS 高的时候，token 消耗直接与账单挂钩

另外，不要指望一个模型吃遍所有任务。我推荐“路由分工”的策略：简单分类、槽位抽取可以用小模型低延迟完成；复杂规划、多步推理才用大模型。这样既保证质量又节约成本。

4.2 向量数据库与检索优化

向量数据库现在选择很多，但核心考察点是可以列出来的：百万级 POI 的召回性能、过滤条件的结合能力（比如向量检索 + 地域过滤同时进行）、以及高可用维护成本。

在检索优化上，我最想强调的一点是“查询改写”。用户的自然语言问句和知识库文档的表达方式往往差异很大。用户问“请问那个玻璃栈道是不是很刺激”，而文档里可能写的是“此景点设有高空玻璃观景平台，惊险指数较高”。如果不做改写，向量相似度会被“刺激”这个抽象词干扰。查询改写模块可以在检索前把问句转换为更适合召回的描述形式，这一做法在很多榜单里看着不起眼，实际提升非常明显。

4.3 评测体系：没有评测就没有迭代

大模型应用上线后最大的难题不是开发，而是“怎么知道每次改动是变好了还是变坏了”。旅行问答的答案是开放式的，人工评测成本高、标准还不统一，所以必须建一套混合评测体系。

我会优先建立三个维度的评测：

• 结构化准确率：槽位抽取是否正确、调用的工具参数是否合理
• 事实一致性：生成的回复是否基于检索到的真实信息，有没有胡编乱造
• 对话成功率：用户是否在一次会话内获得了可执行的答案（酒店链接、行程方案）

实际做法通常是把评测集分成几十个典型场景，每个场景涵盖不同难度的请求，然后每次模型或策略更新后跑一遍回归测试。另外，上线后必须有线上打点回收，监控用户的显式反馈（点踩、追问、跳出）和隐式信号（点击推荐链接、咨询后下单概率）。

提示：建评测集时一定要覆盖“模糊表达”样本，比如“想去暖和点的地方”“适合遛娃的城市”。这些反直觉的抽象说法在旅行问答中占比极高，如果评测集里全是表达规范的问句，系统上线后会很难看。

4.4 上线的渐进式策略

大模型系统切忌“一把梭”全量上线。稳妥的做法是灰度 + 兜底：

• 内部员工体验阶段：验证链路通畅和基础质量
• 小流量白名单阶段：收集真实用户问题和线上表现
• 按业务场景逐步开放：先开放攻略问答，再开放酒店咨询，最后再接入交易链路

每一个阶段都要设置“兜底策略”。例如模型返回置信度过低时，可以回退到 FAQ 检索；工具调用失败时，直接给用户一个带友好提示的“暂未查询到，请稍后再试”或转人工入口。兜底不影响体验高峰，但决定了系统下限。大厂做的产品，安全性下限永远比峰值体验重要。

5. 常见问题与排查技巧实录

5.1 模型进入“复读机模式”，反复要求用户补充信息

在落地澄清策略时，最容易遇到的问题就是模型陷入死循环：用户明明已经给了足够信息，系统还在不停追问“请问您还有其他需求吗？”或者反复重申同一个问题。

排查思路：

• 检查对话状态管理器中的槽位是否会标记“已确认”，如果确认状态没有写入，模型自然以为信息缺失
• 检查澄清触发条件的阈值，如果条件太宽松，模型会把低置信度的正常回答也误判为需要澄清
• 在 Prompt 中增加“如果约束已满足优先给出答案”的指令约束，效果往往是立竿见影的

5.2 工具返回的数据没有被正确利用

模型调了酒店搜索接口，但用户问“有没有泳池”，模型却没看返回数据里的设施字段，直接开始编答案。这一类问题是 Agent 链路里最典型的失败模式。

解决思路有几层：首先，工具的返回摘要里要显式列出关键业务字段，尽量用规整的文本让模型“容易读到”；其次，在生成阶段的 Prompt 里强调“答案只能基于工具返回数据和已检索知识，不得自行补全”；最后，通过评测用例对这类场景做专门验证，一旦发现模型总结链路漏字段，立刻修正摘要模板而非调 Prompt。

5.3 知识库更新了，模型还是引用旧信息

旅行知识的时效性问题在系统上线后会被急剧放大。景区政策这周变了，但用户问的时候模型还在引用上周的知识切片。

有效做法是给知识库打“时效版本号”。每一次批量更新知识库后，将更新区间和影响 POI 列表记录下来。查询阶段如果请求涉及这些 POI，系统优先选择最新版本切片。同时，对于时效性极强的信息（天气、限流通知、航班动态），强制要求走实时工具查询，不给 RAG 抢答的机会——这属于架构级的约束，不依赖模型的自觉。

5.4 用户体验从“怪怪的”到“很专业”的最后一步

最后分享一个从评测数据里总结出来的经验：用户对一次回答好坏的判断，很大程度上不取决于模型推理得多深，而取决于“回答有没有回应我的所有约束”。用户问了“适合带孩子去、有室内泳池、价格五百以内”，一次好的回答要在开头就直接回应这三个点，哪怕是在推荐理由里逐条列出“这家酒店有室内儿童乐园”“泳池是恒温的”“目前价格 480”。

这意味着生成模型输出前，需要一个“约束对齐检查”模块，将用户的槽位和生成答案里的关键实体做对齐比对，发现遗漏时可以触发一次修正生成。这个技巧在很多项目里被低估，却是提升复杂长问句满意度的关键。

6. 从「问一问」看大模型应用落地的底层逻辑

现在市面上关于大模型的讨论，要么过度神话，要么简单地当成聊天机器人。飞猪这类真实业务给出的答案是：大模型的真正价值在于“连接”——连接用户模糊的自然语言和平台庞大的结构化数据与工具服务。

架构上最有借鉴意义的一点，是把模型当作“决策者”而不是“答案机”。系统先通过大模型判断用户的完整意图，再通过路由分发让响应的能力单元（RAG、业务 API、实时数据服务）去各司其职，最后再汇总信息生成人话。这种模式的工程复杂度远高于单模型问答，但它换来的是用户实际问题的解决率，而不是表面上的“机器人在陪你聊天”。

我自己在实践中的体会是，不要先动手写模型代码，而要把业务中真实用户的 1000 条问题从头到尾看一遍。你会惊讶地发现，大部分问题的表象是问句，本质是“你给我一个可执行的方案”。带着这个视角去看架构设计，自然就知道哪些模块必须做扎实：状态管理、工具链路、评测体系。模型本身可以迭代替换，但这三块底盘决定了系统的天花板。

如果现在有人要我做一个新的旅行垂域助手，我会先照着这个骨架搭起来：接入层统一上下文，编排层做快慢分离，知识层做混合召回，工具层做摘要归一化，再配上一套针对模糊表达和复杂约束的评测集。这套组合拳打下来，也许不会像短视频里展示的那样惊艳，但它能稳定地在真实用户流量里活下来。而“活下来”，才是大模型落地的第一步。