从51%企业用RAG的现状出发,对比开源编排框架与托管服务的优劣,覆盖摄取、分块、嵌入、检索、重排全流程。
Menlo Ventures 在《2025 年生成式 AI 现状报告》中调查了近 500 名美国企业决策者:在已投入生产的 LLM 部署中,51% 使用了检索增强生成(RAG),而采用微调的只有 9%。超长上下文窗口并没有杀死 RAG。真正被淘汰的是朴素的“切块后检索”流水线;到了 2026 年,检索正日益成为一种由 Agent 按需调用的行为。与此同时,企业 AI 中已有 76% 选择购买而非自建,托管式 RAG 服务也因此开始与开源框架直接竞争。
我在 DevToolLab 上发布了这份指南的完整版本:《2026 年最佳 RAG 平台与工具》。这篇精简版只讨论编排层——摄取、切块、Embedding、检索、重排序和生成——不涉及底层的向量数据库,因为后者本身就是一项独立的技术选型。
所有 RAG 系统都遵循相同的六个步骤:摄取文档,解析并切块,将文本块 Embedding 为向量,根据查询检索相关内容(通常采用稠密检索与 BM25 结合的混合检索),对候选结果重新排序,最后生成带引用的回答。
框架为你提供可组合的组件和完整的控制权;托管平台则把这些步骤隐藏在“上传后提问”的 API 背后。这就是自建与购买之间的全部取舍。

当数据处理是最棘手的问题时,LlamaIndex(MIT,约 5.1 万颗星,2026 年 6 月完成 1900 万美元 A 轮融资)最具优势。LlamaHub connectors、LlamaParse parser 和 LlamaCloud 共同构成了这里最强大的数据摄取方案,而 Workflows 则负责 Agentic 编排。代价在于:它的 API 覆盖面庞大、变化很快,而且开源框架与 LlamaCloud 之间的边界有时并不清晰。
LangChain 和 LangGraph(MIT,约 14.2 万颗星,二者均于 2025 年 10 月发布 1.0 版本,已按约 12.5 亿美元估值融资 1.25 亿美元)拥有规模最大的集成生态。对于由模型决定是否检索、检索什么,并能循环执行和重新表述查询的 Agentic RAG,LangGraph 是自然而然的选择。LangSmith 则负责链路追踪。针对简单场景的长期批评依然成立:一条普通的“先检索、再回答”流水线并不需要这么多机制。

deepset 推出的 Haystack(Apache 2.0,约 2.6 万颗星)将 RAG 建模为显式 Pipelines 中具有类型定义的 Components,并提供异步运行时、YAML 序列化和内置评估能力。如果说 LangChain 给人的感觉像是用于 Notebook 的胶水代码,那么 Haystack 更像是可以直接部署的软件。它的社区规模较小,教程也更少。
Stanford NLP 推出的 DSPy(MIT,约 3.6 万颗星)是真正与众不同的那个:你只需声明带有输入/输出签名的模块,再让 MIPROv2 和 GEPA 等优化器编译 prompt 与 few-shot 示例。你不再需要手动调试 prompt,而是开始优化程序。它确实存在学习曲线;如果只是做一个演示,则有些杀鸡用牛刀。
txtai(Apache 2.0,约 1.27 万颗星)把向量索引、图索引、关系索引、RAG 和 Agent 打包进同一个库——不必再单独运行向量数据库。R2R(MIT,约 7900 颗星)则是一款可部署的 RAG 服务器,通过 REST 提供数据摄取、混合搜索、知识图谱和 Agentic 检索能力。二者都以较小的社区规模换来了更简单的配置体验。

