# Summary |模块|通俗比喻|作用| |---|---|---| |**MinHash**|找抄袭作业|去除重复帖子| |**PostGIS**|电子地图|存坐标、算距离| |**图数据库**|朋友圈关系网|知道哪些POI常一起玩| |**RAG检索**|图书馆查资料|找相关帖子喂给LLM| |**LLM生成**|旅游规划师|把资料整理成行程| ## 重点knowhow | 数据 | | | -------------- | ------------------------------ | | [[四渡赤水-RAG]] | 检索: 分块、索引策略 | | | 增强：[[四渡赤水-POI共现图谱]] | | | 生成：离线与实时 | | [[四渡赤水-数据抓取]] | 认知单位是 POI，而不是路线。名词和概念是理解信息的抓手 | | [[四渡赤水-数据清洗]] | | | [[四渡赤水-交互]] | 渐进式的信息交互，本质也是在教育和传递给用户信息和目的地知识 | | [[四渡赤水-评估]] | 人类无法分辨陌生地方链表的优劣，交给机器后置评估 | | | | | [[四渡赤水-猜你想问]] | | ## workflow vs React 1. 意图很容易 MECE，就 workflow 2. 意图不容易 MECE，就 reAct ## 处理过程 gpt pro：https://chatgpt.com/s/t_68e38fc2f2388191b69376d8b13dba21 本质是过去这个系统的信息 input 只有干巴巴的路线列表，现在下钻到帖子维度，而且也不需要区分路线贴和 POI 贴了。只有经典贴和新鲜贴 1. [任务型对话](任务型对话.md) 1. [意图识别](意图识别.md)、[对话状态跟踪 DST](对话状态跟踪%20DST.md) 2. 基于[[RAG]]的有特色的动态反问，通过召回的帖子生成一轮三个选择题三种风格方案的反问，然后再根据用户按钮的选择对帖子进行生成，这一轮很关键，是选择题，费力度不会太高，但同时也是通过选项的方式给用户传递目的地的一个大的 context 信息。多选题里不是链表 而是风格玩法 可以带一点点poi 1. 读帖子→去重→分块→建立索引→检索→行程生成 2. [[四渡赤水-数据清洗]]、帖子时效性标注（例如“首发于 2023-10”） 3. **冷启动与地域覆盖**：热门目的地离线预计算完整；长尾目的地用轻模板 + 在线检索补全。单城市、热门城市的可以离线生成，离线召回；如果是那种用户定制的（比如：我想去北京，必须去xxx景点），这种就得现生成了，我今天看用户问题，感觉定制路线的也不少 4. 多城市的可以实时生成或者跳过这一步骤 3. [[四渡赤水-RAG]]生成文字回答，只有跨城市的才在dayx字样后面标注城市 非跨城市的不标注 1. 可[[多路召回]]，比如自驾等需求可直接走关键词搜索召回 2. 以后不再区分路线贴和 POI 贴，只区分 旅游贴 vs 非旅游贴，经典贴 vs 新鲜贴 3. 对存量帖子和新鲜帖子的[表征学习](表征学习.md) 4. 和UI商量用下划线还是用彩色字 5. **要把一些注意事项和真诚推荐也总结到结果中** **只是一个链表反应的信息太有限了** 4. 问题推荐，多选题还可以体现在问题推荐里。里面可以说帮我换个xx风格的路线 5. [命名实体识别 NER](命名实体识别%20NER.md)、[[四渡赤水-NER]] 6. [实体链接, 挂靠](实体链接,%20挂靠.md) 7. 如果挂靠 70%+以上 NER，才会给出地图卡片模块 8. 行程管理阶段：用户进入地图自己编辑调整POI 列表和顺序 9. 用户确定出发日期，匹配酒店交通，给出预算价格和便签理由 10. Agentic 阶段 以后的规划结果的chat编辑直接让ai硬改 严格要求输出json格式就行。前端动态适配。明确好酒店这种tool的边界 说清楚无法实现宠物筛选之类的就可以 11. MVP 验证 1. 找到最近所有杭州的问题。用新版本的新方案得到一下评分 12. 背后统计 1. AI 生成的路线的交通费力度和 xhs 路线的水位比较 2. 用户漏斗比例 3. 用户保存的路线 ## 算法角度的理解（可以作为打分和巡检逻辑） [[四渡赤水-评估]] **普通人仅从文字交付很难看出来，哪怕实地去一次也很难感受到，偏向一锤子买卖** > 本质是**带时间窗的 Orienteering/VRPTW**：在每天有限时长内，选择并排序 POI，使总“体验分”最大，满足开放时间、交通与节奏约束。 1. **评分函数（示例）** $\text{score}(p)=w_\text{style}\cdot s_\text{style}(p)+w_\text{pop}\cdot s_\text{pop}(p)+w_\text{fresh}\cdot s_\text{fresh}(p)+w_\text{season}\cdot s_\text{season}(p)-w_\text{crowd}\cdot c(p)$ - **style**：与所选风格的相似度（由文本/标签学到）； - **pop**：热度（去交互水分后）； - **fresh**：内容新鲜度； - **season**：与出行月份/天气兼容度； - **crowd**：拥挤风险或排队时长估计。 2. **候选集裁剪** - 先用 **地理聚类（H3/k-means by 坐标）**，每日选 1~2 个簇，减少跨城穿梭； - 对每簇按 score 排前 k（如 12~15）。 3. **序列求解** - **启发式**：Nearest Insertion / Greedy + **2-opt/3-opt** 微调路顺； - **时间窗**：硬约束（闭馆前必须到）、软约束（午餐 60min、咖啡 45min、步行日总量 $\le$ 12k 步）； - **交通时长**：用路网/打车/地铁 ETA（可用缓存表或第三方 API 估计）； - **回退机制**：若违反任何约束，自动替换为同簇“备选 POI”。 4. **鲁棒性** - 为每个 Day 产出 **Plan A（主线）/Plan B（雨天）/Plan C（人多时）**。 # Notes 1. 一定要最热门的 POI 串起来，不然觉得来亏了 2. 又要多一些本地人视角，让他觉得自己不是简单的打卡而已 ## 十、端到端流程（落地蓝图） - **采集 → 解析 → 归一**（文本清洗、时间/价格规范化、图片 OCR）。 - **多层去重**（MinHash → SimHash → Embedding/pHash）。 - **NER & 实体链接**（候选生成 + cross-encoder 排序，产出 POI_id + 坐标 + 置信度）。 - **知识构建**（POI 主档 + 经验片段索引，打上风格/季节/时段标签）。 - **离线预计算**（目的地×风格模板、ETA/转场表）。 - **在线请求**： - 风格/天数 → **Hybrid 检索**候选片段与 POI； - **Orienteering/VRPTW** 选点与排序（约束校验 + 备选）； - **RAG 生成**（结构化 JSON + 可读文案 + 证据对齐）； - **冲突校验**（闭馆/超时/过长转场）→ 自动替换与再生成。 - **观测与纠错**（日志 + AB 测试 + 人工复核队列）。