7000字长文解读AI大模型智能旅游规划项目方案

当大模型遇上旅行规划，一场关于精准与效率的战役正式打响。本文深度拆解对话式AI行程规划产品的核心流程，揭秘多模态意图识别、行程框架生成等关键环节中，大模型与传统算法的黄金分割点。从提示词设计到模型评估体系，手把手教你打造一个听得懂、问得准、规划稳的AI旅伴。

上一篇文章，和大家聊了一下这个项目，做了一个整体性的复盘，但主要是以业务和团队等方面说的，但是实现方案和大模型相关评估上，说的不多，这篇文章，我们就在产品实现方案和大模型这块来聊一下。

这个项目主要是让用户通过对话，利用大模型来实现旅行行程规划。

一、整体流程

核心的流程：收集用户意图 → 行程框架规划 → 每日景点规划 → 行程路径规划→ 结果展示

详细流程图如下所示。

我们将流程更详细的说一下，这样大家对项目逻辑和作用，之后在哪些环节使用大模型，哪些环节不使用大模型就会更请清楚。

1.1 信息收集

首先我们需要收集用户的旅行规划相关信息，有了这些信息，才能作为大模型的输入。

输入的方式提供了三种模式：

a、快捷输入方式——每个快捷方式预设提示词，比如说周末周边游，预设情侣一男一女，获取定位确定地区，不出省内，2天1夜，休闲，价格适中，自驾出行

b、通过文字、语音、图片——在对话显示框中给出提示词，提示用户提供必要的信息

c、长途旅行——模版信息填写提交，让用户填写必要的信息，然后提交

1.2 信息判断

用户填写信息之后，对于快捷方式和长途旅行的模版信息，都是有标准信息的，基本可以进入旅行规划，但是针对用户输入框输入的需要做两件事情

a、判断用户信息是不是旅游相关及与旅行规划相关，如果不是，则需要提醒用户

b、用户输入的信息是否满足规划所需的最低信息

1.3 旅游行程宏观规划

当我们收集到用户的旅行相关意图信息并且判断符合规划启动条件时，就开始规划整个行程的宏观内容，也就是整个行程总的天数，哪些地区，行程包含哪些类型的景点等

1.4 旅游行程微观规划

在宏观规划之后，进一步的规划每一天的行程，包括吃、住、行、玩的各方面。

进一步将这些元素进行按照时间从早到晚进行组合，规划路径，提供进一步的行程建议。

1.5 结果展示

最终，我们将宏观规划和微观规划的行程，打包之后组合成一个完整的行程，然后按照一个固定的展示框架输出给前端进行展示。

二、业务流程中大模型与传统编程的使用取舍

上面我们较为详细的说了一下整个的流程，现在我们进一步讨论，这整个业务流程中，哪些选择使用大模型来处理，哪些还是使用传统的方式来处理，以及为什么这么做。

2.1 信息收集

这个环节中，涉及到用户通过输入框来输入信息，里面有语音及图片方式，需要模型来解析用户的语音及图片，这涉及多模态的理解，用户意图的提取，这里是必须要用到大模型的。

2.2 信息判断

需要判断用户的输入信息是不是旅游相关信息，如果不是，需要提醒用户聊跟旅游相关的，用户问了旅行相关信息，则回复用户，比如最近哪里适合旅游。

并且进一步判断，用户输入的信息是否和旅行规划信息相关，是否满足出发旅行规划的最少参数。

如果判断用户输入的信息不足，则需要对用户进行追问，提醒用户还确实哪些信息。以上这些都是需要大模型来处理。

2.3 旅游行程：宏观规划

当识别到用户旅行规划信息已满足规划需求时，则将相关信息和预设的旅行规划提示词作为输入，给到大模型，由大模型进行规划，给出整个行程的基调。

2.4 旅游行程：微观规划

根据宏观规划中整体的方向+每一天的行程重点+限制条件（比如当日景点数+单日经费标准）作为输入，让大模型规划每日行程，包含早中晚餐食，景点。

以上部分采用大模型来规划，以下部分则采用固定算法处理。

为了达到让行程的景点数据为可用数据，则将行程景点在大模型规划的时候多规划一些作为冗余，然后再对接三方API数据进行查询，将不可用的景点剔除，对剩下的按照最优路径法从早餐店开始规划直到入驻酒店。

