从原型到生产：使用 FastAPI + ChromaDB 构建可靠的 RAG API

Source: Dev.to

为什么我超越了原型

原型可以回答文档中的问题。
生产系统还必须具备：

• 在重复使用下保持可靠
• 可追溯（显示来源）
• 更易于维护和部署
• 对幻觉更安全

这种转变改变了我对每一层的设计方式。

架构概览

我的流水线

• 文档导入（.pdf、.txt、.docx）
• 文本清洗 + 带重叠的智能分块
• 嵌入生成（all‑MiniLM‑L6‑v2）
• 在 ChromaDB 中持久化向量存储
• 语义检索（带元数据的 Top‑K）
• 严格的提示构建以获得有依据的答案
• 通过 Groq（兼容 OpenAI SDK）生成 LLM 响应
• API 响应包含答案 + 来源 + 置信度 + 延迟

我实现的内容

1. 文档处理层

   • 多格式加载器（PDF/TXT/DOCX）
   • 规范化和清洗
   • 带重叠的分块策略以保持上下文连贯
   • 为每个块添加元数据（来源、页码、chunk_id、时间戳）

2. 向量存储层

   • 持久化的 ChromaDB 集合
   • 嵌入 + 索引流水线
   • 相似度搜索 API
   • 可选的 MMR‑式多样性检索
   • 集合维护（计数、清空、按来源删除）

3. RAG 聊天机器人层

   • 带编号来源块的上下文构建器
   • 受控提示规则：
     • 仅从提供的上下文中作答
     • 如上下文不足则明确拒绝
     • 始终引用来源
   • 基于检索距离的置信度估计
   • 可选的对话历史支持

4. FastAPI 服务层

   • POST /upload 用于导入 + 索引
   • POST /query 用于有依据的问答
   • GET /health 用于服务检查
   • GET /documents 用于查看已索引数量
   • POST /reload 用于重置操作

关键的生产经验

• 检索质量 > 模型规模，对多数问答任务更重要。
• 提示约束与向量搜索同等重要。
• 元数据是调试和建立信任的超级能力。
• 置信度 + 来源显著提升可用性。
• 可观测性（延迟/日志/错误）不是可选项。

技术栈

• FastAPI
• ChromaDB
• Sentence Transformers
• OpenAI SDK（兼容 Groq 的端点）
• PyPDF2 / python‑docx / dotenv

最后感想

构建 RAG 很容易。
构建可靠的 RAG 才是真正的工程挑战。

如果你也将 RAG 系统投入生产，欢迎分享在你的部署中最关键的改进点。

GitHub: RAG SYSTEM