MicrocosmWorks创新与构建数字宇宙
关于我们联系我们
MicrocosmWorks创新与构建数字宇宙

提供重要的IT解决方案。我们热衷于技术、安全,并通过可靠、创新的IT基础设施帮助企业成长。

[email protected]
+91 7011868196
New Delhi, India

AI增长中心

AI中心初创创新企业加速器

解决方案

所有解决方案健康与健身应用AI视频平台AI代理开发

资源

见解行业指南用例蓝图架构模式案例研究

公司

关于我们联系我们我们的工作

服务

数字咨询云基础设施SaaS 开发AI 开发视频技术
ERP 开发Zoho 定制Odoo 开发Salesforce 集成定制 CRM 开发
QuickBooks 集成物联网解决方案区块链开发
网络安全咨询IT 支持 - L3

© 2026 MicrocosmWorks. 保留所有权利。

隐私政策服务条款
返回架构模式
AI / DataAdvanced

RAG 流水线架构

让您的 LLM 无需微调即可访问您的数据。RAG 弥合了通用语言模型与领域特定知识之间的鸿沟。

June 22, 2026
|
2 topics covered
讨论此架构
rag-pipeline-architecture.webp
AI / Data
Category
Advanced
Complexity
Legal, Healthcare
Industries
2+
Technologies

何时需要它

您希望构建一个 AI 助手,能够回答关于您组织文档的问题——合同、政策、知识库、产品文档、医疗记录等。在您的数据上微调 LLM 成本高昂、耗时,并且会创建一个在训练时点上固化的模型。您需要一个架构,让 LLM 能够在查询时访问最新的、领域特定的信息,引用其来源,并避免“幻觉”出您的文档中不存在的事实。RAG(检索增强生成)就是实现这一目标的途径。

模式概述

RAG 通过从知识库中检索到的上下文来增强 LLM 的生成能力。在查询时,系统将用户的提问转换为 embedding,在 vector database 中搜索语义相似的 document chunks,并将最相关的 chunks 作为上下文包含在 LLM prompt 中。这使得模型的响应基于实际文档,支持来源引用,并使知识库无需重新训练即可更新。一个生产级的 RAG pipeline 处理 ingestion(解析、分块、embedding)、retrieval(vector search、reranking、hybrid search)和 generation(prompt 构建、streaming、guardrails)。

Related Architecture Patterns

Explore more design patterns and system architectures

scalable-vector-database-architecture.webp
AI / Data

可扩展向量数据库架构

当向量数量为 10K 时,嵌入式搜索很容易。但当向量数量达到 100M 且 P99 延迟要求低于 100 毫秒时,这就成了一个基础设施问题——而本模式正是为此而生。

EnterpriseView
ai-ml-pipeline-architecture.webp

常见问题

MicrocosmWorks 在 RAG 流水线中实现冲突解决,方法是通过来源权威排名、基于时间戳的近期加权以及评估每个检索到的段落对其主张支持强度的置信度评分。当检索到冲突段落时,我们的流水线会呈现最高权威的答案,同时透明地展示分歧和来源引用,以便用户做出知情决策。我们还建立反馈循环,领域专家可以在其中标记不正确的解析结果,从而随着时间的推移提高检索排名。

MicrocosmWorks 采用内容感知 chunking,根据文档结构应用不同的策略——对于散文采用语义段落拆分;对于表格采用行级或节级 chunking,并保留表头上下文;对于代码采用函数级 chunking,并附带 import 语句。我们为每个 chunk 丰富元数据,包括文档标题、章节层级和内容类型,以便检索阶段可以应用类型特定的评分。在我们的客户项目中,这种方法在检索相关性基准测试中持续优于朴素的固定大小 chunking 25-40%。

MicrocosmWorks 构建评估工具,用于从三个维度测试 RAG 管道:检索相关性(是否找到了正确的块)、答案忠实性(生成的答案是否真实反映了检索到的内容)和答案完整性(是否回答了整个问题)。我们与领域专家一起创建黄金测试集,其中包含已知答案查询、对抗性边缘案例以及需要多文档综合的问题。此评估在 CI/CD 中自动运行,因此在部署之前,每次管道更改都会根据基线质量指标进行基准测试。

