RAG实战|8种RAG架构浅析

因为项目的需要，之前研究了一段时间的RAG，于是本文总结 8 种 RAG 架构，对每种架构进行简要介绍，并用 langchain 实现其参考代码。 1. Naive RAG 简介： Naive RAG 是最基础的检索增强生成架构，采用“索引-检索-生成”的经典流程。 print(answer) 4. Agentic RAG 简介： Agentic RAG（智能体RAG）将 AI Agent 的规划和推理能力与 RAG 相结合。 架构： 实现步骤： 实体抽取：使用NER或LLM从文档中抽取实体（人物、地点、概念等） 关系抽取：识别实体之间的关系，构建三元组（实体-关系-实体） 知识图谱构建：将实体和关系存储到图数据库中（如Neo4j 架构： 实现步骤： 查询分类：分析用户查询的类型和复杂度（简单事实/多跳推理/开放性问题） 策略选择：根据查询类型选择最优的RAG策略 简单查询：直接LLM回答或单次检索 复杂查询：多轮迭代检索 开放性问题

RAG技术架构与实现原理

本文详细解析了RAG技术，包括其定义、作用、技术架构和检索模块的实现与优化，全面展示了RAG在自然语言处理中的重要性和广泛应用前景。 关注TechLead，复旦AI博士，分享AI领域全维度知识与研究。 二、RAG的技术架构 RAG模型整体架构 RAG（Retrieval-Augmented Generation）模型的技术架构包括两个主要部分：检索模块（Retriever）和生成模块（Generator 技术架构图 以下是RAG模型的技术架构图，展示了检索模块和生成模块的工作流程： 输入查询 │ ▼ 检索模块 │ ├──> 文档1 │ ├──> 文档2 检索模块的性能直接影响RAG模型的整体效果，因此深入理解其工作原理、技术实现和优化策略是非常重要的。本章将详细解析RAG检索模块的各个方面，包括其架构、实现细节、优化方法以及实际应用中的注意事项。 检索模块架构 RAG的检索模块通常采用双塔模型（Dual-Encoder）架构，由两个独立的编码器组成：一个用于编码查询（Query Encoder），另一个用于编码文档（Document Encoder

langchain4j 之 Advanced RAG

langchain4j 中的 Advanced RAG 涉及到诸多策略，今天和大家聊一聊这里涉及到的一些策略。 智能路由器会： 识别到"技术术语+架构分析"特征 自动选择学术论文库和 AI 技术文档库检索 跳过无关的新闻和百科内容 优势： • 减少无效检索，响应速度提升 40% • 避免多路检索的资源浪费 3.2.3 4.2.4 其他 其他的还有像 AzureAiSearchContentRetriever 主要负责和 Azure AI 进行交互，Neo4jContentRetriever 则主要负责和 Neo4j with LangChain4j?") with LangChain4j?")

聊聊langchain4j的RAG

序本文主要研究一下langchain4j的RAG概述RAG(Retrieval-Augmented Generation)即检索增强生成，它通过检索来获取相关信息，注入到prompt，然后用增强的prompt 实现LangChain4j 提供了三种RAG（Retrieval-Augmented Generation，检索增强生成）的实现方式：Easy RAG：这是最简单的方式，适合初学者快速上手。 Easy RAGpom.xml<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-easy-rag RAG Flavors**LangChain4j offers three RAG flavors:* **Easy RAG:** The simplest, quickest way to get LangChain4j 提供了三种RAG（Retrieval-Augmented Generation，检索增强生成）的实现方式：Easy RAG、Naive RAG、Advanced RAG。

七种RAG架构cheat sheet！

Weaviate 是一个开源的向量数据库， 面向的就是RAG使用场景，给出了七种RAG架构cheat sheet。RAG 分为两个阶段：索引阶段 和 查询阶段，每个阶段都有超多硬核技术加持！ 7 种 RAG 架构 以下是Weaviate官方总结的七种RAG（Retrieval-Augmented Generation）架构的核心要点速查表，涵盖核心原理、优缺点及适用场景。1. 4. Graph RAG（图RAG）核心原理：利用图数据库（如Neo4j）存储实体关系，通过图查询实现多跳推理和语义关联检索。 优点：捕捉复杂关系（因果、层级）、支持动态更新、增强推理能力。 4. 检索策略纯向量检索：适合语义相关性强的场景（如问答）。 混合检索：结合向量与关键词（BM25），提升多样性和覆盖率。 图增强检索：集成知识图谱（如 Neo4j）支持多跳推理。 #RAG架构 #Weaviate #AI技术 #技术分享 #多模态 #知识图谱 #智能代理

