6.6 KiB
客服图谱快速查询实现说明
更新时间：2026-06-03
1. 目的
当前客服页 http://localhost:8102/admin/plaza/user 的原型目标不是生成完整复杂行程，而是让客服在对话中快速查到三类高频信息：
- 固定线路有哪些。
- 某个景区附近有哪些可选酒店、餐饮。
- 某个景区有哪些门票、小交通、保险、二消、必付/可选费用。
因此这次没有把所有问题都交给 LLM 慢慢生成，而是先做“轻量 Agent 分流 + 图谱直查”的快速查询能力。
2. 当前采用的方法
方法一：高频问题先走规则意图识别
对客服常见问题先做规则判断：
路线有哪些 / 线路有哪些 / 产品有哪些黄果树附近有哪些酒店餐饮小七孔有哪些必付和可选费用酒店房型 / 旺季 / 淡季 / 房价加人 / 车型 / 用车
命中这些问题后，直接进入专用图谱查询函数，不进入复杂推荐排序，也不等待 LLM。
代码位置：
/Users/xuexue/new2/app/api/travel_assistant.py:1944/Users/xuexue/new2/app/api/travel_assistant.py:3082
方法二：线路清单使用轻量图谱查询
以前“有哪些线路”会加载完整图谱，包括酒店、餐饮、费用、车辆等关系，导致慢且容易只返回一个推荐方案。
现在改成只查询：
TourProduct -> ProductDay -> RouteStop -> ScenicAttraction/SubAttraction
不查酒店、餐饮、费用细节。
这样“有哪些线路”只返回线路清单，默认最多显示 30 条。
代码位置：
/Users/xuexue/new2/app/api/travel_assistant.py:1679/Users/xuexue/new2/app/api/travel_assistant.py:2975
方法三：景区附近资源使用 NEARBY 关系直查
酒店和餐饮已经拆成独立 POI 实体：
ScenicAttraction -> ATTRACTION_NEARBY_RESOURCE -> Hotel
ScenicAttraction -> ATTRACTION_NEARBY_RESOURCE -> Restaurant
客服问“黄果树附近有哪些酒店餐饮”时，直接从景区节点查附近资源，不再绕到线路产品里查。
代码位置：
/Users/xuexue/new2/app/api/travel_assistant.py:2013
方法四：费用资源兼容两条查询路径
费用、小交通、保险、二消可能来自两类关系：
RouteStop -> STOP_USES_DEFAULT_RESOURCE -> TravelItem
ScenicAttraction -> ATTRACTION_HAS_ITEM -> TravelItem
因此费用查询同时查这两条路径。
如果关系里已有 MANDATORY / OPTIONAL / INCLUDED，就直接使用。
如果没有明确状态，就按证据文本轻量推断：
- 出现“必须、必付、需自理、不含、另付” ->
MANDATORY - 出现“自愿、可选、不必须、客人自愿” ->
OPTIONAL - 出现“已含、包含、赠送” ->
INCLUDED
代码位置：
/Users/xuexue/new2/app/api/travel_assistant.py:2196
方法五：推荐问题才走完整图谱排序
如果用户问的是复杂需求，例如：
5个人，想玩5天，想去黄果树、小七孔、西江，预算低，帮我推荐线路
这时才加载完整固定线路图谱，做路线匹配、车辆建议、每日行程、费用提示。
完整图谱加载包含：
TourProduct
ProductDay
RouteStop
TravelItem
Hotel
Restaurant
Vehicle
Fee
NEARBY
代码位置：
/Users/xuexue/new2/app/api/travel_assistant.py:1536/Users/xuexue/new2/app/api/travel_assistant.py:3082
3. 当前已经验证的效果
本地直接调用后端函数验证：
| 测试问题 | 返回结果 | 响应时间 |
|---|---|---|
游路线有哪些 |
30 条线路，图谱候选 39 条 | 约 0.12 秒 |
黄果树附近有哪些酒店餐饮 |
8 个酒店、10 个餐饮 | 约 0.07 秒 |
小七孔有哪些必付和可选费用 |
90 条费用候选 | 约 0.09 秒 |
说明：这是后端图谱查询耗时，不包含浏览器渲染和网络开销。
4. 前端展示调整
客服页按不同结果类型做轻量展示：
route_catalog：线路清单模式，只显示线路编号、名称、天数、路线概览。nearby_resource：附近资源模式，只显示酒店候选、餐饮候选、使用说明。- 普通推荐：保留原来的行程方案卡片。
同时左侧增加常用问法：
- 有哪些线路
- 5天路线有哪些
- 黄果树附近有哪些酒店餐饮
- 小七孔有哪些必付和可选费用
代码位置：
/Users/xuexue/new2/admin-web/src/panels/plaza/TravelAgencyAssistantPanel.tsx:131/Users/xuexue/new2/admin-web/src/panels/plaza/TravelAgencyAssistantPanel.tsx:156/Users/xuexue/new2/admin-web/src/panels/plaza/TravelAgencyAssistantPanel.tsx:182/Users/xuexue/new2/admin-web/src/panels/plaza/TravelAgencyAssistantPanel.tsx:218
5. 是否满足当前原型需求
当前已经满足原型阶段的核心需求：
- 客服可以快速查询已有固定线路。
- 客服可以按景区查附近酒店和餐饮候选。
- 客服可以按景区查费用、二消、必付和可选项目。
- 响应速度从原来的数秒级降到 0.1 秒级图谱查询。
- 展示方式从复杂行程卡，调整为按问题类型展示足够信息。
6. 当前还不是完整 GraphRAG
当前实现是：
用户问题
-> 规则/轻量 Agent 分流
-> 知识图谱快速查询
-> 结构化结果展示
还没有完整接入：
图谱查询
-> 向量库补充原文话术/证据
-> LLM 生成客服自然语言回复
原因是当前原型优先解决“查得到、查得快、数据结构可控”。如果一开始所有问题都走向量和 LLM，会更慢，也更容易把线路、费用、可选资源说错。
7. 后续建议
下一步建议把 GraphRAG 分成三层：
- 快速图谱层：线路、景区、费用、附近资源，必须秒级返回。
- 向量证据层：客服话术、合同说明、退改规则、行程原文，用于补充解释。
- LLM 话术层：只负责把图谱结果和证据整理成客服可复制的话，不负责凭空生成事实。
推荐的最终链路：
用户自然语言
-> Agent 识别意图
-> KG 精确查询
-> Vector 补充原文证据
-> LLM 生成客服回复
-> 返回可复制话术 + 图谱依据
8. 当前风险
- 酒店和餐饮的高德车程字段还有部分是
pending_amap_driving，附近推荐目前主要依赖业务区域匹配。 - 部分费用状态来自文本推断，最终仍应以供应商/产品配置确认。
- “路线有哪些”返回的是固定线路产品清单，不等于所有线路都支持小包团，需要看产品字段
small_group_supported或后续供应商补充。 - 如果后续图谱节点增加到几万级，需要给线路清单和 NEARBY 查询增加分页、索引或缓存。