您希望构建一个 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)。
Explore more design patterns and system architectures
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 响应。
核心组件:text-embedding-3-large, Cohere embed-v4 等模型,或开源替代方案(BGE, E5)。摄取时采用批量处理,搜索时采用单查询处理。| 层级 | 技术 |
|---|---|
| 文档解析 | Unstructured, Apache Tika, LlamaParse, Docling, 自定义 OCR (Tesseract, AWS Textract) |
| Embedding | OpenAI 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 |
| LLM | Claude (通过 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%。
模型无法自行运行。训练、验证、部署和监控模型的管道才是实际产品——模型只是其中一个产物。