基于 Qwen2.5 + RLHF + RAG 的智能旅游规划智能体

想象一下：你在手机上打开一个聊天窗口，随口说"春节去云南7天，想去大理和丽江，孩子6岁"，几秒钟后，系统不仅给出了一份完整的行程规划——每天几点去哪儿、吃什么、住哪里——还顺带规划好了景点间的最优路线、查好了机票和酒店价格，甚至用一张思维导图把所有信息可视化呈现出来。

这不是科幻，而是 NJUxlj/Travel-Agent-based-on-Qwen2-RLHF 正在做的事。

项目背景：一个研究生的"AI旅行梦"

这个项目来自南京大学的一位研究生，他想做一件很有意思的事：让普通人在本地就能用轻量级大模型规划出一流的旅行体验。

旅行规划是一个天然的复杂决策场景：用户需求模糊（"我想放松一点"），涉及多源信息整合（景点、天气、交通、住宿），还需要在多种选项中权衡取舍——这恰好是 AI Agent 最适合介入的任务。

项目的核心挑战在于：旅行知识具有极强的时效性和地域性，通用大模型的参数知识无法覆盖所有景区的实时营业状态和个性化偏好。而 RAG（检索增强生成）正是解决这个问题的关键技术。

技术架构：四层"积木"搭起的旅行助手

第一层：Qwen2.5 基座模型

项目选用阿里巴巴通义千问团队发布的 Qwen2.5-0.5B 到 3B 系列作为基座。这个选择非常务实——相比 GPT-4 等超大模型，Qwen2.5 的小参数版本可以在消费级 GPU（RTX 3090）上运行，降低了普通用户的部署门槛，同时保持了足够强的语言理解和推理能力。

基座模型负责理解用户意图、生成自然语言响应，并调用下层的工具链。

第二层：SFT + RLHF 微调系统

仅有基座模型还不够。旅行场景要求模型严格按照工具格式输出调用指令，不能随意编造景点信息或价格数据。为此项目实现了完整的 RLHF（人类反馈强化学习）训练流程：

• SFT（监督微调）：使用 JasleenSingh91/travel-QA 数据集，让模型学习旅行领域的问答模式
• PPO（近端策略优化）：通过 reward 模型对生成内容打分，优化策略网络
• DPO（直接偏好优化）：利用 HumanLLMs/Human-Like-DPO-Dataset，让模型学会区分高质量和低质量回答
• GRPO（群体相对策略优化）：一种新型的强化学习算法，用于提升模型的工具调用准确性

项目将四种训练器统一封装在 src/finetune/ 目录下，使用 HuggingFace 的 TRL 库和 DeepSpeed 进行分布式训练，配置文件参考 ds_config.json 实现 ZeRO-3 优化。

第三层：RAG 知识增强系统

这是项目最有技术含量的部分——一套三合一 RAG 调度器，支持三种检索策略：

传统 RAG（Naive RAG）：基于 ChromaDB 向量数据库和 BM25 关键词检索，使用 LangChain 框架实现完整流程：文档切分（chunking）→ 向量化（embedding）→ 相似度检索 → 上下文注入。这种方式简单直接，适合结构化的旅游攻略文档。

Self-RAG（自适应反思 RAG）：这是最接近工业级应用的方案。核心思想是让模型自己决定"需不需要查资料"。模型在生成过程中会输出特殊的 [Retrieval] 标记——如果它认为当前回答需要外部知识支撑，就会主动触发检索。检索回来的内容还会经过三层反思标记评估：

• [IS_REL]：检索内容与问题是否相关？
• [IS_SUP]：检索内容是否支持模型自己的回答？
• [IS_COM]：最终回答是否完整？

只有通过所有评估的答案才会被输出。这是一个真正的"批判性思考"流程。

MemWalker（记忆树导航 RAG）：针对长文本（如完整旅游攻略PDF）的深度检索方案。它不追求一次性找到答案，而是构建一棵"记忆树"：将长文档切分为多个段落，每个段落生成摘要节点，摘要再聚合成更高层的父节点。查询时，模型从根节点开始，逐层向下"走"，遇到判断为不相关的分支就回溯（通过输出 action=-1/-2/0），最终到达包含答案的叶节点。