Bedrock Knowledge Bases 是 AWS 上的默认选择:基于 Neptune Analytics 的 GraphRAG 已于 2025 年 3 月正式可用,而 re:Invent 2025 又增加了多模态检索(文本、图像、音频和视频)、S3 Vectors 存储以及 text-to-SQL 结构化检索能力。
Vertex AI RAG Engine 是 GCP 上的对应产品,与 Gemini 深度绑定,提供 serverless 模式,并支持可插拔的向量后端,包括 Pinecone 和 Weaviate。
Azure AI Search 拥有一流的混合搜索和语义排序能力,其 Agentic 检索功能——由 LLM 拆解并行子查询——已通过 2026-04-01 REST API 正式可用。不过,它是一个检索引擎,而不是端到端应用。
Pinecone Assistant 于 2026 年 2 月正式可用:上传文档后,即可通过 Chat API 获得有依据、带引用的回答,并且内置评估能力。
Contextual AI 由 RAG 论文共同作者 Douwe Kiela 创立,已融资约 1 亿美元。它通过联合优化检索器与生成器,即所谓的“RAG 2.0”,服务于受监管行业的知识工作。
关于创业公司,还有一个警示案例:面向开发者的托管式 RAG 服务 Ragie 宣布将于 2026 年 7 月 19 日停止运营。托管平台能帮你卸下基础设施工作,但小型供应商也可能直接把自己从市场上“卸载”掉。
无论使用什么平台,有三类工具都能可靠地提升 RAG 准确率。
重排序器(Cohere Rerank、现已并入 MongoDB 的 Voyage AI)往往是整条流水线中成本最低、效果最明显的准确率提升手段。
文档解析决定了下游的一切:IBM 的 Docling(约 6.3 万颗星,由 Linux Foundation 托管)免费且可在本地运行;Unstructured 支持的格式最多;LlamaParse 和 Reducto 则擅长处理复杂表格与扫描件。
评估让优化形成闭环:Ragas 无需标注数据,就能评估忠实度以及上下文的精确率/召回率;TruLens(Snowflake)还增加了链路追踪能力。
检索质量早在任何模型运行之前,就已经由切块步骤决定了。带重叠区域的固定大小文本块是一个稳妥的默认方案,而重叠区域可以确保位于文本块边界上的句子仍与其上下文保持关联。核心逻辑只需要一页不依赖第三方库的 Python 代码:
def chunk_text(text, chunk_size=200, overlap=40):
"""Split text into overlapping word chunks for embedding."""
if overlap >= chunk_size:
raise ValueError("overlap must be smaller than chunk_size")
words = text.split()
step = chunk_size - overlap
chunks = []
for start in range(0, len(words), step):
chunk = words[start:start + chunk_size]
if chunk:
chunks.append(" ".join(chunk))
if start + chunk_size >= len(words):
break
return chunks
生产系统会按照句子或语义边界进行切分,并根据 token 数量而不是单词数量确定文本块大小,但这就是每条流水线最先执行的操作形态。
调整文本块大小时,DevToolLab 的 AI Token Counter 可以检查检索到的上下文究竟有多少能放进模型的上下文窗口;Cosine Similarity Calculator 则可以帮助你快速验证向量存储在大规模运行时使用的相似度计算是否合理。
Agentic RAG 如今已成为主流模式——它是 Azure AI Search、Vertex RAG Engine、R2R 以及所有 LangGraph Agent 中的一等能力。
今年,多模态 RAG 已在托管平台中全面普及。由 Microsoft 开源项目推广开来的 GraphRAG,也已经在 Bedrock 中实现产品化。
而随着“购买优先于自建”的浪潮不断增强,对许多团队来说,最诚实的起点就是选择托管平台,只有在遇到平台能力瓶颈时,才转向框架。
没有投入基础设施的意愿:选择现有云平台上的托管服务(Bedrock、Vertex、Azure AI Search 或 Pinecone Assistant)。
PDF 混乱、数据源众多:选择 LlamaIndex。
重视生产严谨性和可测试的流水线:选择 Haystack。
需要带循环和 human-in-the-loop 的 Agentic 检索:选择 LangGraph。
需要系统化优化准确率:选择 DSPy。
需要轻量级且可自托管:选择 txtai;如果需要 REST API,则选择 R2R。
无论选择什么,真正决定系统是否值得信赖的,都是平台无法替你负责的部分——解析质量、切块、重排序器和评估闭环。完整指南对每款工具进行了更深入的介绍,包括融资详情、功能演进时间线以及完整的决策框架。
DevToolLab 上的原始文章
Menlo Ventures:《2025 年企业生成式 AI 现状》
LangChain 和 LangGraph
Amazon Bedrock Knowledge Bases
Docling 和 Microsoft GraphRAG
如需采取进一步行动,你可以考虑屏蔽此人和/或举报滥用行为。