MiA-RAG (Mindscape-Aware RAG)：为大模型构建“全局大脑”的革命性RAG架构

MiA-RAG的诞生，正是为了将这种人类独有的“全局心智”能力赋予AI系统。 二、MiA-RAG的核心思想与整体架构MiA-RAG的核心创新在于其两阶段架构，明确分离了全局心智构建和局部任务执行两个过程。 三、关键技术优势与对比分析特性传统RAG超长上下文MiA-RAG上下文视野局部、碎片化理论上完整，但实际注意力稀释全局、结构化计算成本低（仅处理小片段）极高（处理整个文档）中等（预处理+小片段处理）推理能力单跳 四、实验效果与评估根据原论文（arXiv:2512.17220）及后续的行业评测，MiA-RAG在多个专注于长上下文理解和基于证据推理的基准测试中，持续且显著地超越了现有的所有基线RAG方法。 深入的案例研究表明，MiA-RAG能够成功地将分布在文档不同部分的证据进行整合，完成复杂的多跳推理，而传统RAG则常常失败。

大模型+知识库rag项目架构

将大模型与知识库结合的项目架构（RAG项目架构）可能指的是一种结合了检索（Retrieval）和生成（Generation）的架构，即RAG（Retrieval-Augmented Generation 这种架构特别适用于需要结合检索信息和生成新内容的任务，如开放域问答、内容创作等。RAG架构的一般流程如下：检索阶段（Retrieval）：首先，系统会从知识库中检索出与输入查询相关的信息。 在实际应用中，RAG项目架构可以根据不同的应用场景和需求进行定制和优化。例如，检索系统可以使用不同的搜索引擎或推荐系统，而生成模型可以是传统的语言模型，也可以是专门为特定任务训练的模型。 如果你有关于RAG项目架构的具体问题，或者需要了解如何在特定的应用场景中实现这种架构，请提供更多的上下文信息，我会尽力提供帮助。

学习向量数据库与 RAG 架构

### **二、RAG 架构：核心原理与流程**#### 1. RAG 是什么？ - **Step 4：生成（Generation）** - 将检索到的Chunk作为“上下文”，与用户问题一起传入LLM（如GPT-3.5/4、LLaMA）。 - 用工具如LangSmith、RAGAs评估RAG系统性能。 4. **RAG高级架构**： - **多模态RAG**：支持图像、音频等数据（如用CLIP模型生成跨模态向量）。 **结合其他技术**： - 与知识图谱（KG）结合，提升检索逻辑推理能力（如RAG + KG架构）。

聊聊langchain4j的Naive RAG