如果无效景点数据过多，则需要重复大模型规划进行补齐。

2.5 结果展示

规划完成之后，还需要做一些补充，比如将从第三方获取的景点信息等，再让大模型进行一些加工，提炼景点的一些特色信息，简介等方便给用户做出更标准的展示。

最终将整个方案，按照固定逻辑展示给用户端，这里不是让大模型直接输出展示，也不是让大模型来生成每次的界面，而是使用传统前端控制的方式来处理。

2.6 各个流程节点总结

以下是各个流程节点涉及模型及其作用

三、业务节点评估维度

通过以上每个节点中涉及的大模型，我们进一步讨论，怎样评估哪个环节使用哪个大模型，又如何设计评估维度、指标、测试集等让最终应用达到一个好的效果。

3.1 信息收集

用户说话可能乱糟糟的：打字、发语音、甚至发一张照片。模型第一件事就是搞明白用户到底想去哪、玩几天、和谁去、花多少钱。

字段准确率：用户说“五一去西安3天”，模型必须听出“西安”和“3天”。要是把“西安”听成“西藏”，后面全白干。这是最基础的。

偏好召回率：用户说“我喜欢历史，也爱吃小吃”，模型漏掉“爱吃”的话，推荐的行程可能全是博物馆，没有美食街。用户会觉得“你没听懂我”。

多模态识别准确率：用户发一张海边照片说“想去这儿”，模型得认出这是三亚。或者发语音说“去成都”，得转成文字。这个指标看模型能不能处理“非打字”的输入。

3.2 信息判断

用户经常只说一半，比如“想去成都”。模型不能瞎编，得知道还缺什么，然后礼貌地问。

缺失字段识别率：用户没说玩几天，模型得知道“缺的是天数”，而不是去问“您喜欢什么景点”。

• 追问相关性：缺天数就问“您打算玩几天？”；别缺天数却问“您预算多少？”——跑题了。这个指标看模型问的是不是缺的那个东西。
• 追问简洁性：一次问太多问题，用户烦；一次问太少，来回好多轮。最好一次问1-2个。这个指标看模型会不会“话痨”。
• 多轮对话效率：从用户说“想去重庆”到模型把目的地、天数、人数、预算都问清楚，平均要聊几轮？轮数越少，用户越爽。

用户可能会问“今天天气怎么样”甚至不礼貌的问题。AI旅伴只做旅游，不该答的要拒绝，但拒绝后要引导回来。

• 拒答准确率：用户问“怎么写Python”，模型不能说“我推荐你去颐和园”。要直接说“我只懂旅游哦”。这个指标看模型能不能分清边界。
• 误拦率：用户问“去西安穿什么衣服”，这是旅游问题，不能拒答。误拦率就是看模型有没有错杀好人。
• 引导有效性：拒绝后不能冷冰冰结束，要说“你可以继续问我行程问题”。这个指标看模型会不会把用户拉回正题。

3.3 旅游行程：宏观规划

用户不想一上来就看每天几点去哪，太晕。模型应该先给个整体概览：主要去哪些区域、大概花多少钱、行程松还是紧。

• 区域划分准确性：去西安，模型说“主要玩古城、曲江和临潼”，这靠谱；如果说“主要去高新区逛街”，那就错了。区域对了，后面才不会跑偏。
• 景点类型匹配度：用户喜欢自然风光，模型说“主要看博物馆和寺庙”，类型就不对。这个指标看模型有没有抓住用户爱好的大方向。
• 预算估算误差：用户预算5000，模型估2000，后面用户看到真实价格会骂你。误差别超过20%，这是信任问题。
• 整体节奏合理性：带老人小孩，模型说“每天暴走3万步”就找死。这个指标看模型会不会根据人群和天数调整松紧。

3.4 旅游行程：微观规划

用户确认概览后，模型给出每天几点去哪、怎么去、吃什么、住哪。必须真实可行，不能坑人。

