Zhongye 
2026-08-12-[ADR]-Arkhiv_RAG-vol.1
1. 项目背景与愿景
在当前的 AI 工程实践中，简单的“玩具级” RAG（检索增强生成）Demo 已经无法满足复杂业务场景的需求。为了深入探索 GenAI 系统的工程化边界，我们设计了 Arkhiv_RAG 系统。
该系统的核心目标是：将海量、非结构化的业务知识库及其文档转化为结构化、可检索、可问答的知识库，并在此基础上构建一个具备高可用性、可观测性和高检索精度的生产级 RAG 系统。
作为整体工程路线图的“阶段 1”，本系统将为后续引入 AI Agent 工具调用、推荐系统融合以及完整的 MLOps/LLMOps 流水线奠定底层架构基础。
2. 系统主要要素
[阶段 1] RAG 系统 │ ├─[W1] 基础设施搭建 ──> Docker Compose, FastAPI 骨架, PG/OpenSearch 容器 │ ├─[W2] 数据接入管道 ──> Airflow DAG, arXiv API, GROBID/Docling 双引擎解析 │ ├─[W3] 搜索基础设施 ──> OpenSearch 映射, 自定义分析器, BM25 多字段检索 │ ├─[W4] 分块与评估 ──> 上下文感知分块, nDCG/RAGAS 指标体系, 查询扩展 │ ├─[W5] 完整 RAG 链路 > LlamaIndex 编排, Prompt 工程, 来源追溯, 上下文管理 │ └─[W6] 可观测性闭环 ──> Langfuse 追踪, Prompt 版本控制, Gradio 前端, 缓存层 │ ▼ (输出：高可用本地知识库 API)================================================================================ │ ▼[阶段 2] AI Agent + 工具调用 (新项目) - - - - - - - - - - - - - - - - - - - - - │ ( 虚线代表未来进阶阶段 ) ├─ 记忆与规划能力 │ ├─ 多步推理与工具调用 │ └─ LangGraph 集成 │ │ ▼[阶段 3] 推荐系统 (新子项目) - - - - - - - - - - - - - - - - - - - - - - - │ ├─ 实时内容/混合推荐 └─ 排序与反馈循环 │ ▼[阶段 4] MLOps + LLMOps (进阶) - - - - - - - - - - - - - - - - - - - - - - │ ├─ CI/CD, 评估框架 └─ 微调与 Prompt 版本管理 │ ▼[阶段 5] 完整应用集成 + 云部署 (进阶) - - - - - - - - - - - - - - - - - - - │ ├─ AWS/GCP 部署, IaaS └─ 成本优化, 容器化编排 │ ▼[阶段 6] 监控 + 告警精通 (进阶) - - - - - - - - - - - - - - - - - - - - - - │ ├─ 日志追踪, 漂移检测 └─ 事件就绪的仪表盘本系统采用微服务架构思想，通过 Docker Compose 进行本地编排，实现数据流、控制流和检索流的解耦。核心架构分为以下五大模块：
2.1 数据接入与解析层
- 数据源：arXiv API。
- 解析引擎：采用双引擎容灾模式。主解析器使用
GROBID提取严密的学术结构（标题、作者、摘要、章节、图表、参考文献）；备用解析器使用Docling，确保在 GROBID 解析失败时系统鲁棒性。 - 编排调度：使用
Airflow构建 DAG，实现每日定时拉取、限速下载与并发解析。
2.2 存储与索引层
- 元数据存储：
PostgreSQL，利用 JSONB 字段灵活存储业务文档的动态元数据。 - 搜索引擎：
OpenSearch，构建混合检索索引。- 倒排索引：针对学术术语配置自定义 Analyzer，支持多字段 BM25 评分。
- 向量索引：存储由
SentenceTransformers生成的 Embedding，支持 KNN 语义搜索。
2.3 检索与分块引擎
- 语义分块：摒弃朴素的固定长度切分，采用上下文感知分块，保持文档段落和章节的语义完整性。
- 查询处理：实现查询扩展以提升召回率，支持按类别、作者、时间范围的 Facet 过滤。
2.4 RAG 编排与生成层
- 编排框架：基于
LlamaIndex构建检索管道。 - 上下文管理：针对长业务文档实现智能截断策略，平衡上下文窗口限制与信息完整性。
- 大模型底座：通过
Ollama容器化部署本地模型（如 LLaMA3），支持无缝切换至 OpenAI API。
2.5 应用与可观测性层
- API 网关：
FastAPI异步服务器，负责请求路由与聚合。 - 前端交互：
Gradio构建问答与结果浏览界面，支持段落级来源追溯。 - 全链路监控：
Langfuse集成，实现 Prompt 版本管理、Trace 追踪、缓存命中率监控及 RAGAS 评估指标可视化。
3. 迭代开发计划
构建一个完全本地化并集成 API 的生产级 RAG 系统，包含：
| 模块 | 技术内容 |
|---|---|
| 数据接入 | 使用 Airflow 每日自动从 arXiv 下载 PDF |
| 双解析引擎 | 通过 GROBID 提取结构化内容 + Docling 作为备用方案 |
| 元数据存储 | 将作者、标题、摘要等元数据存入 PostgreSQL |
| 搜索引擎 | 使用 OpenSearch 实现基于 BM25 + 语义向量的混合搜索 |
| 分块引擎 | 语义感知分块（评估不同分块策略） |
| 嵌入存储 | SentenceTransformers + LlamaIndex 索引 |
| RAG 管道 | 查询扩展 + 检索 + Prompt 模板化 |
| 本地 LLM | 使用 Ollama 或 API（LLaMA3、OpenAI 等）回答问题 |
| 可观测性 | 使用 Langfuse 进行 Prompt 版本管理、追踪和质量监控 |
| 评估 | RAGAS 指标、nDCG 评分、准确率和延迟追踪 |
| 前端 | 通过 Streamlit 或 Gradio 提问和浏览结果 |
| FastAPI 后端 | 异步 API 服务器，用于集成和扩展 |
| 开发最佳实践 | uv、ruff、pre-commit、pydantic、pytest、logging 等 |
Sprint 1: 基础设施与沙箱环境搭建
目标：建立微服务骨架与网络通信。
-
FastAPI 项目骨架搭建
-
编排所有服务的完整 Docker Compose 堆栈
-
带健康检查和基础端点的 FastAPI 应用
-
配置了适当网络通信的 PostgreSQL 和 OpenSearch 容器
-
用于本地 LLM 推理的 Ollama 容器
-
无需外部依赖的测试用 Mock 数据管道
-
理解 AI 应用的微服务架构
-
搭建支持热重载的开发环境
-
实现具备错误处理的异步 FastAPI 端点
-
容器网络与服务发现
-
环境配置与密钥管理
🔗 代码 - https://github.com/jamwithai/arxiv-paper-curator 🔗 博客 - 《驱动 RAG 系统的基础设施》
Sprint 2: 数据接入与 ETL 管道
目标：让系统“活”起来，实现真实数据的自动流入。
-
带限速和重试逻辑的 arXiv API 客户端
-
业务文档自动元数据获取器
-
带进度追踪的并行 PDF 下载器
-
GROBID 集成用于科学 PDF 解析
-
Docling 备用方案确保文档处理稳健性
-
编排每日接入的 Airflow DAG
-
妥善使用外部 API（限速策略）
-
高效处理大文件下载
-
实现备用模式提升可靠性
-
理解学术文档中 PDF 解析的挑战
-
构建容错数据管道
-
面向 I/O 操作的异步/等待模式
🔗 代码 - https://github.com/jamwithai/arxiv-paper-curator 🔗 博客 - 《让 RAG 系统活起来——数据管道》
Sprint 3: 搜索基建与混合索引构建
目标：建立高性能、多维度检索底座。
-
针对学术内容优化的 OpenSearch 映射
-
带有 JSONB 灵活元数据的 PostgreSQL 表结构
-
双存储策略实现
-
针对科学术语的自定义分析器
-
带 BM25 评分的多字段搜索
-
按类别、作者和日期范围筛选
-
搜索结果排序和相关性调优——如最新业务文档优先
-
设计双存储系统的表结构
-
面向学术文本的 OpenSearch 分析器和分词器
-
以编程方式构建复杂搜索查询
-
理解 BM25 和相关性评分
-
实现分面搜索和过滤器
-
搜索操作的性能优化
🔗 代码 - https://github.com/jamwithai/arxiv-paper-curator 🔗 博客 - 《每个 RAG 系统都需要的搜索基础》
Sprint 4: 语义分块与检索质量评估
目标：优化文本切分策略，建立评估基线。
-
保留业务文档结构的上下文感知分块
-
基于检索性能的分块大小优化
-
nDCG、精确率和召回率指标实现
-
提升召回率的查询扩展
-
为什么朴素分块对学术文档效果差
-
在技术文本中保持语义边界
-
实现检索系统的评估指标
-
测试不同分块策略
-
理解精确率-召回率权衡
-
真正有效的查询扩展技术
🔗 代码 - https://github.com/jamwithai/arxiv-paper-curator 🔗 博客 - 《分块策略与混合 RAG 系统》
Sprint 5: RAG 核心链路串联
目标：实现“检索-生成-溯源”的闭环。
-
端到端的问答系统
-
LlamaIndex 集成用于 RAG 编排
-
带段落级引用的来源追踪
-
针对学术内容优化的 Prompt 模板
-
长业务文档的上下文窗口管理
-
在保持语义完整性的截断策略
-
带置信度评分的答案生成
-
实现生产级 RAG 管道
-
面向事实准确性的 Prompt 工程
-
有效管理上下文窗口
-
处理多文档综合
-
构建用户信任的引用系统
-
平衡全面性与简洁性
🔗 代码 - https://github.com/jamwithai/arxiv-paper-curator 🔗 博客 - 《完整的 RAG 系统》
Sprint 6: 可观测性、缓存与前端闭环
目标：系统生产化准备，提升用户体验与运维能力。
-
Langfuse 集成实现完整可观测性
-
Prompt 版本管理与 A/B 测试框架
-
性能监控仪表盘
-
从问题到答案的请求追踪
-
便于交互的 Gradio 界面
-
针对常见查询的缓存层
-
生产部署配置
-
实现 LLM 应用的可观测性
-
数据驱动的 Prompt 优化
-
构建直观的研究界面
-
性能分析与优化
-
AI 系统的缓存策略
-
生产部署最佳实践
🔗 代码 - https://github.com/jamwithai/arxiv-paper-curator 🔗 博客 - 《生产就绪的 RAG：监控与缓存》
5. 非功能性需求设计考量
这里则侧重以下工程化特性：
- 韧性与容错：外部 API 调用（arXiv、LLM）必须具备重试和熔断机制；GROBID 解析失败时无缝降级到 Docling。
- 异步并发：所有涉及网络 I/O 和大文件处理的地方（如 PDF 下载、解析、LLM 推理），严格采用
asyncio提升吞吐量。 - 可评估性：RAG 系统最忌讳“感觉不错”。通过硬编码 RAGAS 指标评估集，确保每次架构调整（如分块大小变动）都有定量数据支撑。
- 隐私与安全：通过 Ollama 本地部署选项，确保敏感研究数据不出内网。
6. 后续演进路线
Arkhiv_RAG（阶段 1）作为基座支撑以下架构演进：
- 阶段 2 (Agent 化)：引入 LangGraph，将 RAG 作为 Tool，赋予系统多步推理、自我纠错和主动规划能力。
- 阶段 3 (推荐系统)：基于用户查询日志和文档向量空间，构建实时个性化推荐流。
- 阶段 4 & 5 (云原生与 MLOps)：剥离本地 Docker Compose，向 AWS/GCP 迁移，引入 Kubernetes 编排、CI/CD 流水线、模型微调流水线及 Prompt 工程平台。
- 阶段 6 (高可用监控)：构建基于数据漂移检测和 LLM 输出质量下降的自动化告警体系。
分享到社交平台
将本文分享给你的朋友们