序本文主要研究一下langchain4j的Naive RAG示例public class Naive_RAG_Example { /** * This example demonstrates 技术，Easy RAG使用了EmbeddingStoreIngestor来隐藏了文档解析、分割、嵌入、嵌入存储，Naive RAG亦可使用。 EmbeddingStoreContentRetrieverdev/langchain4j/rag/content/retriever/EmbeddingStoreContentRetriever.javapublic 小结langchain4j提供了EmbeddingStoreContentRetriever来开启Naive RAG的功能，EmbeddingStoreContentRetriever.builder( docNaive RAG

langchain4j 学习系列(5)-RAG

继续我们的langchain4j之旅，今天来看看RAG如何实现，“RAG萌宠新手盆友们”建议先看看B站大佬的视频RAG 工作机制详解—哔哩哔哩_bilibili，核心步骤就是下面这3张图： 最简单的RAG error: " + e.getMessage() + "\"}"); } } 略做解释： 为了简单起见， 这里分片我们略过，直接手动用二个句子，当成2个分片 使用langchang4j prompt_eval_count":11} 3、重排/生成 private interface Assistant { String chat(String userMessage); } /** * 基于RAG "" + e.getMessage() + "\"}"); } } 日志输出： 2025-12-03T21:06:00.218+08:00 INFO 16956 --- [langchain4j-study "done_reason":"stop","total_duration":1059949995,"prompt_eval_count":21,"eval_count":22} 从日志上看，先做了1次RAG

聊聊langchain4j的Advanced RAG

序本文主要研究一下langchain4j的Advanced RAG核心流程将UserMessage转换为一个原始的QueryQueryTransformer将原始的Query转换为多个Query每个Query *

* Advanced RAG in LangChain4j is described here: https://github.com/langchain4j/langchain4j DefaultQueryTransformerdev/langchain4j/rag/query/transformer/DefaultQueryTransformer.javapublic class ReRankingContentAggregatordev/langchain4j/rag/content/aggregator/ReRankingContentAggregator.javapublic ContentInjectordev/langchain4j/rag/content/injector/ContentInjector.java@Experimentalpublic interface

【AIGC】通过RAG架构LLM应用程序

toc在之前的博客文章中，我们已经描述了嵌入是如何工作的，以及RAG技术是什么。本节我们我们将使用 LangChain 库以及 RAG 和嵌入技术在 Python 中构建一个简单的 LLM 应用程序。 我们的 RAG 应用程序将使用私有数据扩展 LLM 的知识。在这种情况下，它将是一个包含一些文本的 PDF 文件。 在关于RAG的文章中对此进行了更详细的描述。 4.准备环境变量下一步是将这些块转换为数字向量，并将它们存储在向量数据库中。这个过程叫做嵌入，也有一篇关于它的博文，所以我们现在不会详细介绍它。对于嵌入过程，我们需要一个外部嵌入模型。 复制密钥并将其粘贴到 .env 文件中，如下所示：OPENAI_API_KEY=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让我们通过导入 load_dotenv

聊聊langchain4j的核心RAG APIs

序本文主要研究一下langchain4j的核心RAG APIs核心RAG APIslangchain4j提供了一套丰富的API来构建自定义的RAG（检索增强生成）pipelines，从简单的到高级的都有涵盖 (langchain4j-document-loader-amazon-s3)、AzureBlobStorageDocumentLoader(langchain4j-document-loader-azure-storage-blob (langchain4j-document-parser-apache-pdfbox)、ApachePoiDocumentParser(langchain4j-document-parser-apache-poi 提供了一套丰富的API来构建自定义的RAG（检索增强生成）pipelines，包括DocumentLoader、DocumentParser、DocumentTransformer、DocumentSplitter doccore-rag-apis

RAG流程优化（微调）的4个基本策略

RAG简单回顾 RAG主要有两个过程。第一个是“数据收集过程”，它收集来自不同来源的数据，将其转换为文本，将其分割成较小的、连贯的和语义相关的部分，并将结果存储在矢量数据库中。 4、提供模型的最后提示:制作有效提示以提高输出质量。 RAG的A/B测试 A/B测试可以比较每个组件具有不同配置的两个版本，确定哪个版本的性能更好。 = pd.DataFrame(rag_dataset) rag_eval_datset = Dataset.from_pandas(rag_df) # Return the lragas dataset return rag_eval_datset def get_metrics(rag_dataset): """ For a RAG Dataset 这些组件中的每一个都在提高RAG系统的性能方面起着至关重要的作用。 优化RAG的过程是需要持续的测试的，从失败中学习，以及做出明智的调整。

RAG 架构如何克服 LLM 的局限性

检索增强生成 (RAG) 是一种架构框架，利用 向量数据库 来克服现成 LLM 的局限性。在本文中，我将引导你了解 RAG 的功能和优势，以及它如何促进 LLM 和实时 AI 环境的彻底改造。 检索增强生成 (RAG) RAG 是一种架构框架，可帮助企业在其 LLM 和 AI 生态系统和流程中使用专有向量数据库作为先导步骤。RAG 将这些搜索结果用作 LLM 的附加输入，可用于塑造其答案。 RAG 架构使 LLM 能够在对提示或查询创建响应之前访问外部数据库。 通过绕过重新训练流程，RAG 为企业提供了一种经济且便捷的方式来增强其 AI 应用程序，而不会损害搜索准确性和性能。 RAG 的功能和优势 既然你对 RAG 有了基本的了解，我想将重点转移到它的主要功能和主要优势上。 更好的搜索质量 增强的搜索质量是企业使用 RAG 解锁的首批优势之一。 展望 RAG RAG 可以帮助生成更好、更具上下文且没有幻觉的响应来回答人类的问题。借助 RAG，聊天机器人的响应对用户来说更快、更准确。当然，这只是一个简单的用例。

Kubernetes(4:架构)

Master 是cluster 的大脑： 运行 kube-apiserver kube-scheduler kube-controller-manager etcd pod restful api scheduler 调度器Scheduler负责决定将Pod放在哪个Node上运行。Scheduler在调度 时会充分考虑Cluster的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。 Controller Manager负责管理Cluster各种资源，保证资源处于预期的状态。Controller Manager由多种controller组成，包括replicationcontroller、endpoints controller、namespace controller、serviceaccounts controller等。 etcd负责保存Kubernetes Cluster的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速地通知Kubernetes相关组件。 Pod要能够相互通信，Kubernetes Cluster必须部署Pod网络，flannel是其中一个可选方案。

构建十亿级向量检索与智能体生态：由 RAG 到 Agentic RAG 的架构实践

随着业务向多步推理、动态任务规划以及跨知识库协作检索演进，传统的 RAG（检索增强生成）架构暴露出明显的性能与运维瓶颈。 部署集成化 RAG 解决方案与原生智能体平台 为应对上述挑战，腾讯云联合 Elastic 提供了一套从底层基础设施到敏捷上层开发的全链路解决方案，推动应用由传统 RAG 向 Agentic RAG（智能体驱动的 RAG）转型。 统一化搜索平台架构：将原本割裂的多个组件整合为 1 个集成的 RAG 解决方案。 基础设施与技术效能指标： 服务器资源大幅缩减：在“十亿级向量”的 RAG 应用实战中，系统架构由管理 4 个不同系统、400+ 台服务器，精简至单一集成方案仅需 30 台服务器，实现 90%+ 的成本降低

RAG 架构实战：Fixed-Size Chunking（固定切块） 解析

Hello folks，我是 Luga，今天我们来聊一下人工智能应用场景 - 构建高效、灵活的计算架构的 RAG 架构的切块策略—Fixed-Size Chunking（固定切块）。 通过本文，你将一文读懂这款为下一代 RAG 应用量身打造的开源图向量数据库的核心理念、架构优势以及它如何助力你的智能化创新。让我们一起深入了解 HelixDB 的独特之处吧！ 执行运行： (base) lugalee@labs rag % /opt/homebrew/bin/python3 /Volumes/home/rag/fixedsiz.py 原始文本被切分成了 2 个块 通过本文，你将一文读懂这款为下一代 RAG 应用量身打造的开源图向量数据库的核心理念、架构优势以及它如何助力你的智能化创新。让我们一起深入了解 HelixDB 的独特之处吧！ 今天的解析就到这里，欲了解更多关于 LM Studio 相关技术的深入剖析，最佳实践以及相关技术前沿，敬请关注我们的微信公众号或视频号：架构驿站（priest-arc），获取更多独家技术洞察！

PDF通过新的RAG架构更容易进入GenAI

虽然这些视觉丰富的元素通常被排除在 RAG 工作流程之外，但一种用于从视觉增强文档中检索信息的新方法将简化多模态文档准备，并改变 RAG 和生成式 AI (GenAI) 的潜力。 这些处理步骤可能很耗时，并会影响检索质量，但 Contextualized Late Interaction over PaliGemma (ColPali) 是一种新的检索模型架构，专注于文档密集型环境中的 RAG，克服了这些挑战。 ColPali 的架构建立在两个关键概念之上：来自 视觉语言模型 (VLMs) 的上下文视觉嵌入和后期交互机制。 展望未来 ColPali 架构为文档检索树立了新标准，提供了一个灵活的框架，可以适应新兴的 VLM。基准测试结果表明 ColPali 优于传统方法，标志着该领域范式转变。

RAG 作者：RAG 已死，RAG 万岁！

一个具有更大上下文窗口的新模型问世，社交媒体上便会充斥着“RAG 已死”的宣言。 Meta 最近的突破再次引发了这场讨论——Llama 4 Scout 惊人的 1000 万（理论上）token 上下文窗口代表着一次真正的飞跃。 底线是：您同时需要长上下文 LLM 和 RAG。 但既然“RAG”这个术语似乎如此具有争议性，那我们不妨这样说： 我们不必非得称之为 RAG。 我们可以就叫它 检索 (retrieval)。 RAG 提供了相当于直接翻到相关页面的能力。处理更多 token 不仅更慢，而且极其低效，并且比使用 RAG 精准定位所需信息要昂贵得多。 RAG、微调和大型上下文窗口在 AI 中也是如此。 结论 我们不需要在 RAG 与长上下文窗口、微调或 MCP 之间做出选择。