• 时间可行性：一天所有景点玩下来加上坐车时间超过10小时，用户根本走不完。这是硬杠杠。
• 地理可行性：两个相邻景点坐车超过1小时（市内），用户半天浪费在路上。要顺路。
• 营业时间匹配：推荐晚上8点去下午5点关门的博物馆，用户白跑。这个指标看时间对不对。
• 顺序合理性：把距离远的两个排一起，而不是顺路排，用户多走冤枉路。这个指标看路线顺不顺。
• 节奏合理性：一天塞8个景点累死，一天只1个景点又亏。3-5个比较合适。太密太松都不好。
• 偏好匹配度：用户喜欢历史，却推荐一堆游乐园，那就是没听进去。这个指标看个性化够不够。
• 预算匹配度：用户选经济型，你推荐五星酒店，预算超了。要符合用户说的档次。
• 信息丰富度：只给景点不给交通、酒店、美食，用户还得自己查。这个指标看方案是不是“一条龙”。
• 宏观-微观一致性：宏观说“主要玩古城”，微观第一天却跑去新区。用户会觉得你前后矛盾，不靠谱。

3.5 结果展示

对于三方返回的景点数据，有时候过多，无法再用户端完全展示，需要大模型给进一步提炼出特色标签，对内容进行精炼。

3.6 通用指标

这些不针对某个环节，而是看整个产品快不快、稳不稳、安不安全、贵不贵。

• 时间效率：用户从提交到看到完整行程，总共等多久？超过10秒就悬了，超过15秒可能流失。分段计时可以定位哪个环节慢。
• 鲁棒性：用户会打错字、说一半、中途改主意、前后矛盾。模型要能扛得住这些“脏话”，否则真实场景没法用。
• 安全：绝对不能推荐危险活动（如半夜爬野山），绝对不能泄露用户手机号、住址。这是红线，零容忍。
• 成本：每调用一次模型都花钱。如果一次行程花太多钱，用户量大时公司亏本。要控制在合理范围。

四、测试集与提示词设计

4.1 测试集设计

我们上面已经针对各个业务流程节点中用到大模型的地方设计了评估维度和指标，然后我们针对每个节点的业务情况，设计测试题，大致标准如下，具体题目就不展示了。

• 分阶段：先测听懂，再测规划大方向，再测每日细节，最后测抗干扰能力。哪一关过不了，都知道问题出在哪。
• 贴近真实：测试用例来自真实用户行为（语音、图片、信息不全、中途改主意），不是出题老师编的完美案例。
• 全面：模拟每个节点可能出现的各种场景，样本量保持充足。不只测模型“聪不聪明”，还测它“会不会聊天、会不会追问、会不会拒绝、会不会展示”。

这套测试就像AI旅伴的“驾照考试”——科目一考交规（听懂意图），科目二考倒库（追缺失信息），科目三考路考（宏观+微观规划），科目四考文明驾驶（拒答非旅游问题）。全部通过，才能放心让用户上路用。

4.2 提示词设计

4.2.1 AI旅游项目的提示词设计概述

以下是对 AI 旅伴项目各节点提示词设计的概述，聚焦于“为什么这样设计、设计时怎么想、用了什么方法”，不包含具体提示词内容。

4.2.2提示词的设计原理

角色锚定

给模型一个明确的身份（如“意图提取员”“行程规划师”）。原理是：大模型在预训练中见过大量不同角色的对话，指定角色能让它调用对应语境下的语言风格和推理模式，减少跑偏。

格式约束

强制要求输出 JSON 或固定字段。原理是：模型生成自由度越高，越容易出现格式混乱。结构化约束相当于给它一个“填空模板”，大幅降低解析难度和出错率。

Few-shot 示例

给 2-3 个“输入→正确输出”的例子。原理是：大模型本质是 next token prediction，示例相当于隐式地教会它映射规则，比单纯用文字描述“你该怎么做”更直接、更稳定。

分步思考（Chain-of-Thought）

让模型先输出中间步骤（如预算估算：先算住宿、再算餐饮…再求和）。原理是：复杂推理任务中，一步到位容易出错，分解成小步骤能降低错误率，而且中间结果可解释、可调试。

负面约束

明确告诉模型“不要做 X”（如“不要编造信息”“不要输出天气”）。原理是：模型有时会自作聪明补充无关内容，明确禁止能有效切断这种倾向。

4.2.3 实际案例

以下是第二个节点，也就是查找用户信息是否遗漏的节点的提示词初版，后期可以根据效果继续调优提示词。

