rag-ops：一条从文档到智能问答的完整 RAG 流水线

在企业级 AI 应用落地过程中，最让开发者头疼的往往不是"怎么调 API"，而是"怎么把一套 RAG 系统从零做到生产级"——文档怎么切分、向量化怎么做、查询怎么路由、回复怎么安全、出了问题怎么追踪。这些问题分散在不同工具、不同配置文件里，拼凑起来至少要踩十几个坑。

T-Sunm/rag-ops 就是一个专门解决这个问题的开源项目：它将 RAG（检索增强生成）系统的所有核心组件串联成一条完整流水线，覆盖从文档摄入、向量存储、推理服务，到可观测性、安全护栏、缓存加速的全部环节。项目使用 Python + LangChain 构建，代码结构清晰，模块之间职责明确，是学习和落地 RAG 生产系统的绝佳参考。

图：rag-ops 系统整体架构，展示了从文档摄入到 LLM 回复的完整数据流向

一、项目背景与解决的问题

RAG（Retrieval-Augmented Generation）已经是目前大模型落地最主流的架构范式之一。它的核心思想很直观：让大模型在回答问题时，先从知识库中检索相关文档，再结合这些文档来生成答案，从而有效缓解大模型的"幻觉"问题，并支持私有知识问答。

然而，将 RAG 从 Demo 做成生产系统，远比想象中复杂。一个完整的企业级 RAG 系统通常需要以下组件协同工作：文档摄入管道、向量数据库、推理服务、API 网关、缓存层、可观测性平台、安全护栏和路由层。这些组件在开源世界里各有优秀的独立项目，但把它们整合在一起、让彼此无缝协作，本身就是一个巨大的工程挑战。rag-ops 的核心价值，就是把这个"拼图"做好了。

二、核心功能与技术细节

2.1 文档摄入管道

rag-ops 的文档摄入流程借助 Apache Airflow 做任务编排，配合 MinIO（兼容 S3 的对象存储）管理原始文档和中间数据，支持的文档格式包括 PDF（通过 pypdf 和 docling）、Markdown 等。摄入后的文档经过分块处理，转换为向量嵌入存储到 ChromaDB 向量数据库中。

整个摄入管道由 DAG 驱动，开发者可以在 Airflow UI（默认 localhost:8080，账户 airflow/airflow）中直观地监控每个步骤的执行状态，查看 DAG 运行日志和执行时间分布。

图：Airflow Web UI 中的 DAG 监控面板，可以查看 ingest_data 管道的执行状态和耗时

2.2 API 层与推理服务

API 层基于 FastAPI 构建，提供两类核心接口：REST 阻塞接口（/v1/rest-retrieval）和 SSE 流式接口（Server-Sent Events）。推理引擎默认通过 LiteLLM 调用外部 LLM（如 Groq、OpenAI、LM Studio），LiteLLM 充当统一适配层，同一套代码可以无缝切换不同的模型提供商，降低了厂商锁定风险。

图：FastAPI 自动生成的 Swagger UI 文档，支持在线调试 API 接口

2.3 可观测性层

rag-ops 集成 Langfuse（类似 LangSmith 的开源替代），提供 Prompt 追踪、成本分析、质量评估和 Traces 可视化功能。Langfuse 本身依赖 PostgreSQL 和 ClickHouse，通过 Docker Compose 一键启动。

2.4 缓存层与安全护栏

使用 Redis 作为缓存后端，配合 LangChain Redis 集成实现确定性输出缓存。基于 NeMo Guardrails 实现多层安全保护：内容过滤、PII 过滤、主题限制和 Policy 执行。

图：NeMo Guardrails 的配置界面，支持自定义主题限制和安全策略规则

三、上手体验与门槛评估

项目提供了详细的 README 和完整的环境配置示例，克隆后需要先启动基础设施（Redis、Langfuse、Airflow 等多个 Docker 服务），再触发数据摄入 DAG，最后启动 API 服务。部署复杂度中等，对 DevOps 能力有一定要求。项目还集成了 Open WebUI，可以部署为面向终端用户的 ChatGPT 风格问答界面。

四、架构设计与代码质量

项目采用清晰的分层架构：src/ 下分 api（路由）、services（核心业务）、config（配置）、utils（工具函数）、schemas（Pydantic 模型）、constants（常量）；infrastructure/ 下管理 cache、observability、storage、router 等依赖服务；guardrails/ 存放 NeMo Guardrails YAML 配置；ingest_data/ 定义 Airflow DAG。整体遵循关注点分离原则，每个组件都可以独立使用或替换。

技术栈涵盖 LangChain 0.3.x + LiteLLM（LLM 框架）、ChromaDB（向量数据库）、FastAPI + Uvicorn（Web）、Apache Airflow（任务编排）、Redis（缓存）、MinIO（对象存储）、Langfuse（可观测性）和 NeMo Guardrails（安全护栏）。

五、局限与挑战

1. 无 LICENSE 文件：项目没有明确的开源许可证，在生产使用前需要联系作者确认授权方式
2. 部署复杂度较高：需要同时启动 5+ 个 Docker 服务，初次部署需要一定时间
3. 缺少增量摄入：当前 DAG 为全量摄入，缺乏对新增文档的增量更新机制
4. 生产级 HA 缺失：未提供高可用部署配置

六、项目亮点与行业意义

rag-ops 是一个真实生产视角的全链路 RAG 系统示例，涵盖 RAG 生产系统的所有关键组件，展示了真实的工程权衡。模块化设计使每个组件都可以独立使用或替换，整体工具链完整，是很好的 LLMOps 教学案例。通过 --dataset 参数支持多数据源切换，可满足多业务线隔离需求。

总结：rag-ops 非常适合作为 LLMOps 的学习项目或企业内部 RAG 架构的参考模板。如果你正在搭建生产级 RAG 系统，这个项目值得深入研究其中的每一个模块。