Day 14 - Building a Minimal RAG Demo

今日目标

能实现本地文档加载、切分、检索、带来源引用的最小 RAG 问答 Demo。

学习安排

核心概念

阅读重点

• 对应章节：第 3 章中 RAG、知识库相关内容（结合 Day 12 的完整链路）
• 关注点：最小闭环需要哪几个模块：load → split → retrieve → generate → cite
• 关注点：检索结果怎么判断够不够：看 top-k 里有没有真正相关的片段
• 关注点：生成端如何避免编造：约束只基于片段、信息不足就明说
• 关注点：Demo 与生产级的差距：更新、权限、评估、监控、成本
• 补充材料：LangChain 官方文档中 loader 与 text splitter 的用法
• 补充材料：向量数据库（Chroma / FAISS）官方快速入门，跑通一次相似度检索

理解检查

• 最小 RAG 系统必须包含哪些模块？哪个模块可以最后再做？
• 不用向量数据库能不能做 RAG？可以用什么替代？
• 如何判断检索结果是否足够？只看相似度分数够吗？
• 答案生成时如何避免编造？约束手段有哪些？

实践任务

背景：测试团队经常被问"Nginx CPU 升高怎么排查"，你要做一个最小知识库问答 Demo，输入本地 Markdown 文档，输出带来源引用的回答。

• 建一个 docs 目录，放入 3 篇 Markdown 排查文档（可复用 Day 12 选的文档）
• 实现 5 个函数：load_markdown_files / split_docs / retrieve / llm_answer / print
• 用示例问题"如何排查 Nginx CPU 升高？"跑通一次完整闭环
• 检查输出：答案是否基于片段、引用是否指向真实来源文件与片段编号
• 保存运行输出，这是 Day 15 设计文档的证据材料
• 提示：retrieve 先用关键词匹配（分词加词频）跑通，向量检索留到调优阶段再换
• 提示：卡住时先打印 chunks 的前 100 字符，确认切分结果合理，再查检索逻辑

docs 目录结构示例：

docs/
  nginx-cpu-spike.md
  load-test-report-template.md
  defect-report-guideline.md

输出模板

docs = load_markdown_files("./docs")
chunks = split_docs(docs, chunk_size=500)
query = "如何排查 Nginx CPU 升高？"
results = retrieve(chunks, query, top_k=5)
answer = llm_answer(query, results)
print(answer)

各函数职责（用你熟悉的语言实现，不限于 Python）：

- load_markdown_files(dir)：遍历目录，返回 [文件名, 正文] 列表
- split_docs(docs, chunk_size)：按固定长度切分，返回带来源编号的片段列表
- retrieve(chunks, query, top_k)：关键词或向量检索，返回 top_k 片段与来源
- llm_answer(query, results)：把片段拼进 prompt，要求只基于片段回答并附来源

示范输出

问：如何排查 Nginx CPU 升高？

答：根据知识库排查手册，建议按以下顺序排查：
- 确认时间窗口与关联事件，先看是否与流量高峰或 WAF 开关对应。
- 检查 access log 中 5xx 与超时比例的上升。
- 对比 WAF 开启前后的 CPU 曲线与 upstream 响应时间。
- 定位高 CPU 的 worker 进程，抓取调用栈，确认是流量型还是配置型。
- 验证后给出结论，并标记"已验证"与"待验证"项。

来源：
- [nginx-cpu-spike.md #3] 排查步骤与时间窗口确认方法
- [nginx-cpu-spike.md #5] WAF 开关对比方法
- [load-test-report-template.md #2] 压测指标口径说明

追问练习

• 不用向量数据库能不能做 RAG？关键词检索的优劣分别是什么？
• 如何判断检索结果是否足够？top-5 里没有相关片段时你会怎么处理？
• 答案生成时如何避免编造？如果片段之间相互矛盾，生成端应该怎么办？
• Demo 和生产级 RAG 的差距在哪里？列出 4 项并按重要性排序。

常见误区

• 一上来就上重型框架（LangGraph、整套向量平台）：链路没跑通先被框架复杂度困住，应该先做最小闭环。
• 检索结果不检查直接给模型生成：top-k 全是噪声时，模型只能靠编。
• 引用只是装饰：引用必须能回溯到真实片段，否则等于没有。
• chunk_size 与 top_k 随手定：先跑通再调参，调参依据是检索效果而不是感觉。

进阶扩展

• 生产差距清单：知识库更新、权限过滤、检索质量评估、监控与成本控制，是 Demo 到生产的主路。
• 混合检索：关键词与向量并行召回，用 RRF 合并结果，专有名词命中率提升明显。
• 检索端评估：用一组标准问题加期望片段构建小 eval set，持续回归检索质量。

今日作业

• 跑通最小 Demo，保存一次完整问答输出（必须含引用）。
• 换一个你真实工作里的问题（如"如何排查接口 P95 升高"）再跑一次，对比两次引用质量。
• 写出 Demo 与生产级 RAG 的 4 项差距清单。
• 明天用 Demo 经验输出《知识库问答 Agent 设计 v0.1》。

自检清单

• 我能说清最小 RAG 的 5 个模块各自做什么。
• 我能跑通一次带来源引用的问答。
• 我能判断检索结果是否足够，而不是盲目生成。
• 我能说出 Demo 与生产级的至少 4 项差距。
• 我知道明天要复习哪一点。