你是一个旅行规划助手的对话管理器。你的任务是检查用户已提供的旅行信息是否完整，并生成友好的追问。
必填字段：destination（目的地），duration_days（天数），travelers（人群）。
推荐字段：，budget（预算），preferences（偏好）。
规则：
1. 如果缺少必填字段，必须追问。一次最多问2个问题。
2. 如果只缺少推荐字段，可以追问（一次一个），也可以跳过（如果用户已多次忽略或明确拒绝）。
3. 用自然、友好的语气，不要使用技术术语。
4. 如果必填字段齐全且至少有一个推荐字段（或用户明确表示无更多需求），输出“信息完整，可以规划”。
5. 不要输出JSON、代码块或额外解释，只输出追问语句或确认语句。
6. 结合对话历史时，先更新用户已提供的字段，避免重复追问。
以下示例供参考：
输入：{“destination”: null, “duration_days”: 3} → 输出：您计划去哪个城市呢？
输入：{“destination”: “北京”, “duration_days”: null} → 输出：这次旅行打算玩几天？
输入：{“destination”: “上海”, “duration_days”: 2, “travelers”: null, “budget”: null} → 输出：方便告诉我您是独自旅行还是结伴？大概预算多少？
输入：{“destination”: “成都”, “duration_days”: 3, “travelers”: “solo”, “budget”: “economy”} → 输出：信息完整，可以规划。
注意事项：
– 不要重复问用户已经回答过的问题。
– 如果用户明确表示不想提供某个信息（如“预算无所谓”），则跳过该字段。
– 一次最多问2个问题，语气亲切。

五、模型选择与调优

5.1 模型厂商选择

因为没有自己部署模型，所以直接选择云服务器厂商提供的模型。市面上的模型服务厂商也比较多，可以做个选择。现在很多厂商都通过了测试赠送的token，前期测试评估这些token完全够用。

评估维度（加权打分，权重分可以根据自己的情况调整）：

• 模型能力（40%）：用你的意图提取、宏观规划测试集跑分+人工评分。
• 成本（20%）：按token单价×预估行程消耗计算。
• 延迟（15%）：P95响应时间、首token时间。
• 稳定性（10%）：API可用性、错误率、限流策略。
• 易用性（5%）：SDK、文档、参数调节。
• 合规（10%）：数据是否出境、隐私协议。

评估步骤：

选3-4家候选（如阿里云、腾讯云、百度云、华为云）。

用统一测试集和简单提示词，批量调用各模型，计算自动化指标并抽样人工评分。

记录token消耗、延迟、错误率。

加权计算综合得分，确定主选和备选厂商。

5.2 单节点评估

目的：使用你的 初版提示词 + 主模型，在完整的测试集上评估每个节点的达标情况，定位瓶颈。

a、将主模型和初版提示词分别配置到 7 个节点（有些节点可共用模型，但 prompt 分开）

b、依次运行每个节点的专用测试集（如意图测试集、宏观测试集、微观测试集等）

c、用自动化评估脚本计算每个节点的核心指标（参照之前的指标设计表）

d、对未达标的节点（指标低于通过标准）进行 bad case 分析，根因分类（是提示词不足还是模型能力不足）

e、评估各个节点的问题，

最终经过单节点的评估，我们可以明确指出哪个节点、哪个指标不达标，以及可能的原因（提示词 vs 模型）。

5.3 提示词+模型联合优化（迭代循环）

目的：针对不达标的节点，通过修改提示词、更换模型、增加后处理等方式，使指标达到通过标准。

原则：

优先改提示词（成本最低，见效最快）。

其次换模型（如果同一节点尝试 3 轮提示词优化后仍不达标，考虑换更强的模型或专用模型）。

最后加后处理规则（模型无法完美解决的，用确定性代码兜底）。

详细操作步骤如下：

将优化后的各节点串联起来，模拟真实用户流程，确保整体业务达标，并准备上线。

六、业务模型评估调优遵循的规范原则

可重复性原则

所有评估（测试集、脚本、模型版本、提示词版本）必须固化，确保任何人可以复现结果。

隔离原则

