一、为什么需要RAG
在大模型实际落地的时候，存在一些问题，主要集中在以下方面：
缺少垂直领域知识：虽然大模型压缩了大量的人类知识，但在垂直场景上明显存在短板，需要专业化的服务去解决特定问题。 存在幻觉、应用有一定门槛：在大模型使用上有一些幻觉、合规问题，没有办法很好地落地，配套工作不足，缺乏现成的方案来管理非结构化文本、进行测试、运营和管理等。 存在重复建设：各业务孤立摸索，资产无法沉淀，存在低水平重复建设，对公司来说ROI低，不够高效。 ...
RAG的出现，标志着LLMs从静态知识库向动态、自适应系统转变的关键一步。LLMs在处理知识密集型任务时，其固有的静态知识限制（如幻觉和知识过时）促使业界寻求一种能够注入实时、外部和可验证信息的方法。RAG正是这种需求的直接产物，它作为一项重要的架构创新，弥合了预训练的静态知识与不断演进的现实世界信息之间的鸿沟。这种能力使得LLMs能够更好地应对不断变化的信息环境，并提供更可靠的响应。
24年的ChatGLM的一次调研：
RAG的核心思想
定义：RAG是一种将外部知识库的检索（Retrieval）与大语言模型的生成（Generation）能力相结合的技术范式。
通俗比喻：让LLM“开卷考试”，而不是“闭卷考试”。在回答问题前，先去指定的资料库里查找相关信息，然后基于这些信息来组织和生成答案。
核心优势：
提升事实准确性：答案基于提供的上下文，有效减少幻觉。
知识动态更新：只需更新外部知识库，即可让模型掌握最新信息，成本远低于重新训练模型。
增强可信度与可解释性：可以展示答案的来源（引用），用户可以自行核实。
二、RAG核心组成与通用设计
一个完整的RAG系统通常包含两个核心流程：数据准备（离线）和推理检索（在线）。
RAG的核心接口，RAAS，(Rag As a Service)提供的接口，当然平台能力更强的可以支持自定义模型、自定义分片等。但是核心就是构建和召回；
也可以参考Google 的 RAG API：https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/rag-api?hl=zh-cn#retrieval-query-api
创建文档(构建索引)， 架桥修路的感觉
格式要丰富，文本、音频、视频； 数据清洗、预处理、切分
索引要好：嵌入模型、元数据、分层索引、图；
理想轻快：速度要快、成本要低、效果要好；
速度和效果有个折中；
检索文档(使用索引)，问题本质上是一个经典的精确率（Precision）与召回率（Recall）的权衡。
查询模糊性：读者问：“我想找本关于那只蓝色鸟的书。”专家需要理解，读者指的是神话里的青鸟、一部叫《蓝鸟》的小说，还是一本关于蓝鸟生物习性的科普读物？（Query Transformation）
大海捞针：专家定位到“鸟类科普”区，书架上有一百本关于鸟的书，其中几十本都提到了蓝色羽毛的鸟。专家需要快速浏览，找出专门讲“蓝鸟”的那几本，而不是讲“蓝孔雀”或“蓝鹦鹉”的书。（Re-ranking）
上下文碎片化：专家发现，关于蓝鸟的栖息地在A书的第5章，它的食性在B书的第2章，它的迁徙路线在一张地图C上。他需要把这三份资料都找出来给读者，才能完整回答问题。（Context-Enriched Retrieval）
最佳数量：专家是应该只拿最核心的一本书，还是把相关的十本书都拿过来？拿太多读者会晕，拿太少又怕信息不全。他需要做一个专业的判断。（Dynamic k）
三、一些优化RAG系统的方法
构建：Parsing解析
“垃圾进，垃圾出 (Garbage In, Garbage Out)
如果从一开始就无法准确、完整地从原始文件中提取信息并进行清洗，那么后续所有的努力（分块、嵌入、检索）都建立在一个摇摇欲坠的基础上。
这个阶段的任务不是简单地把文件里的字“抠”出来，而是要模拟人类阅读文档的方式，理解其结构、清理无关信息，并处理非文本内容。
解决方案：使用能够理解文档视觉布局和文档对象模型 (DOM) 的现代解析工具。核心工具推荐：
unstructured.io：一个强大的开源库，能将 PDF、HTML、Word 等文档解析成一系列带有类型标签的“元素”（如 Title, NarrativeText, ListItem, Table）。这是目前业界的首选之一。 LlamaParse：由 LlamaIndex 团队开发，专门针对复杂 PDF 进行优化，尤其擅长提取嵌入式表格和复杂布局。 PyMuPDF：一个更底层的库，提供了精细控制 PDF 元素提取的能力，适合需要高度定制化的场景。 LangExtract：Google 开发的一个 Python 库，用于从非结构化文本中提取结构化信息。它利用大语言模型（LLMs）来识别和组织文本中的关键信息，并能精确定位提取内容在原文中的位置。
这里也可以训练一些文档布局模型，参考：https://www.textin.com/
| 类别 (Category) | 技巧/策略 (Technique/Strategy) | 核心问题 (Core Problem) | 解决方案与核心操作 (Solution & Key Action) |
|---|---|---|---|
| 按文件类型加载 | 处理 PDF 文件 | 区分文本型与扫描型 | |
| 处理 HTML/网页 | <main>,<article>等核心内容标签，剔除噪声。 | ||
| 处理结构化数据 (CSV/JSON) | Laptop,999）对语言模型不友好，缺乏语义。 | 转化为自然语言 | |
| 通用预处理 | 精细化文本清洗 | 规范化文本 | |
| 表格转化 | 转化为 Markdown 格式 | ||
| 图像/图表处理 | |||
| 元数据绑定 | 为每个块附加“身份证” |
构建：Chunk切分
| 分段方式 | 工作原理 | 比喻 |
|---|---|---|
| 固定长度 (Fixed-Size) | ||
| 递归字符 (Recursive) | ||
| Agentic Chunking | 一位学识渊博的图书管理员 |
线上主流还是递归分段为主，保持段落的长度256~1024 个字符，看场景：线上一般也会配合Context Expand。
对于需要精确、事实性回答的场景（如Q&A）：倾向于使用更小的尺寸，如256-512。 对于需要更丰富上下文、进行总结或推理的场景（如分析报告）：倾向于使用更大的尺寸，如512-1024。
可以自己跑评估脚本，在相同的Context长度下，什么字符扩大几个窗口可以达到最好的效果。比如context总长度在10000的时候，chunk多少合适，expand几个窗口合适。
实验表明，512的块大小在忠实度（Faithfulness）和相关性（Relevancy）上表现最佳。在嵌入模型选择上，LLM-Embedder在性能上与更大的bge-large相当，但模型尺寸小得多，是性能和效率的绝佳平衡点。
https://arxiv.org/pdf/2407.01219#page=9.46
构建：嵌入模型
所有涉及到模型的肯定都要考虑下性能RT、效果：
如何选择一个Embeding模型：https://weaviate.io/blog/how-to-choose-an-embedding-model
| 决策因素 (Decision Factor) | 核心问题 (Key Question) | 推荐做法 (Recommended Action) |
|---|---|---|
| 1. 性能与准确率 | 查阅MTEB排行榜 | |
| 2. 成本 | 快速验证/原型阶段 | |
| 3. 领域适应性 | 优先选择可微调的开源模型 | |
| 4. 语言支持 | 单一语言应用 | |
| 5. 速度与延迟 | largevs.small模型）。 | |
| 6. 隐私与控制权 | 处理敏感数据 |
Embeding模型选择的路径：
从开源开始：对于大多数正式项目，建议从一个顶级的开源模型开始，例如BGE系列。它在性能和成本之间取得了绝佳的平衡。隐私安全性、速度和延迟、领域特性、成本、效果通过开源都可以做到非常好的地步。 MTEB榜单：访问 Hugging Face MTEB Leaderboard，查看最新的模型排名和性能数据。 建立自己的评估集：公开榜单是通用参考，但无法完全代表你的特定场景。建立一个小的、能代表你核心业务问题的评估集，用它来测试不同模型的实际效果，这是最可靠的方法。 考虑微调：如果通用模型在你的专业领域表现不佳，不要轻易放弃。投入资源对一个优秀的开源模型进行微调，往往能带来惊人的性能提升，是通往专业级RAG应用的必经之路。
为什么近期大厂都在做Embedding模型？
如果说大型语言模型（LLM）是AI时代的“大脑”，那么Embedding模型就是连接这个“大脑”与现实世界海量信息的“神经网络”和“感官系统”。大厂们意识到，谁掌握了最高效、最精准的Embedding技术，谁就控制了AI应用落地的“咽喉要道”。
大厂们集体下场“卷”Embedding模型，是一场围绕AI时代核心基础设施的“圈地运动”。它们不仅仅是在竞争一个技术工具，更是在争夺未来十年AI生态的主导权、话语权和商业入口。而“刷榜”则是这场激烈竞争中，最耀眼的“广告牌”和最直接的“战报”。
战略层面：抢占AI生态的“入口”和“基础设施”：Embedding是构建几乎所有高级AI应用的第一步。一旦开发者习惯了你的Embedding模型，极大概率会继续使用你生态中的LLM、向量数据库和云服务，形成强大的生态锁定。它正在成为AI原生时代的基础设施，控制了它，就等于控制了信息的表示和流动方式。
应用层面：RAG爆发成为直接催化剂：RAG是目前公认的LLM企业落地最佳路径。而RAG系统的核心瓶颈在于检索（Retrieval）的质量，检索质量又几乎完全取决于Embedding模型的性能。优化Embedding这个RAG系统的“发动机”，能带来立竿见影的效果提升。 商业层面：“卖铲子”的稳定生意：在AI的“淘金热”中，提供Embedding模型就像是“卖铲子和牛仔裤”——高频、刚需。无论是通过API按量收费，还是通过开源模型吸引用户上云，都能产生持续且稳定的现金流，是一门清晰的商业模式。 技术层面：构建“护城河”和“数据飞轮”：顶级的Embedding模型需要海量高质量的训练数据和深厚的训练经验，这构成了强大的技术护城河。更多用户使用模型，就能收集到更多真实世界的数据，用于迭代优化，形成自我强化的数据飞轮，让强者恒强。 起点：从高质量的基础分段开始，配合一个顶级的Embedding模型。 第一步优化：引入提取QA对。这是投入产出比最高的一项深度加工，能快速提升核心问答场景的效果。 针对性优化： 如果你的RAG系统主要处理长文档，且用户经常需要总结或在文档中导航，那么构建摘要树是你的首选。 如果你的应用需要回答“谁和谁是什么关系”这类复杂问题，那么投入资源构建知识图谱将是你的“杀手锏”。 精细化优化：当你对检索的精准度有极致要求时，可以尝试命题化分块。 HoloGress：可以同时存储关系型数据以及向量数据库；SQL查询和向量召回； OpenSearch：同时支持向量召回和关键词召回； 多路查询（Multi-Query）：让LLM将用户的单个复杂问题分解成多个角度的子问题，然后分别对这些子问题进行检索，最后合并结果。这能有效提升召回的全面性。
退步提示（Step-Back Prompting）：引导LLM从具体问题回退到更高层次的概念性问题，同时对两者进行检索，可以获得更丰富的上下文。
HyDE（Hypothetical Document Embeddings）：先让LLM针对用户问题生成一个“假设性”的答案，然后用这个假想答案的向量去检索文档。这种方法通常能更好地捕捉到问题的核心语义。
HyDE的核心思想是：在向量空间中，“答案”与“答案”之间的语义相似度，比“问题”与“答案”之间的相似度更高。因此，它先将你的“问题”（Query）变成一个“伪答案”（Hypothetical Document），再用这个伪答案去寻找真正的答案。
但是，只用伪答案可能会丢失原始问题中的一些精确意图。因此，一个更优化的做法是将两者结合。将单个伪文档和原始Query结合（
w/ 1 pseudo-doc + query）的配置，在两个测试集上的nDCG@10指标都明显高于仅使用伪文档的配置。不是越多越好：生成8个伪文档虽然性能也不错，但延迟大幅增加，得不偿失。**查询扩展：**让LLM为原始问题生成一系列相关的同义词、下位词或相关概念，扩展查询的覆盖面。用户问“AI裁员”，LLM可以扩展为“人工智能对就业市场的影响”、“自动化导致的岗位缩减”、“科技行业的人员结构调整”等，然后将这些关键词加入到原始查询中。主要解决 “词汇不匹配” 的问题。用户用的词和文档里的词可能不一样。 稀疏检索（Sparse Retrieval）: 以传统的关键词匹配为基础，如BM25算法。它的优势在于能精确匹配关键词和术语，对于包含特定实体或专业名词的查询非常有效。 稠密检索（Dense Retrieval）: 以基于深度学习的向量嵌入为基础，如论文中推荐的LLM-Embedder模型。它的优势在于能理解查询的语义和意图，即使关键词不完全匹配，也能找到意思相近的内容。 Sh是最终的混合检索相关性分数。Ss是经过归一化的稀疏检索（BM25）分数。Sd是经过归一化的稠密检索（向量相似度）分数。α是一个超参数，用于控制稀疏检索的权重，是调优的关键。基于深度语言模型的重排序 (DLM Reranking)：核心思想：这类方法将重排序视为一个分类任务。它们将“查询”和“待排序的文档”拼接在一起作为输入，然后让一个深度语言模型来判断该文档与查询是否相关（例如，预测输出为 "true" 或 "false" 的概率）。最后根据这个相关性概率对文档进行排序。 基于查询似然性的重排序 (TILDE Reranking)：核心思想：TILDE（Term-In-Last-Decoder-output-space Expansion）是一种追求极致效率的方法。它不直接计算查询和文档的整体相关性，而是预先计算出每个查询词（term）在文档中出现的可能性（log probabilities），在排序时只需将查询中所有词的似然性分数相加即可，速度极快。 对于大多数项目（尤其是初创项目）： 从 **BAAI/bge-reranker-large**开始。它是在性能、成本和灵活性之间取得了最佳平衡的开源模型，足以满足绝大多数高质量RAG的需求。当性能遇到瓶颈或需要更广泛的语言支持时： 评估 **Cohere Rerank API**。如果预算允许，它提供的顶尖性能和易用性是解决问题的最快途径。当部署成本是首要考虑因素时： 可以降级使用 **BAAI/bge-reranker-base**。它比large版本更小、更快，虽然性能略有下降，但性价比极高。**forward**(正向): 按照重排序后的相关性分数从高到低排列。这意味着最相关的文档放在上下文的最前面。**reverse**(反向): 按照相关性分数从低到高排列。这意味着最相关的文档被放在上下文的最后面，紧邻着用户的问题。**sides**(两侧): 这是一个受“迷失在中间”理论启发的策略，它将最相关的文档放在上下文的开头和结尾，而将次要的文档放在中间。灵活性高（可自定义）： 评估模型随便换：你可以指定任何大语言模型（开源的、商业的都行）来当“裁判”打分。 Embedding模型随便换：你可以换成自己系统正在用的 Embedding 模型，让评估更公平。 结果好用（易分析、易展示）： 方便导出：评估分数能一键变成 Pandas表格，方便保存和分析。方便作图：有了表格，就能轻松画出各种对比图，直观地看出哪个方案更好。 想提高精确度？把搜索条件设得非常严格。结果是返回的东西很少，但都很准。缺点是可能会漏掉很多相关的。（就像用一个非常小的渔网，只能捞到特定大小的鱼，但肯定不会捞到垃圾，同时也错过了湖里其他大小的目标鱼）。 想提高召回率？把搜索条件设得非常宽松。结果是返回了一大堆东西，确保所有相关的都在里面了。缺点是也包含了很多不相关的垃圾。（就像用一张巨大无比、网眼又密的渔网，把湖里所有目标鱼都捞上来了，但也捞上来了整片湖的水草）。 准备数据：准备好 问题和标准答案。运行系统：用你的 RAG 回答问题，并记下 答案和引用的原文。自动打分：把上面两步的东西扔给 RAGAS，让它自动评分。 分析优化：看分数，哪里分低就优化哪里。
当然感觉算法同学也很喜欢自己训练模型，Embeding模型的进步还是比较快的。
构建：Indexing
在RAG的构建（Indexing）阶段，我们的目标不仅仅是存储信息，更是以一种“机器友好”的方式理解和重构信息。简单的分段处理保证了知识的“原子性”，而深度加工则在此基础上，构建了知识之间的“关联性”和“层次性”，为后续的检索和生成环节提供了质量极高的“弹药”。
核心思想：从“原始文本”到“结构化知识”
基础分段处理的是“原始文本块”，而深度加工旨在从这些文本块中提炼出“结构化知识单元”。这些单元可以是任何形式，只要它比原始文本更精炼、更具指向性。
在实践中，并不需要一开始就实现所有复杂的加工技术。一个务实的优化路径是：
| 加工技术 | 核心思想 | 解决的关键问题 | 适用场景与特点 |
|---|---|---|---|
| 提取QA对 | |||
| 构建摘要树 | |||
| 构建知识图谱 | 主语-谓语-宾语的三元组）。例如，从“埃隆·马斯克创立了SpaceX”中提取出(埃隆·马斯克) -[创立了]-> (SpaceX)。 | ||
| 命题化分块 |
这里数据库层面：
召回：Query改写
论文：https://arxiv.org/pdf/2407.01219
用户的问题可能是模糊的、复杂的、或使用了与文档不同的词汇，改写就是为了生成一个或多个对搜索引擎更友好的查询。解决用户原始问题与知识库文档之间可能存在的表述不一致或信息不足的问题。
| 策略 | 优缺点 | 权衡点 (Trade-off) | 适用场景 |
|---|---|---|---|
| 多路查询 (深入细节) | 成本/延迟 | 对比类问题 | |
| 退步提示 (高维视角) | 答案深度 | 技术/科学问题 | |
| HyDE (假设答案) | 高相关性 | 零样本问答 | |
| 查询扩展 (纠正问题) | 召回全面性 | 口语化/非正式提问错别字或术语不当 |
召回：混合检索(多路召回)
混合检索的核心思想是结合两种不同类型的检索技术的优势，以实现比单一技术更优越的检索效果。具体来说，它融合了：
通过结合两者的长处，既能保证关键词的精确匹配，又能捕捉语义上的相关性，从而全面提升检索结果的准确率和召回率。
计算公式:Sh = α · Ss + Sd
实验结果表明，当α设置为0.3时，混合检索在各项指标上综合表现最好。这说明在LLM-Embedder和BM25的组合中，给予稠密检索更高的权重，同时用稀疏检索作为补充，是最佳策略。
混合检索还可以与另一种查询增强技术HyDE（生成假设性文档）结合。实验表明，HyDE + Hybrid Search的组合是所有检索方法中的性能王者，在TREC DL19上的nDCG@10分数达到了73.34，是所有配置中的最高分。但它也带来了最高的计算延迟。对答案质量要求极高，可以容忍更高延迟的离线分析、报告生成等任务。可以考虑使用HyDE + Hybrid Search。
混合检索是一个强大且值得默认采用的检索策略，可以在性能上对系统不产生影响的情况下，仍然能够提升检索的效果。
召回：重排序(Re-ranking)
初步检索为了速度和召回率，可能会返回一些不那么相关的文档。重排序的作用就是利用更精确但计算更密集的模型，对这一小批候选文档（例如前50或100篇）进行重新打分和排序，确保最相关的信息被优先提供给后续的大语言模型
两种类型的Rerank模型：
绝大多数都属于“基于深度语言模型（DLM-based）”的方法，在Rerank这个环节，我们处理的通常只是初步检索返回的几十个候选文档，而不是整个知识库，因此这个计算开销在很多场景下是完全可以接受的。
关于如何选择一个合适的Rerank模型：
| 模型系列/服务 | 主要优势 | 适用场景 | 注意事项 |
|---|---|---|---|
BGE Reranker 系列bge-reranker-large,bge-reranker-base) | 开源首选，性能强大large版本。中英双语支持好：对中文和英文的排序效果都经过了大量验证。商业友好：通常采用Apache 2.0许可证。 | large（效果最好）或base（更轻量）版本。 | |
Cohere Rerank APIrerank-english-v3.0,rerank-multilingual-v3.0) | 业界顶尖性能multilingual版本支持超过100种语言。 | ||
| Voyage AI Rerank API | 新兴的强大API | ||
其他开源模型jina-reranker,mxbai-embed-large) | 提供多样化选择 |
召回：重打包(Repacking)
LLM在处理长上下文（long context）时，对位于上下文开头和结尾部分的信息注意力最高、利用得最好，而对放在中间部分的信息则容易忽略或“忘记”。
即使我们已经通过Reranking找到了最相关的文档，如果随意地将它们拼接起来，最重要的信息可能会不幸地落在LLM的“注意力盲区”里，从而影响最终生成答案的质量。Document Repacking 的目的就是通过策略性地排布文档顺序，将最关键的信息放在LLM最“舒适”的位置。
三种不同的文档排布策略：
将最相关的文档放在上下文的最末尾，使其最接近最终的生成指令或问题，对LLM的性能提升最大。这可能是因为模型在生成答案时，会最优先关注离它“最近”的上下文信息。
四、端到端的评估
常用评估框架：RAGAS、ARES、TruLens等，它们可以从答案的忠实度（Faithfulness）、相关性（Relevance）、上下文精度（Context Precision）等多个维度对RAG系统进行打分。
关于为什么使用Ragas作为评估框架？它主要有两大优点：https://www.ragas.io/
可用指标：https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/
精确度和召回率通常是相互制约、此消彼长的。
一个优秀的检索系统需要在精确度和召回率之间找到一个理想的平衡点，既要保证结果相关性高（高精确度），又要保证没有遗漏关键信息（高召回率）。
评估一般的核心流程：
一个模拟的数据集表格：
| question_id | question (问题) | ground_truth_answer (标准答案) | ground_truth_context_ids (标准上下文ID) | generated_answer (模型生成答案) | retrieved_context_ids (模型检索到的上下文ID) |
|---|---|---|---|---|---|
eval_001 | ["doc_rag_definition"] | ["doc_rag_definition"] |
# 使用 Hugging Face datasets 库创建 Dataset 对象
dataset = Dataset.from_dict(ragas_data)
# --- 运行评估 ---
# 定义我们想要使用的评估指标列表
# 注意：answer_correctness 和 context_recall 都需要 ground_truth
metrics_to_evaluate = [
faithfulness, # 忠实度：答案是否基于上下文
answer_relevancy, # 答案相关性：答案是否与问题相关
context_precision, # 上下文精确率：检索到的上下文是否都相关
context_recall, # 上下文召回率：是否检索到了所有必要的上下文来回答问题
answer_correctness, # 答案正确性：答案与标准答案的匹配程度
]
print("🚀 开始运行 Ragas 评估...")
# 使用 ragas.evaluate 函数执行评估
# Ragas 会自动使用 OPENAI_API_KEY 调用 LLM 进行打分
result = evaluate(
dataset=dataset,
metrics=metrics_to_evaluate,
)
print("✅ 评估完成！")
# --- 展示和分析结果 ---
# 将评估结果转换为 Pandas DataFrame 以便清晰地展示
df_results = result.to_pandas()
print("\n📊 评估结果分析:")
print(df_results)
# 保存结果到 CSV 文件
df_results.to_csv("ragas_evaluation_results.csv", index=False)
print("\n💾 结果已保存到 ragas_evaluation_results.csv")
五、经典论文
部分解读：https://mp.weixin.qq.com/s/HrZB4qNga69ePxJvcRiHTA
RAG技术虽然在2020年正式提出，但其早期提案和研究可追溯到2017年至2019年 。
2020年：RAG正式诞生（Lewis等人），密集神经检索、端到端检索-生成架构、检索感知预训练以及超越问答的应用开始涌现 。 2021年：研究重点转向提升生成质量 。 2022年：RAG系统开始进行规模化和专业化发展 。 2023年：RAG与LLMs的结合日益紧密，研究兴趣显著增长 。 2024年：RAGRAPH等新进展出现，将RAG扩展到图数据领域 。 2025年：当前研究方向正转向Agent系统、推理、记忆和多模态 。
| 类别 | 核心文献 (Publication Details) | 核心贡献与价值 (Core Contribution & Significance) |
|---|---|---|
| 奠基与综述 | ||
| "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" | 思想 | |
| "Retrieval-Augmented Generation for Large Language Models: A Survey" | 思想 | |
| 高级RAG与自适应方法 | ||
| "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection" | 思想 | |
| "Corrective Retrieval Augmented Generation (CRAG)" | 思想 | |
| 检索与索引优化 | ||
| "HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels" | 思想 | |
| "RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval" | 思想 | |
| "From Local to Global: A GraphRAG Approach to Query-Focused Summarization" | 思想 | |
| 工程实践与评估 | ||
| "Ragas: Automated Evaluation of Retrieval Augmented Generation" | 思想 | |
| "Searching for Best Practices in Retrieval-Augmented Generation" | 思想 |
六、开发者框架与产品
https://www.ragie.ai/ https://github.com/infiniflow/ragflow https://github.com/HKUDS/LightRAG
开发者框架
LLamaIndex：一个专门为连接 LLM 与您的私有数据而设计的“数据框架”，核心使命是解决数据处理的各种难题：如何高效地摄取（Ingest）、**索引（Index）和查询（Query）**各种复杂的数据。
LangChain：是一个功能极其全面的、用于开发由语言模型驱动的应用程序的通用框架
Haystack (by deepset AI)：Haystack 的工作方式主要是通过构建管道 (Pipelines)。一个管道就像一条流水线，数据在其中被一系列组件 (Components)按顺序处理，主要应用场景就是RAG。
📎OReilly Guide - RAG_in_production_with_Haystack-FINAL.pdf
| 方面 | LangChain | Haystack | LlamaIndex |
|---|---|---|---|
| 核心哲学 | 通用瑞士军刀 | 工业流水线 | 数据研发中心 |
| 主要优势 | 最庞大的生态系统 | 生产级稳健性 | 最强的数据处理能力 |
| 学习曲线 | 陡峭 | 中等 | 入门简单 |
| 最佳应用场景 | 生产级的RAG系统 | 数据密集的RAG系统 | |
| “魔法” vs “明确” | 非常明确 |
选择 LangChain 如果...
你的核心需求是构建一个**智能代理 (Agent)**，它需要与各种外部工具（如Google搜索、WolframAlpha、公司内部API）进行交互。
你需要最大范围的集成，不想自己手写任何连接代码。
你构建的应用不局限于RAG，可能包含更复杂的逻辑和工具使用。
你不介意花更多时间学习，以换取最强大的通用性和灵活性。
选择 Haystack 如果...
你的目标是构建一个稳定、可维护、可用于生产环境的RAG系统。
你和你的团队非常看重代码的清晰度和流程的透明度。
在你的项目中，未来可能会需要轻松地替换底层的大模型或向量数据库。
选择 LlamaIndex 如果...
你的项目最大的挑战在于数据——数据源非常多样化（PDF、PPT、Notion、数据库等）。
你想快速搭建一个RAG原型，并对各种高级的、前沿的RAG算法进行实验和评估。
你追求的是RAG领域的深度和极致性能。
开源产品
**dify：**一个功能极其强大且成熟的LLM应用开发平台，支持通过可视化编排快速构建包括RAG在内的各类AI应用。
RAGFlow by infiniflow：一个专注于深度文档理解的开源RAG引擎。擅长深度文档理解，使用基于模板的分块，与Infinity Database无缝集成，支持GraphRAG，并为可扩展性而设计 。
AnythingLLM：一个主打私有化和安全的桌面端/服务器端RAG解决方案，让您可以安全地与自己的文档聊天。
MegaParse + quivr：一个设计精美的开源RAG平台，旨在帮助用户存储和检索非结构化信息。
| 产品 | 核心定位 | 易用性（非技术人员） | 灵活性/定制性 | 最佳场景 |
|---|---|---|---|---|
| Dify.ai | ||||
| FastGPT | ||||
| AnythingLLM | ||||
| Quivr | ||||
| LlamaIndex/LangChain |
如果您想快速体验和搭建一个功能完整的RAG应用，推荐从Dify.ai或FastGPT开始。它们都提供了非常平滑的上手体验和强大的功能。 如果您最关心的是数据安全和隐私，希望所有东西都跑在自己的电脑或服务器上，AnythingLLM是最简单的选择。 如果您本身是开发者，希望构建一个高度定制化的产品，那么基于LlamaIndex或LangChain从代码层面开始会给予您最大的自由度。
商业产品
TextIn是合合信息旗下的品牌，专注于智能文字识别和文档处理领域长达16年。 它为全球用户提供一个智能文档处理云平台，核心产品围绕智能图像处理、文字表格识别以及文档内容的结构化提取，旨在显著提升企业业务处理的效率。
| 框架 | 核心定位 | 解决的问题 |
|---|---|---|
| PaddleOCR | ||
| Unstructured.io | ||
| Camelot | ||
| LlamaIndex |
Jina AI：Jina AI 提供了一整套开源框架和云端服务，帮助开发者轻松构建和部署能够理解文本、图片、音频、视频等多种数据类型的复杂AI搜索和生成应用。
可以查看排行：https://huggingface.co/mteb
**Milvus：**是目前全球最流行、最领先的开源向量数据库
| 产品 | 核心定位 | 部署模式 | 最佳应用场景 |
|---|---|---|---|
| Milvus | 大规模、高性能 | ||
| Weaviate | AI原生 | ||
| Qdrant | 高性能、高效率 | ||
| Pinecone | 完全托管 | ||
| pg_vector | |||
| Elasticsearch | 搜索引擎 | ||
| Chroma | 轻量级嵌入式 |
NotebookLM：是由 Google 开发的一款个人化AI研究和写作助手，它能将您提供的文档、笔记和网页等资料变成一个专属的知识库，并只根据这些资料来回答您的问题、生成摘要和启发新想法。
RAG-as-a-Service：是一个非常热门且快速增长的领域。许多公司认识到，虽然RAG（检索增强生成）的理念很简单，但要搭建一个生产级别的、稳定、高效的RAG系统却非常复杂，涉及文档解析、分块、嵌入、向量存储、检索、重排（Rerank）、提示词工程等多个环节。因此，一系列产品应运而生，旨在将整个RAG流程打包成一个简单易用的服务。用户只需上传数据，就能获得一个可以进行对话或查询的API端点。
| 产品 | 类别 | 核心优势 | 最适合的场景 |
|---|---|---|---|
| Vectara | |||
| Cohere | |||
| Amazon Bedrock | |||
| Vertex AI Search |
... 等等各种基于上述RAG应用场景的变种，客服、知识问答、记忆。
七、总结
检索增强生成（RAG）已不仅仅是一项补充性技术，它更是将大模型从一个通用的“知识大脑”转变为能够解决特定领域问题的“专家系统”的核心桥梁。它通过“开卷考试”的模式，从根本上解决了LLM在知识时效性、领域深度和事实准确性上的固有缺陷，为AI在企业中的规模化落地铺平了最关键的一段路。
构建一个卓越的RAG系统，并非单一技术的突破，而是一场贯穿数据处理全流程的系统工程。加载、切分、索引、嵌入、召回等，其中的每一个环节都充满了性能、成本与效果之间的权衡，不存在一劳永逸的“银弹”，只有最适合特定场景的最佳实践。
另外要认识到，没有度量，就没有优化。以RAGAS为代表的评估框架，使我们能够量化地评估RAG系统在忠实度、相关性和准确性上的表现。这是区分一个Demo与一个Production-ready产品的关键所在。
当前RAG的生态系统已经百花齐放，为开发者提供了从底层框架（如LlamaIndex, LangChain）到开箱即用的开源产品（如Dify, RAGFlow），再到全托管的商业服务（RAG-as-a-Service）的丰富选择。这意味着无论技术背景如何，无论是个人开发者还是大型企业，都能找到适合自己的切入点，参与到这场游戏中。
最后，RAG还在继续发展，它正与Agent深度融合，向多模态领域延伸，并逐渐成为更复杂AI系统中不可或缺的记忆与推理基石。掌握RAG，不仅是掌握一项技术，更是掌握了在AI时代将信息转化为价值的关键钥匙。