实验三：检索增强生成（RAG）系统实现

用户735

用户3092

3月31日修改

有困难先找 AI

本实验比实验二更容易出现“明明服务都启动了，但链路还是不通”的情况。遇到报错时，不要只问一句“为什么不行”，而要把以下信息一起发给 AI：​

•
你当前做到哪一步了​

•
你执行的完整命令​

•
报错原文​

•
相关代码或配置片段​

•
docker compose ps、docker compose logs、接口返回结果等上下文​

推荐提问方式：

•
贴出 docker-compose.yml，问“为什么 gateway 容器连不上 chroma”​

•
贴出 curl /v1/retrieve 的返回结果，问“为什么检索出的片段不相关”​

•
贴出 chunk_text() 和入库代码，问“为什么 Chroma 里已经有数据，但回答还是没引用”​

实验目标

本次实验需要在实验二的基础上，为同一个 CourseBot 项目加入最小可用的 RAG 能力，让系统不再只依赖模型参数，而是能够基于你提供的资料进行检索增强问答。​

本次实验的目标如下：

1.
在现有环境中部署 Chroma，作为固定的向量数据库。​

2.
使用 Ollama 运行 bge-m3，作为统一的 embedding 模型。​

3.
新增 services/ingestor，支持上传 .txt 文档、切分 chunk、生成 embedding，并写入 Chroma。​

4.
新增 services/retriever，支持根据用户问题检索 top_k 个相关片段。​

5.
在 gateway 中组装 RAG prompt，把检索结果作为上下文传给大模型。​

6.
让最终回答至少引用 1 条检索片段，证明系统“真的用了资料”，而不是模型自由发挥。​

本实验有一个重要边界：本次先把模块和接口拆清楚，不要求你现在就把 ingestor 和 retriever 独立部署成完整微服务集群。 你可以先把它们做成独立目录、独立接口或独立模块，为迁移到 Kubernetes 做准备。​

为了让大家更容易上手，下面的示例统一采用：

•
Python 3.11​

•
FastAPI​

•
chromadb Python SDK​

•
httpx 调用 Ollama / 其他服务​

•
Docker Compose 管理容器​

如果你的实验二不是 Python，也允许继续使用自己的技术栈；但建议至少把接口、字段语义、验证步骤和本实验保持一致。​

建议完成顺序

这次实验建议严格按顺序推进，不要一上来就同时改 Chroma、embedding、ingestor、retriever 和 gateway。推荐顺序如下：​

1.
先确认你已经完成实验二，且 gateway、ollama、redis 可以稳定运行。​

2.
在现有 Compose 环境中加入 Chroma，并确认服务可访问。​

3.
在 Ollama 中拉取 bge-m3，先单独验证 embedding 能正常返回向量。​

4.
准备一份资料，先用最简单的 .txt 文档开始。​

5.
新增 services/ingestor，先完成“上传文档 -> 切 chunk -> 写入 Chroma”。​

6.
新增 services/retriever，先完成“输入 query -> 返回相关 chunks”。​

7.
最后再改造 gateway，把检索结果拼进 prompt，并要求答案带引用。​

8.
全链路跑通后，再补 readyz、错误处理、README 和实验说明。​

只要你每一步都能“单独验证成功”，实验难度会明显下降。​

1. 实验准备

1.1 准备上一实验的 CourseBot 项目

本实验默认你已经完成实验二，至少具备以下基础：

•
已经有一个可运行的 gateway 服务​

•
已经支持 saas/... 和 ollama/... 两种模型路由​

•
已经有可运行的 docker compose up -d​

•
已经能通过 GET /readyz 看出关键依赖是否可用​

•
已经有基础日志输出能力​

如果这些内容还没有完成，需要先补齐实验二，再继续本实验。​

实验三：检索增强生成（RAG）系统实现​