每个节点的评估独立进行，避免因上游节点错误导致下游指标虚低。端到端测试使用完整流程，但单节点评估使用标准化的输入（不依赖上游模型的输出，而是用标注好的输入直接喂给该节点）。

渐进原则

先离线，后在线；先小流量，后全量。每个改动（换模型、改提示词）必须先在离线测试集上验证，再上线小流量。

成本意识原则

记录每次评估的 token 消耗和 API 费用，防止评估成本失控。在离线评估阶段，可使用小模型（如蒸馏版本）跑中间指标，仅当需要准确结果时再用大模型。

人工复核原则

自动化指标不能完全替代人工判断。每个评估阶段结束后，必须抽样人工复核至少 20 条 bad case 和 10 条 good case。

回滚原则

始终保留上一个稳定版本的模型+提示词。线上出现问题时，能在 5 分钟内回滚。

七、业务模型评估调优常见问题复盘

7.1 单节点达标，但端到端体验差

原因分析

每个节点独立评估时，输入都是标准化、理想化的（例如节点5的输入是人工标注的完美宏观规划），但实际端到端中，上游节点的输出可能存在微小偏差（如意图提取漏了一个偏好），这些偏差在下游节点被放大，导致最终行程不合理。

节点之间缺少契约校验：下游节点假设上游输出一定符合某种格式或取值范围，但实际输出可能超出预期（如“预算”字段输出“中等”，但下游期望的是“标准水平”）。

解决方案：

• 增加中间结果校验层：在每个节点输出后，用轻量级规则检查输出的合法性。
• 建立端到端集成测试集：准备 50~100 条真实用户完整对话（从开始到结束），人工标注最终期望的行程。
• 引入端到端追踪：在日志中记录每个节点的输入输出 ID，当最终输出不达标时，能快速定位是哪个节点的输出导致了问题。例如，用户反馈“行程太赶”，可以回溯到微观规划节点，查看其输入（宏观规划）是否节奏合理。

7.2 模型输出时好时坏

原因分析

大模型本质是概率模型，即使 temperature=0，由于浮点运算的非确定性、批处理顺序、甚至硬件差异，输出仍可能微小波动。但在某些关键点上（如预算数字、景点名称），微小波动就会导致结果有时正确有时错误。

提示词中的约束不够强，模型在某些情况下会“自由发挥”。

解决方案

• 固定随机种子和参数：在 API 调用中明确设置 temperature=0、top_p=1.0
• 强化提示词约束：在提示词中明确要求“输出必须确定，不要有多种可能性”。例如：“对于同一个输入，无论调用多少次，你的输出应该完全一致。”

7.3 成本超预期

原因分析

初步评估时使用的测试集较短，未考虑实际对话中的多轮交互（每轮都会调用模型）。

解决方案

• 缓存重复请求：许多用户的输入类似（如“北京三日游”），可以对相同的输入（标准化后）缓存模型输出，直接返回。
• 采用混合模型策略：简单节点（意图提取、信息完整性判断、非旅游过滤）使用更便宜、更快的模型
• 压缩输出 token：微观规划中，要求模型只输出必要字段，去掉冗长的描述（如景点历史故事）。

7.4 模型更新导致效果下降

原因分析

云厂商会不定期升级模型版本（如从 qwen-max-2024-12 升级到 2025-03 版），新版本可能在推理风格、输出格式上变化，导致调优的提示词不兼容。

模型更新可能修复了一些问题，但引入新的 bug（例如对中文地名的识别变差）。

解决方案

• 锁定模型版本：大多数模型厂商允许指定模型版本（如 qwen-max-2024-12-31），在 API 调用中明确写上具体版本号，除非测试验证有更好的模型，否则不轻易变更模型。
• 更换模型测试要全面完整：运行全量测试集，对比关键指标（字段准确率、预算误差等）与基线（上一次通过的版本），充分全面评估新模型的能力是否有提升，是否有关键指标的下降。
• 灰度升级新模型：不要直接全量切换到新模型版本。先在生产环境用少量流量尝试新版本，观测 几 天，对比旧版本的用户点踩率、规划完成率等。如果表现持平或更好，再逐步扩大流量。
• 准备回滚预案：在代码中保留使用旧模型版本的配置开关。一旦发现新模型导致问题，能快速切换回旧版本。