前面三篇文章记录的是景区导览系统从架构、RAG 到数字人联调的第一版脉络。6 月这轮更新之后，项目已经不只是“能演示问答和数字人”，而是补上了更完整的游客闭环：官方资料进入知识库，问答支持多模式检索和真实流式生成，游客端有电子围栏和老年模式，管理端能处理反馈、二维码和知识候选。

这篇是最新口径的补充，不推翻前面的文章。前面的文章仍然适合看系统怎么搭起来；这篇主要说明项目后来补了哪些工程边界。

官方资料进入知识库

最重要的变化，是知识来源不再只靠早期网页资料和手写样例。

项目把比赛官方提供的结构化景点资料、游览指南和游客行为数据接进来了。知识库从原来的 122 条真实资料切片扩展到 150+ 条，新增内容覆盖灵山胜境 16 个景点、拈花湾 6 个景点、历史沿革、门票信息、工程数据和文化内涵。

同时，数据大屏侧也补了更像真实运营材料的数据：140,447 条游客行为记录总览、152 个景区统计、8 种景区类型统计、消费结构，以及灵山大佛、灵山胜境和拈花湾的月度趋势、年龄段和消费结构。

这里我会刻意分清楚边界：这些数据能支撑本地演示、RAG 评估和运营看板展示，但它不是实时客流系统，也不代表线上商业运营数据。

RAG 从单路检索变成可对比链路

RAG 现在支持 5 种检索模式：

  • bm25-local
  • embedding
  • hybrid-weighted
  • rrf-fusion
  • light-rerank

本地无外部 Key 时，可以稳定跑 bm25-local 和 light-rerank。配置 DashScope Embedding 后，再比较语义召回、加权融合和 RRF 融合。

真实资料评估集仍然是 203 条独立问答。6 月更新后，项目在检索前增加了只用于召回和打分的 query expansion，并补强了少量真实资料切片中的游客问法和边界词。用户原始问题不会被改写，生成 prompt 也不会被替换成扩展词。

当前 retrieval-only 单轮口径是：bm25-local 通过率 98.5%、Recall@8 94.8%、MRR@8 0.793；light-rerank 通过率 99.5%、Recall@8 95.3%、MRR@8 0.802。

这组数字只说明当前真实资料评测集上的检索链路表现。它不包含外部 Embedding、大模型生成、ASR、TTS，也不是线上 SLA。这个边界比漂亮百分比更重要。

流式回答从“像流式”改成真实链路

数字人和 AI 问答也做了一次关键修正。

早期 OpenAI 兼容接口里，stream=true 更像是拿到完整回答后再按字符切块输出。最新实现改成直接走 QueryWithRAGStreaming，向上游 LLM 发送真实流式请求。上游失败时会返回明确 SSE error，不再把知识库素材拼成一个看似正常的答案。

这个改动牺牲了一点“看起来很快”的体验，但换来了正确性。导览系统最怕的是模型失败后还装作正常回答，尤其知识库里有“游客常问”“问答素材”这类组织文本时，模型如果直接复述素材标题，游客会立刻出戏。

所以现在的策略是：配置真实 LLM 时，优先保证检索改写、重排序和生成质量；模型不可用时明确失败或走受限本地 fallback，不伪装成完整导游讲解。

文字输出和语音播放解耦

数字人页面以前有一个体验问题：如果 Open-LLM-VTuber WebSocket、TTS 或浏览器自动播放任何一环出问题，用户会感觉连文字回答都卡住。

最新前端把文字回答固定优先走 Go 后端 /api/v1/ai/chat，语音播放、口型和 Live2D 表现变成独立增强。未点击“启用声音”前，不主动请求 TTS；TTS 无音频或播放失败时，会提示用户并退到浏览器朗读，朗读 fallback 也继续驱动口型脉冲。

这让数字人从“语音链路成功才像活着”变成“文字问答先可靠，声音和动作逐步增强”。对作品集演示来说，这比单纯追求一次顺滑录屏更稳。

鉴权和接口契约收紧

浏览器端登录改成 Cookie 会话：POST /api/v1/login 只设置 auth_token HttpOnly Cookie，响应体返回用户资料，不再把 JWT 放进响应体。前端通过 GET /api/v1/user/me 恢复会话。

配套的安全边界也补上了：

  • /api/v1/admin/* 必须管理员鉴权。
  • 数字人游客 API 需要登录。
  • /metrics 改为管理员保护。
  • CSRF token 统一处理。
  • 注册接口不接受客户端传角色。
  • 对外 JSON 字段统一使用 snake_case。
  • 密码策略、IDOR、限流器停止、响应体大小限制和密钥扫描都做了补强。

这些东西不会让页面变酷，但会让项目从“能跑”更接近“有基本工程纪律”。

游客闭环：电子围栏、二维码和反馈分析

v0.3 这轮最像“业务闭环”的部分，是游客端和管理端一起补了起来。

游客端新增了老年模式：放大控件、降低语速，让地图页、数字人页和扫码页都能用同一套体验开关。地图和数字人页接入电子围栏逻辑，到达景点附近可以触发自动讲解，并带跨页面冷却，避免重复打扰。

管理端新增二维码管理，可以生成、复制、下载 PNG/SVG，用于把线下景点和线上导览入口连起来。知识库管理也从普通列表升级为服务端搜索、分类筛选、分页和 AI 知识候选审批。

反馈链路也不再只是“点了赞踩”。游客会话可以进入脱敏分析，生成满意度结果和知识候选；管理员可以批准入库或拒绝。这里同样有边界：AI 分析需要真实 OpenAI-compatible 配置，不会在无 Key 时伪造结果。

现在这版怎么讲

如果现在介绍这个项目，我不会只说“Go + Vue + RAG + Live2D”。更准确的说法是：

它是一个景区智能导览系统，后端用 Go/Gin 管 API、鉴权、RAG、统计和数字人协议；前端用 Vue 做游客地图、数字人、数据看板和管理后台；知识库从官方资料和真实评估集出发，支持多种检索模式和可复现评测；游客反馈、二维码、电子围栏和知识候选让系统形成了一个小闭环。

它仍然不是公网商业系统，也没有宣称生产 SLA。但相比最早的演示版本，它已经更能回答一个关键问题：游客问完以后，系统怎么维护知识、怎么处理反馈、怎么继续变好。