我的成长笔记

Appearance

第 10 课：独立完成一个 RAG 项目 ​

RAG 课程 · 10 ｜目标：从数据、检索到评测和部署独立交付｜建议周期：1～2 周

这一课不是继续记概念，而是把前 9 课收敛成一个可展示、可复现、可解释的项目。

项目题目 ​

完成一个“企业内部知识库问答助手”。默认领域是公司制度和技术运维文档，也可以替换为你自己的文档。

用户可以提问：

  • “年假需要提前几天申请？”
  • “Docker 容器无法访问外网应该检查什么？”
  • “这个错误码对应哪篇运维文档？”
  • “资料里没有说明的内容是什么？”

系统必须返回答案、证据片段和来源，而不是只返回一段没有依据的生成文本。

最小功能范围 ​

离线入库 ​

text
Markdown/PDF
  → 解析
  → 结构感知切分
  → metadata
  → embedding
  → 向量库

至少保存：

text
chunk_id
document_id
title
section
source_path
content_hash
embedding_model
version
updated_at
permission_scope

在线问答 ​

text
用户 query
  → query 处理
  → dense / BM25 / hybrid 召回
  → metadata 权限过滤
  → rerank
  → 上下文组装
  → LLM 生成
  → 引用和拒答

第一版可以使用标准 RAG；Agentic RAG 作为扩展，不要一开始就让 Agent 接管所有问题。

推荐项目结构 ​

text
rag-project/
├── data/
│   ├── raw/
│   └── eval.jsonl
├── src/
│   ├── ingest.py
│   ├── chunking.py
│   ├── embeddings.py
│   ├── retrieval.py
│   ├── rerank.py
│   ├── context.py
│   ├── answer.py
│   └── evaluate.py
├── tests/
├── .env.example
├── README.md
└── docker-compose.yml

目录不是硬性要求，但模块边界必须能回答：哪段代码负责入库，哪段负责召回，哪段负责生成，哪段负责评测。

四个交付里程碑 ​

Milestone 1：可检索 ​

  • 准备至少 20 篇有真实结构的文档。
  • 解析并切分为 chunks。
  • 能通过 document_id 和 chunk_id 追溯来源。
  • 用 10 条 query 验证正确 chunk 是否能被召回。

Milestone 2：可回答 ​

  • 实现标准 RAG 问答。
  • 答案必须带引用。
  • 证据不足时必须拒答或明确说明资料不足。
  • 保存每次请求的召回结果和最终 prompt。

Milestone 3：可评测 ​

  • 建立至少 30 条 query 的评测集。
  • 覆盖同义表达、精确关键词、多条件、无答案和权限问题。
  • 比较至少两种方案，例如 dense 与 hybrid，或两种 chunking。
  • 报告 Recall@5、Recall@20、MRR、答案正确性和 p95 延迟。

Milestone 4：可交付 ​

  • 支持文档更新和失败重试。
  • 有日志、trace_id、错误处理和基础缓存。
  • 有 README、架构图、配置说明、启动命令和已知限制。
  • 使用 Docker 或明确说明本地部署方式。

验收标准 ​

维度最低要求
召回评测集中的正确证据能稳定进入 Recall@5 或 Recall@10
答案关键事实有证据支持，引用能指向原始来源
拒答无答案问题不会编造确定结论
权限不同用户只能检索允许访问的文档
更新文档变更后不会长期返回旧版本
可观测能定位一次请求的 query、候选、上下文和阶段延迟
可复现新环境按 README 能完成安装、入库、评测和启动

数值阈值要根据数据集难度、模型和业务风险说明依据，不要为了达标而隐藏失败样本。

最终技术报告 ​

README 或报告至少回答：

  1. 为什么这样选择 chunking 和 overlap？
  2. 为什么使用 dense、BM25 或 hybrid？
  3. embedding 模型如何选择，比较过哪些候选？
  4. reranker 和上下文 token 预算如何设置？
  5. 评测集如何构造，最差的 query 是什么？
  6. 一次失败答案经过哪些日志可以定位？
  7. 更新、权限、缓存和降级如何处理？
  8. 如果引入 Agentic RAG，它解决了什么具体问题？

推荐实施顺序 ​

text
先做可测的标准 RAG
  → 建立评测基线
  → 优化 chunking / embedding / retrieval
  → 加 rerank 和上下文策略
  → 解决更新、权限、延迟和日志
  → 最后为复杂问题增加 Agentic RAG

这条顺序可以避免把检索问题误判成 Agent 问题，也能让每次优化都有对照数据。

项目启动任务 ​

现在先完成项目立项，不要马上写完整代码：

  1. 选择文档领域和数据来源。
  2. 列出 20 篇初始文档及其权限范围。
  3. 写出 10 条真实用户 query。
  4. 为每条 query 标注 relevant chunk 或“无答案”。
  5. 画出离线入库和在线问答两条链路。
  6. 写出第一版技术选型和三个风险。

把这份立项说明发给我，我会按“数据、检索、评测、工程”四个维度检查项目范围，再进入代码实现。

课程完成标准 ​

完成这个项目后，你应当能够独立解释每个模块为什么存在、每个指标如何计算、每个失败样本如何定位，以及一次优化是否真的带来了收益。这样才算从“会调用 RAG 框架”进入“能交付 RAG 系统”。

参考资料 ​

有任何不清楚的地方，直接向老师提问。