三种策略由 RAGDispatcher 统一调度，用户可以根据场景灵活切换。

第四层：工具调用系统（Tool-Use）

模型理解了用户问题、有了知识储备之后，还需要真正帮用户做事。项目实现了完整的工具调用管道：

• PromptTemplate：定义了包含 query、context、工具列表的提示模板，让模型按规范输出工具调用指令
• ToolDispatcher：解析模型输出的工具函数字符串
• ToolExecutor：实际调用外部 API——Google 搜索、天气预报、酒店预订、机票查询、最短路径计算

此外还有 ChatPDF 功能，用户可以直接上传一份旅游手册 PDF，系统自动从中提取相关信息。

上手体验：Gradio Web UI

项目提供了基于 Gradio 的 Web 界面（src/ui/ 或 app.py），用户可以在浏览器中直接与 Agent 对话。README 中提到，模型输出可以附带一张思维导图（mindmap），将行程规划以可视化方式呈现——这个设计对旅行规划场景非常友好。

需要注意的是，完整的训练环境需要多卡 GPU（RTX 3090 x 2），部署门槛不低。但如果只是想体验推理过程（使用已微调好的模型），单卡应该可以胜任。

代码质量评估

项目代码组织清晰，模块化做得不错：

• src/agents/：多种 Agent 范式实现（MCTS、ReACT、单步规划）
• src/rag/：三种 RAG 方法独立封装
• src/finetune/：四种 RLHF 训练器
• src/tools/：工具调用基础设施
• src/embedding/、src/chunking/：RAG 数据处理管道

README 中提到 2026 年 4 月进行了一次全面代码审查与修复，共修复 26 个问题，涵盖训练器参数误用、RAG 实现逻辑、安全漏洞（tool_executor 中的 eval 调用风险）等，说明作者有一定的维护意识。

不过项目没有 License（license 字段为 null），使用前需注意。项目也不包含测试文件，代码质量分数保守估计在 70-75 分。

局限与挑战

1. 训练数据依赖：SFT 数据集 JasleenSings91/travel-QA 的质量直接影响模型效果；DPO/GRPO 数据集使用的是通用"类人回答"数据集，并非专门针对旅行场景的偏好数据，可能会引入噪声。

2. 工具 API 依赖：项目中集成的 Google Search、天气 API、酒店/机票 API 均依赖外部服务，在实际部署时需要配置有效的 API Key，且部分工具可能存在访问限制。

3. 向量数据库运维：RAG 系统依赖 Milvus（通过 langchain_milvus）和 ChromaDB，需要额外的数据库部署和索引维护工作。

4. 无 License：这对商业化使用构成障碍，不建议直接用于商业产品。

行业意义

这个项目的价值不仅在于旅行场景本身，更在于它展示了一套可复用的 LLM Agent 技术栈：Qwen2.5 基座 → LoRA 微调 → RLHF 对齐 → 多策略 RAG → 工具调用 → Gradio UI。这套架构可以迁移到法律咨询、医疗问答、金融分析等垂直领域。

从趋势来看，"小模型 + RAG + 工具调用" 正在成为落地 AI 应用的主流范式。相比动辄需要 H100 集群的 GPT-4 类超大模型，Qwen2.5-3B 在消费级硬件上就能跑，极大降低了 AI 应用部署的门槛。

对于 AI 开发者而言，这个项目是一份很好的RLHF 实战教材：四种训练器的实现代码、DeepSpeed 配置、RAG 三种策略的对比实现，都可以直接参考和迁移。

---

一句话总结：一个用 Qwen2.5+RLHF+RAG 打造的智能旅游规划助手，技术栈完整、代码可迁移，适合作为垂直领域 AI Agent 的实战参考项目。部署有一定门槛，适合有 GPU 资源的开发者研究学习。