MicrocosmWorks 根据您的规模、查询模式和操作要求选择向量数据库——Pinecone 适用于托管式简单性,Weaviate 适用于混合关键字-向量搜索,pgvector 适用于已投入使用 PostgreSQL 的团队,Qdrant 适用于高吞吐量自托管部署。在低于 1000 万向量的规模下,大多数选项都能提供低于 100 毫秒的延迟,但在数亿向量的规模下差异变得显著,在这种情况下,索引类型、量化和分片策略至关重要。我们将在架构设计阶段根据您的实际嵌入维度和查询模式对入围选项进行基准测试。

MicrocosmWorks 构建增量摄取管道,这些管道监控源文档存储库的变化,仅对修改过的部分进行重新分块和重新嵌入,并更新 vector store,而无需进行完整重新索引。我们实施文档指纹识别技术,在章节级别检测内容变化,因此单个段落的编辑不会触发重新处理整个 200 页的文档。对于具有实时新鲜度要求的客户,我们增加一个实时检索层,直接查询源系统以获取最近修改的文档,并将这些结果与 vector search 匹配项合并。

需要帮助实现此架构吗?

我们的架构师可以帮助您根据您的具体要求设计和构建使用此模式的系统。

联系我们

参考架构

该架构包含两个 pipeline。ingestion pipeline 通过解析(PDF、DOCX、HTML 提取)、分块(语义或固定大小带重叠)、embedding(通过 embedding model)和存储(vector database + document store)来处理文档。query pipeline 接收用户问题,生成 query embedding,从 vector database 中检索候选 chunks,重新排序以提高相关性,用最佳 chunks 作为上下文构建 prompt,并流式传输带有来源引用的 LLM 响应。

核心组件:
  • 文档摄取流水线(Document Ingestion Pipeline):多格式解析器(Apache Tika, Unstructured, 或自定义)从 PDF、DOCX、HTML、Markdown 和扫描图像(OCR)中提取文本。分块策略将文档拆分为可检索的单元——MW 默认采用语义分块(在段落/章节边界处拆分),目标大小为 512-token,重叠部分为 50-token。
  • Embedding 服务:将文本块转换为 vector embeddings。使用 OpenAI text-embedding-3-large, Cohere embed-v4 等模型,或开源替代方案(BGE, E5)。摄取时采用批量处理,搜索时采用单查询处理。
  • 向量数据库(Vector Database):存储带元数据的 embeddings 以进行过滤搜索。支持大规模的 approximate nearest neighbor (ANN) 搜索。有关生产规模的考量,请参阅可扩展向量数据库架构。
  • 检索与重排序(Retrieval & Reranking):两阶段检索——快速 ANN 搜索返回前 50 个候选,然后 cross-encoder reranker(Cohere Rerank, BGE Reranker, 或 ColBERT)根据查询对每个候选进行评分,以实现精确的相关性排序。排名前 5 的 chunks 将发送给 LLM。
  • 混合搜索(Hybrid Search):将向量(语义)搜索与关键词(BM25)搜索相结合。这解决了向量搜索可能遗漏精确术语(产品代码、法律条款、医学术语)的情况,而关键词搜索在这方面表现良好。Reciprocal rank fusion 合并这两个结果集。

设计决策与权衡

