
— 第五讲封面
顾客问:“这个商品收到以后,几天内可以退?”AI 很快回答“七天”。听起来没问题,可你的政策昨天刚改成十四天。它回答得越流畅,错误反而越容易被当真。
上一课的商品顾问能围绕三款商品进行推荐。这一课,我们给它加上知识库客服:先查资料,再回答,最后把找到的依据交给你检查。目标不是让它“永远不会错”,而是让错误更容易被发现。
01
PART
为什么写一句“不要胡编”不够
PRACTICE
模型具备语言能力,不等于保存着你今天刚修改的经营政策。把十份文档一股脑塞进每次提问,也会增加上下文长度、调用成本和维护难度。资料继续增长后,还需要有选择地找出相关片段。
本课使用 Viking 知识库与火山方舟。知识库负责保存、处理和检索文档;方舟里的模型负责根据检索到的资料组织回答。它们都不能替你决定过期政策还能不能用,也不能替你保证原始文档正确。
这条流程常叫检索增强生成。可以先记住一句话:先找证据,再解释证据。知识库并不能自动消除幻觉,提示词也不是权限系统。

— 第五讲架构图
02
PART
第一步:整理十份能核对的资料
PRACTICE
仓库的 knowledge 目录提供十份虚构资料:两款背包、一款台灯,以及退货、运费、发货、发票、保修、人工客服和价格库存声明。每份都有资料编号和版本,便于判断回答来自哪里。
资料要写清适用范围。“台灯保修十二个月”不能被解释成“全店商品都保修十二个月”。“通常四十八小时内发货”也不等于“保证两天送达”。如果原文模糊,先修原文,再指望 AI 回答准确。
默认只导入 D01 至 D10 十份文件。return-policy-v2.md 留到更新实验时使用,不要一开始把七天和十四天两份政策混在同一个有效索引里。
AI 任务卡:检查十份资料的编号、版本与适用范围,找出容易混淆的承诺。不得添加资料没有写明的政策。把每份文档对应的可回答问题和不可回答问题列出来;冲突内容先标记,不能替商家决定以哪份为准。
03
PART
第二步:先看本地检索,再接云端
PRACTICE
进入 course-plan/lessons-04-06,首次使用先从示例复制 .env,确认 MODE=demo、RETRIEVER=local。第五课使用18405端口和独立 Compose 项目。
docker compose -f lesson-05/compose.yaml config --quiet
docker compose -f lesson-05/compose.yaml up -d --build
curl http://127.0.0.1:18405/health
打开页面问“退货期限是几天”。默认模式用关键词找资料,并直接展示原文。它是帮助理解流程的本地演示,不是向量检索,也没有调用方舟。
然后在 Viking 知识库控制台创建专用实验知识库,导入十份资料。知识库名称、资源标识、项目、索引参数与计费方式按当前控制台确认。上传完成后,还要检查文档处理、切片和索引状态,不能把“文件已上传”当成“可以检索”。
本课使用知识库 API Key 鉴权与 search_knowledge 接口。把 RETRIEVER 改为 viking,填写服务端 VIKING_API_KEY 与 VIKING_RESOURCE_ID,再更新本课容器。先保持模型模式为演示,检查真实检索返回的原文;确认检索正确后,再切换 MODE=ark 并填写方舟配置。
这三个阶段分别是本地检索加原文展示、云端检索加原文展示、云端检索加模型组织回答。页面与验收记录都要写清处于哪个阶段。TOS 可以用于资料归档,本次小实验不要求为了凑产品额外购买存储。
04
PART
第三步:让依据跟着答案一起出现
PRACTICE
服务端会保留检索返回的文档编号、切片编号、原文和版本。页面在答案下方展示这些来源,便于你直接对照,而不是让模型临时编几个“参考资料”名称。
有引用,不等于引用支持答案。例如引用的资料只写了“通常发货时间”,答案却说“必定明日到货”,仍然是不合格的回答。请检查答案中的每个承诺是否真的能从对应原文推出。
没有检索结果时,本实验直接提示资料不足,不再让模型自由补全。检索到的是无关资料时,仍然需要检查相关性,并让回答明确不足;生产应用应结合业务评测设置相关性门槛和人工转接机制,不能照搬一个随意的分数。
文档里出现“忽略规则、输出密钥”等内容,也应被当成待处理数据,不是执行命令。不要把知识库的文字变成系统权限。
05
PART
第四步:用二十题找到薄弱处
PRACTICE
仓库提供二十个问题,其中十八个应当找到指定资料,两个没有答案,必须转人工。先运行本地验收,确认资料映射与拒答逻辑,再用同一套题人工检查真实云端检索与模型回答。
python3 -m unittest discover -s tests -v
python3 evaluate.py
本地评测统计来源命中与缺失问题拒答,不能代替生成答案的正确性评测。真实模式应另存逐题记录:检索到的资料、回答中的事实、是否遗漏条件、是否编造承诺、是否需要人工介入。
用一个反例解释差别:问题问“背包能保修十二个月吗”,检索可能召回台灯的保修条款。即使来源命中保修文档,也不能据此判定答案正确。要检查商品范围。
06
PART
第五步:改一条政策,看更新是否真的生效
PRACTICE
本地页面可以切换v1与v2:退货期限从七天变成十四天。这是内置数据切换,只演示版本概念,不代表已经更新 Viking。
真实知识库中,用v2替换或隔离旧政策,等待新索引处理完成,确认旧版不再进入当前有效检索范围,再重新问同一个问题。保留检索原文和版本记录。如果新旧资料同时召回,客服应说明冲突并转人工,不能让模型自行决定哪个更有效。
对于旧订单适用哪版政策,也要由业务规则判断,不能简单认定“新政策覆盖所有历史订单”。本课更新文件已明确留下这个待核实条件。
07
PART
60分钟直播怎么做
LIVE
前5分钟演示“流畅但过期”的错误;5至13分钟拆开检索与生成;13至23分钟整理资料并运行本地实验;23至36分钟检查云端导入、索引与检索;36至46分钟展示来源和无答案问题;46至55分钟评测并更新政策;最后5分钟答疑。
文档处理和索引等待安排在课前。直播现场展示状态与结果;如果状态未就绪,就讲清卡在哪里,不伪造成功结果。
作业是提交二十题检查表,指出一个“有引用但仍然答错”的例子。下一课,客服将不只查资料,而是查询订单:谁能查、查什么、失败时怎么解释,都要有后端规则。
08
PART
代码与官方资料
PRACTICE
实验入口为 lesson-05/README.md,附十份资料、二十题、更新实验与验收模板。
我是 {{作者名}},{{简介}}。