分块策略:固定大小 vs. 语义 vs. 文档结构。固定大小分块(每 N 个 token 拆分)简单,但在句中可能打断,并丢失文档结构。语义分块(在自然边界处拆分——段落、节、标题)保留上下文,但产生大小可变的块。文档结构分块(尊重文档的层次结构——章、节、小节)最适合法律合同或技术手册等结构化文档。MW 默认采用语义分块,对于高度格式化的源则切换为文档结构分块。 向量搜索 vs. 混合搜索。纯向量搜索对于对话式查询(“我如何处理退款?”)效果良好,但对于精确匹配查询(“条款 7.3.2 是什么?”)则会失效。混合搜索(向量 + BM25 关键词)可以同时处理这两种情况。MW 推荐对任何具有特定术语、代码或标识符的领域使用混合搜索——这涵盖了大多数企业领域。额外增加 10-15% 的复杂性,换来显著的相关性提升是值得的。 重排序:Cross-Encoder vs. 无。 Cross-encoder reranking 会增加 100-300 毫秒的延迟,但显著提高了检索精度——我们测量到在法律和医疗保健领域,前 5 名相关性提升了 15-25%。MW 默认包含 reranking,适用于任何回答质量比亚秒级延迟更重要的 RAG 系统。对于对速度要求极高的聊天机器人,我们跳过 reranking,并通过更好的分块和 prompt engineering 进行补偿。 单向量 vs. 多向量(ColBERT 风格)。单向量 embeddings 更简单,存储/搜索成本更低。多向量表示(每个 token 一个向量,后期交互评分)能捕捉更多细微差别,但需要专门的基础设施。MW 大多数部署使用单向量,并将多向量保留给检索质量是瓶颈且文档语料库超过 10 万个 chunks 的领域。

技术选择

层级技术
文档解析Unstructured, Apache Tika, LlamaParse, Docling, 自定义 OCR (Tesseract, AWS Textract)
EmbeddingOpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2
向量数据库(Vector Database)Milvus, Pinecone, Qdrant, Weaviate, pgvector (适用于小型规模)
关键词搜索Elasticsearch, OpenSearch, PostgreSQL full-text search
重排序(Reranking)Cohere Rerank, BGE Reranker, ColBERT v2, FlashRank
LLMClaude (通过 AI Gateway), GPT-4, Gemini — 通过 AI SDK 实现供应商无关性
编排LangChain, LlamaIndex, 或自定义 pipeline (MW 推荐用于生产环境)

何时使用 / 何时避免

使用情景避免情景
用户需要基于您组织特定文档的答案知识库少于 50 页——直接将其放入系统 prompt 中即可
文档频繁更新,AI 需要最新信息您需要模型学习新技能/行为,而不是获取新事实(请选择微调)
需要来源引用和可审计性(法律、合规、医疗保健)问题纯粹是对话性质,不需要事实依据
多个用户组需要访问不同的文档子集(权限过滤 RAG)您正在构建一个创意写作工具,其中事实准确性并非目标

我们的方法

MW 从检索质量出发构建 RAG pipeline——在触及 LLM prompt 之前,我们会对检索精度进行基准测试。一个检索效果平庸但 LLM 优秀 的 RAG 系统会产生听起来自信但错误的答案。我们的标准 pipeline 包含一个检索评估工具:一组带有已知相关文档的测试查询,通过 MRR@5 和 NDCG@10 进行衡量。我们迭代优化分块、embedding model 和 reranking,直到检索指标达到目标阈值,然后再优化生成。我们已经在法律文档审查、医疗保健知识库和多语言客户支持等领域构建了 RAG 系统——共同的经验是,检索质量占答案质量的 80%。

相关蓝图

  • AI 客户支持代理 — 采用 RAG 技术,具备知识库检索能力的客服代理
  • AI 文档处理流水线 — 文档摄取、解析和 AI 驱动的提取

相关行业指南

  • 法律领域的 AI — RAG 在合同审查和法律研究中的应用

相关案例研究

  • 文档智能 — 用于电子表格和文档分析的本地 RAG pipeline
  • AI 聊天平台 — 具备文档检索和符合 GDPR 标准数据处理的多模型聊天
Related Technologies
AI DevelopmentSaaS Development
AI / Data

AI/ML 管道架构

模型无法自行运行。训练、验证、部署和监控模型的管道才是实际产品——模型只是其中一个产物。

EnterpriseView
multi-tenant-saas-architecture.webp
Application

多租户 SaaS 架构

一个代码库,数百个租户,零数据泄露——每个可扩展 SaaS 业务的基础。

AdvancedView