RAG基本路线

提示用于检索知识库中的信息，而知识库又用于增强提示。然后将此增强的提示馈送到模型中进行生成

basic rag 与 anythingllm

basic rag 检索处理基本流程

1. 对文本进行分块并为数据块生成嵌入；

2. 通过语义相似性搜索检索块

3. 根据top_k块的文本生成响应

• 分块策略（权重 35%）
块大小直接影响信息完整性，法律文档建议 4096 字符重叠量优化上下文保留，代码类数据最佳重叠率 12.5%;

• 嵌入模型适配（权重 30%）
领域专用词表覆盖率需>85%，混合嵌入方案可提升跨模态检索准确率 23%

• 重排序机制（权重 25%）
BGE 重排器使MRR@5提升41%，动态阈值过滤减少噪声文档干扰

• 提示工程（权重 10%）
CoT提示策略在QA任务中提升F1值17%结构化模板降低代码生成错误率 32%
参考自 Towards Understanding Retrieval Accuracy and Prompt Quality in RAG Systems

不足分析

1. 向量数据库问题 key：向量 value：文本/原始数据
1. 基于嵌入向量相似性检索方式的限制
• 向量相似性问题：向量相似性度量（如余弦相似性）的挑战
• 粒度不匹配：查询和检索内容之间的粒度级别不匹配
• 稀疏检索挑战：由于数据稀疏，难以检索相关内容。
2. 向量表示的不足：对于单词，开发者不知道该向量提取了哪些信息；对于长文本，怎样使用嵌入向量充分表示文本信息？
• 语义歧义：查询解释中的歧义。

2. 分块参数灵活性问题
复杂的 RAG 应支持灵活的分块，并且可以添加一点重叠以防止信息丢失。一般来说，分块过程会忽略文本的内容，这会导致问题。块的理想内容应该围绕单个主题保持一致，以便嵌入模型更好地工作。分块不应该从一个主题跳到另一个主题;不应该改变场景。此外，如果 chunk 大小太小或 chunk 中的信息不够密集，我们可能无法从 vector 数据库中提取所有必要的信息。

3. 多跳问答

4. 确定多个检索到的段落对生成任务的重要性或相关性可能具有挑战性。
• 排名不当：检索到的内容排名不正确。

可能的解决方案

1. 数据层面
• 文本清理：标准化文本格式，删除特殊字符和不相关信息。这提高了检索器的效率并避免了垃圾进垃圾出。
• 实体解析：消除实体和术语的歧义以实现一致的引用。
• 重复数据删除：删除重复文档或冗余信息以提高检索器的重点和效率。
• 文档分割：将长文档分解为可管理的块，或者相反，将小片段组合成连贯的文档以优化检索器性能。
• 特定于域的注释：使用特定于域的标记或元数据对文档进行注释。【交互问题】
• 层次结构和关系：识别文档之间的父子或兄弟关系，以提高上下文理解。
• 用户反馈循环：根据真实世界的互动，使用新的 Q&A 对不断更新您的数据库，并标记它们以确保事实的正确性。

2. 检索与嵌入
• 参考 Qwen-Agent 实现在百万字长文中找到我们需要的内容





• 调整分块 LLaMA index 具有针对不同分块方法的自动评估功能
• 检索方法 Langchain 的多向量检索方法，该方法采用较小的块、摘要嵌入和假设问题来提高检索准确性
• 重新排名解决向量相似性问题，
• 尝试使用混合搜索和递归检索技术来提高性能 HyDE HyDE 是一种策略，它接受查询，生成假设响应，然后使用两者进行嵌入查找。研究发现，这可以显著提高性能。

• 微调嵌入

• 与其他外部知识库（如图形数据库）混合LLM

• 多跳问答：使用复杂的提示工程（如 ReACT）、使用外部图形数据库来辅助推理、工具调用（也称为函数调用）代理或 ReAct 代理。
基于文档的问答中的一个经典挑战是多跳推理。例如，当给出一个包含相关事实的长文件时，考虑回答问题“与第五交响曲创作的同一世纪发明了什么车辆？该模型需要首先确定子问题“第五交响曲是在哪个世纪创作的”的答案，即 19 世纪。然后，它可以意识到包含 “Bicycles were invented in the 19th century” 的块实际上与原始问题相关。

一、检索器原理与实现

1. 文档预处理与分块
• 智能分块策略：支持按固定字符数分割，并允许设置重叠窗口（如 200 字符重叠），以保留上下文信息。
• 多格式支持：处理 PDF、HTML、Markdown 等格式时，会提取纯文本并清除噪声（如广告、页眉页脚）。
• 元数据附加：为每个文本块附加来源、创建时间等元数据，辅助后续检索的筛选。

2. 向量化与索引
• 嵌入模型选择：默认使用 sentence-transformers/all-mpnet-base-v2 等高精度开源模型，也支持 OpenAI 或 Cohere 的付费 API。
• 混合检索：结合稠密向量检索（语义相似度）和稀疏检索（如 BM25 关键词匹配），提升召回率。
• 动态重排序（Rerank）：使用交叉编码器模型（如 bge-reranker）对初步检索结果重新排序，优先最相关片段。

3. 查询优化
• 查询扩展：通过 LLM 生成假设性回答（HyDE 技术），将其作为补充查询，增强检索意图理解。
• 多路召回：并行执行多个检索策略（如关键词+语义+元数据过滤），合并结果后去重。

4. 向量数据库集成
• 支持 Chroma、Pinecone、Milvus 等多种数据库，利用 HNSW 或 IVF 索引加速近似最近邻搜索（ANN）。

二、保障问答质量的措施

1. 预处理阶段
• 数据清洗：过滤低质量文本（如乱码、重复内容）和敏感信息。
• 分块参数调优：提供 UI 界面供用户自定义分块大小和重叠，适应不同文档类型（如代码需小分块，论文需大分块）。

2. 检索阶段
• 阈值过滤：设定相似度分数阈值，仅保留高于阈值的片段，避免无关内容干扰生成。
• 多样性控制：限制同一文档的片段数量，确保结果多样性。

3. 生成阶段
• 提示工程：设计结构化提示模板，明确要求 LLM 基于检索内容回答，并标注引用来源。例如：
• 温度调节：降低生成温度（如 temperature=0.3），减少模型虚构可能性。

4. 后处理与验证
• 引用校验：检查生成答案中的引用是否与检索片段一致，剔除无来源支持的陈述。
• 事实一致性检测：使用小型判别模型（如 DEBERTa）验证答案与上下文的一致性。

5. 反馈闭环
• 人工标注：允许用户对答案评分或标记错误，数据用于微调检索和生成模型。
• 自动化评估：内置 BLEU、ROUGE 等指标评估生成质量，结合检索覆盖率（Recall@k）持续优化。

anythingLLM配置

配置

1. 模型选择配置

2. 向量数据库
1. <LanceDB: 适用于<10万文档，零配置自动维护>
2. Qdrant: 开源方案中HNSW算法性能最优，支持混合检索（关键词+向量）

3. Embedder 选择策略

类型	语言支持	硬件消耗	成本估计
内置MiniLM	英语优先	CPU 2核/内存2GB	0
OpenAI	92种语言	API	0.8美元/千次
Ollama模型	自行训练	GPU 显存8GB+	训练成本

4. 分块优化策略



文本分块大小和重叠大小直接决定了检索器（Retriever）能够提供给生成器（Generator）的上下文质量：
块大小：较大的分块可以保留更多上下文信息，但可能导致信息稀释，降低检索精度；较小的分块则可能导致重叠不足，而易造成上下文断裂，且top_k个相关块丢失信息严重。 重叠大小：适度的重叠有助于保持跨块的语义连贯性，但过多重叠会增加冗余，降低检索效率。 上表是根据个人近期实践结合网上搜索做的整理，仅供参考。分块大小与业务场景强相关，没有普适最优解。一般而言，分块策略的调整依据是：
复杂文档（如法律条款）：块大小建议 4096，重叠 512。
短文本（如对话记录）：块大小建议 1024，重叠 256。
在此基础上，还应该根据自定义的质量评估指标设计动态调整机制，例如：检索召回率<85% → 增大块重叠（每次+10%）。生成结果偏离度>30% → 减小块大小（每次-25%）。
分块策略包括两个主要参数： 分块大小与top_k值

5. 重排序机制

rag 前沿探索

RAG技术实施

核心架构： 文档处理→向量化→知识库构建→相似度检索→上下文融合→答案生成 关键技术点： - 文本分块策略 - 向量表示方法 - 检索算法优化 - 提示词工程

矢量数据库

• SQL 数据库、No-SQL 数据库和全文搜索引擎扩展了它们的功能以支持矢量数据存储和相似性搜索。

• 量身定制的商业和开源 Vector 数据库。

• 向量数据库编制索引： 长文本嵌入向量表示

• 查询，为要在相似性搜索中使用的查询生成嵌入

基于文本的检索

1. Lexical search / Sparse Lexical Retrieval



使用TF-IDF、Okapi BM25等排名函数来对搜索结果进行排名。（稀疏向量的维度等于词汇表中术语数的向量）词法搜索方法的一个显著缺点是，当词汇不匹配时，它无法检索结果。

2. Lexical search with Learning to Rank（LTR）
学习排名算法使用监督学习来解决搜索相关性中的排名问题。在 LTR 中，关于文档与给定查询的相关性判断在模型训练期间用作基本事实。这些判断可以由专家创建，也可以通过使用点击模型分析点击日志来生成。
与基于概率的 TF-IDF 或 BM25 排名相比，LTR 方法更耗时，因此通常用于对前 N 个文档进行重新排名。与查询、文档以及查询和文档之间的交互相关的特征用于监督式训练。

3. Semantic Search / Dense Retrieval
代表：transformer
存在两种不同的架构方法，用于利用这种嵌入表示对文档进行排名以响应给定的查询。





（1）以表示为中心（bi-encoder）使用神经网络（如编码器）来获取查询/文档表示形式。然后使用距离度量（如余弦相似度或点积）匹配获得的表示（嵌入向量）以生成分数。使用编码器获取文档或查询嵌入的一种方法是获取查询或文档中的每个输入标记的嵌入，然后计算平均嵌入。另一种方法是获取句子标记开头的嵌入向量（<CLS>）。
以表示为中心的架构的一个优点是，文档嵌入可以预先计算并存储在矢量数据库中以供将来检索。在运行时，查询向量是使用类似的模型计算的，距离是使用语料库中每个可用文档的向量计算的。结果按相似度（最短距离）排序。
但是，这些嵌入的问题在于它们是标记级嵌入，而不是句子/文档级嵌入。平均嵌入的思路在实践中效果不佳【已经试验过】。句子转换器（例如，Sentence-BERT）通过为稍长的文本生成合适的嵌入来解决这个问题（受所用编码器模型的大小限制，nomic_text的1024个 WordPiece标记）。句子转换器使用siamese网络架构来微调预先训练的编码器模型，例如 BERT。他们使用相关句子（或查询/文档文本）的标记语料库来训练前馈网络，该网络对两个句子是否相互匹配进行分类。以这种方式生成的输出嵌入适合比较不同的句子（或 query 和 documents）。



(2)以交互为中心（Cross-Encoder）跨编码器的神经网络架构也适用于序列。但是，它侧重于使用 query 和 document 的联合表示形式。在此方法中，查询和文档将合并到一个序列中，然后将其传递给编码器。前馈神经网络层用于获取查询和文档之间的匹配概率。预训练的编码器可以使用标记的查询-文档对进行微调。
由跨编码器生成的联合查询-文档表示形式比以表示为中心的系统提供更准确的结果。但是，跨编码器会带来较大的运行时开销，因为需要在运行时计算每个查询-文档对的相似性分数。因此，这些模型通常用于文档数量较少的重新排名阶段。



（3）后期交互检索模型 使用BERT等编码器生成的token嵌入，并为文档存储这些token级向量。因此，不是将文档表示为一个向量（就像句子转换器所做的那样），而是由一个向量列表表示，每个token都有一个向量。文档向量列表可以在索引时计算，并且可以存储在高效的向量存储中以供以后检索。查询token在运行时编码到token级别向量中，并通过token级别的可扩展但精细的交互进行评分。

4. 混合检索

分块策略 （代码参考）

在自然语言处理的上下文中，“分块”是指将文本分割成小的、简洁的、有意义的“块”。与大型文档相比，RAG 系统可以更快、更准确地在较小的文本块中定位相关上下文。

• Fixed-size chunking:只需决定 chunk 中的标记数量，以及它们之间是否应该有任何重叠。确定最佳数据块大小就是要取得平衡 — 在不牺牲速度的情况下捕获所有基本信息。 虽然较大的数据块可以捕获更多上下文，但它们会引入更多的干扰，并且需要更多的时间和计算成本来处理。较小的数据块的噪点较少，但可能无法完全捕获必要的上下文。重叠数据块是平衡这两个约束的一种方式。通过重叠数据块，查询可能会跨多个向量检索足够的相关数据，以便生成适当的上下文化响应。 一个限制是，此策略假定必须检索的所有信息都可以在单个文档中找到。如果所需的上下文被拆分到多个不同的文档中，可能需要考虑利用文档层次结构和知识图谱等解决方案。;

• “Content-aware” Chunking
• Sentence splitting:按句点分割、NLTK、spaCy
• Recursive Chunking
递归分块使用一组分隔符以分层和迭代的方式将输入文本划分为较小的块。如果拆分文本的初始尝试未生成所需大小或结构的块，则该方法会使用不同的分隔符或条件递归地在生成的块上调用自身，直到达到所需的块大小或结构。
• Specialized Chunking:针对特殊格式文档（Markdown、latex）
• Semantic Chunking*：
• 将文档分割成句子
• 创建句子组：对于每个句子创建一个组，组中包含给定句子（锚点）的上下文。
• 为每个句子组生成嵌入，并将组与锚点句相关联
• 按顺序比较每个组之间的距离：当按顺序查看文档中的句子时，只要主题或主题相同——给定句子的句子组嵌入与前面的句子组之间的距离将很短。另一方面，较高的语义距离表明主题或主题已更改。这可以有效地将一个块与下一个块区分开来。




• Agentic Chunking(EMNLP 2024 Dense X Retrieval: What Retrieval Granularity Should We Use?)

查询增强——检索器Retriever

• NeedleBench 是一个基准测试，旨在测试模型是否能够在充满大量不相关句子的上下文中识别最相关的句子，类似于大海捞针。回答问题可能需要同时发现多个 “针” 并执行多跳推理。

• LV-Eval 是一个具有挑战性的基准，需要同时理解多个证据。我们修改了 LV-Eval 原始版本的评估指标，因为它过于严格，导致大量假阴性。

• MMLU：一组 57 项任务，涵盖小学数学、美国历史、计算机科学、法律等。要表现出色，模型必须具备广泛的世界知识和解决问题的能力。

• EleutherAI Eval：统一的框架，可通过 200 个任务的零/少镜头设置来测试模型。包含大量评估，包括 BigBench、MMLU 等。

• AlpacaEval：自动评估框架，用于衡量强LLM者（例如 GPT-4）更喜欢一个模型的输出而不是参考模型的输出的频率。指标包括赢率、偏差、延迟、价格、差异等。经验证与 20k 人工注释具有高度一致性。

• HELM：HELM 不是特定的任务和指标LLMs，而是通过跨领域评估它们来提供全面的评估。指标包括准确度、校准、稳健性、公平性、偏差、毒性等。任务包括 Q&A、信息检索、摘要、文本分类等。

• 上下文相关：这些选项考虑了上下文。它们通常是针对特定任务提出的;将它们重新用于其他任务需要一些调整。
1. MoverScore 使用上下文化嵌入来计算生成的输出和引用中标记之间的距离。但与基于令牌一对一匹配（或“硬对齐”）的 BERTScore 不同，MoverScore 允许多对一匹配（或“软对齐”）。

• 上下文无关：在评估生成的输出时，这些不与上下文相关联;他们仅将输出与提供的黄金引用进行比较。由于它们与任务无关，因此更容易应用于各种任务。
1. BLEU （Bilingual Evaluation Understudy） 是一个基于精度的指标：它计算生成的输出中也出现在参考文献中的 n-gram 的数量，然后将其除以输出中的单词总数。它主要用于机器翻译，由于其成本效益，它仍然是一个流行的指标。
2. ROUGE （Recall-Oriented Understudy for Gisting Evaluation）：与 BLEU 相比，ROUGE 是以召回为导向的。它计算引用中也出现在输出中的单词数。它通常用于评估自动摘要任务。
3. BERTScore 是一种基于嵌入的指标，它使用余弦相似度将生成输出中的每个标记或 n-gram 与参考句子进行比较。

LLM

RAG优化点

1. 离线文档处理

2. 文档内容增强
1. 句子摘要和扩展。作为索引的句子可以和用于模型生成的句子不是一句。特别是非对称检索，为了让q和d尽可能接近，可以使用文段关键句、摘要、问题作为索引。
2. 文档合并

3. 索引构建和选择
要面对的可能是结构化的数据，例如各种产品的结构化信息、参数等，也可能非结构化的文段，文本可长可短，短到几个字，长到一份长篇材料材料，甚至有表格、图像甚至公式等目前技术仍旧不容易解析的结构，因此需要将他们转化为“可以检索”的模式。仅仅采用向量化然后向量召回的方案存在局限。
• 数字信息的检索： 使用数字索引，结构化存储
• 专有名词性质较高的检索：抽取关键词，对给定query进行实体抽取，必要时挖掘同义词

4. 检索策略多样性和合并方法
• 字面召回、向量召回、多路召回（合并和排序）
• 不同数据库中差异召回
• query改写前后的召回 （query2doc）

5. 查询后处理
在完成检索后，获得了最需要的若干个文档，再把他们扔进大模型之前，可以进行后处理。
• 文档多、内容长→进行一次摘要
• 配合文档更新query
• 通过先询问一次模型，查看回复中那些信息更有利于回答问题，或者没有合适的信息利于回答问题，提前进行拒识。

6. 多轮对话
• 直接拼接历史对话，供大模型参考。不适合长对话场景。
• 对前面的对话进行摘要。

7. 查询路由与agent
使用agent协助进行各种策略的选择：
• 最优文档的筛选
• 查询策略

8. 模型微调

项目实践

④ deepseek性能的探讨： 将全部知识分别喂给了满血版deepseek、kimi、通义千问【不在线搜搜情况下】。

结论： 满血版在接收所有文档后，对于文档中有明确答案的内容回答非常准确，但是对于多跳问答（需要几条数据总结回答的）回答不能和知识库中内容相关。

嵌入模型微调

qanything

• 大模型服务 : llm_server_entrypoint.py

• 重排名服务 ： dependent_server/rerank_for_local_server/rerank_server.py

• ocr服务：（识别图像和处理PDF）

• sanic服务：异步web服务框架（代码中包含了知识库增删改查、文件增删改查、问答接口）

1. 初始化与配置

• __init__ 方法初始化基本配置，包括网络会话、文档分割器等

• init_cfg 方法初始化嵌入模型、重排模型、向量存储等客户端

2. 文档检索与处理

• get_source_documents 方法异步从知识库检索相关文档

• web_page_search 和 get_web_search 方法实现网页搜索补充知识

3. 文本处理与优化

1. 上下文优化：不是简单返回检索到的最相关片段，而是尝试提供更完整的文档内容，改善语言模型理解上下文的能力

2. 资源平衡：在token限制下，智能地平衡文档完整性和多样性，确保在有限的token预算内提供最有价值的信息

3. 特殊内容处理：保留表格和图片信息，同时提供带图和不带图两个版本，以便系统灵活使用

• reprocess_source_documents 方法根据token限制处理文档

• aggregate_documents 方法智能聚合文档，尽可能提供完整上下文
在系统已经检索到相关文档片段后被调用，用于优化这些片段的呈现方式。其核心思想是：如果检索结果集中于少数几个文件，则尝试返回完整文件内容而非片段，以提供更连贯的上下文。
1. 文档归类与分组：
2. 智能聚合判断：
• 如果检索结果来自超过两个文件，直接返回原始片段
• 否则尝试获取完整文件内容
3. Token预算管理：
4. 优先级处理：在token预算有限的情况下，优先保证第一个(最相关)文件的完整性，然后再考虑第二个文件

• get_completed_document 用于获取一个文件的完o'l'olp整内容或指定范围内的内容。从数据库中获取指定文件ID的所有文档片段，并将它们组合成一个连贯的文档，同时处理特殊内容(如表格、图片)。

工作流程

1. 获取原始数据：
2. 内容合并与处理：
3. 元数据合并：

4. 提示词生成与回答生成

• generate_prompt 生成结构化提示模板

• generate_response 方法处理回答并支持流式输出

1. 问题处理:
• 使用 RewriteQuestionChain 结合历史对话重写用户问题

2. 文档检索:
• 从向量库检索相关文档
• 可选择进行网络搜索获取补充信息

3. 文档重排序优化:
• 使用重排模型对文档进行精排，提高相关性
• 过滤得分低的文档，保留高质量内容

4. 智能处理特殊情况:
• FAQ完全匹配直接返回预设答案
• Token限制动态调整文档数量
• 表格和图像内容的特殊处理

5. 答案生成与优化:
• 构建优质提示词
• 调用LLM生成答案
• 对包含图片的文档进行相关性评估，找出合适的图片

1. 文档上传
1. mysql记录上传文件条目（在指定知识库下增加文件并记录）
2. 文档切片、嵌入向量表示、存入矢量数据库

2. 文档处理

1. 索引构造

1. 初始化与连接管理

• 支持本地或在线模式连接Milvus服务器

• 根据模式确定使用CPU(IVF_FLAT)或GPU(GPU_IVF_FLAT)索引类型

• 设置检索阈值和超时参数

2. 数据库结构定义

• chunk_id: 文本块的唯一标识符

• file_id: 文件标识符

• embedding: 768维向量表示

• 其他元数据字段

3. 初始化和集合管理

• 连接到Milvus服务器

• 检查用户集合是否存在，不存在则创建

• 为每个知识库ID创建对应的分区

4. 向量搜索与结果处理

• 在指定分区中搜索最相似的向量

• 使用L2距离计算相似度

• 处理并转换返回结果

5. 结果后处理与文档聚合

• 按相似度阈值筛选结果

• 对不同类型文档采用不同处理策略

• 对普通文本文档进行上下文扩展

6. 上下文扩展机制

1. 按文件ID对检索结果分组

2. 对每个匹配片段，尝试扩展其前后200个chunks

3. 智能判断并合并连续文本片段

4. 控制合并后文本不超过最大限制(CHUNK_SIZE)

7. 混合检索支持

• 结合Milvus向量检索和ElasticSearch全文检索能力

• 确保结果不重复

• 对ES结果应用与Milvus结果相同的扩展逻辑

Dify RAG 模块结构详解

1. 目录结构概览

2. 核心组件详解

2.1 检索服务 (retrieval_service.py)

• 功能：接收用户查询，调用向量数据库进行语义检索

• 参数控制：通过top_k和score_threshold控制结果数量和质量

• 重排序集成：支持通过DataPostProcessor对检索结果进行优化

2.2 向量存储 (Vector类)

• 向量库适配：支持20+种向量数据库，包括Qdrant、PGVector、ElasticSearch等

• 工厂模式：使用get_vector_factory动态加载适配器

• 特色功能：支持全文搜索、向量检索、重复检测等

2.3 文本分割器 (text_splitter.py)

• TextSplitter：抽象基类，定义分块接口

• CharacterTextSplitter：基于字符分隔符的简单分割器

• RecursiveCharacterTextSplitter：递归尝试不同分隔符的高级分割器

• TokenTextSplitter：基于Token计数的分割器，适用于LLM上下文窗口

2.4 后处理器 (DataPostProcessor)

• 重排序：对初始检索结果进行重新评分，提升相关性

• 灵活性：支持多种重排序模式（权重分数、重排序模型）

• 模型集成：连接外部重排序模型服务

2.5 数据模型 (models/)

• 文档结构化：定义统一的文档表示格式

• 转换接口：提供文档与其他格式互转的能力

3. 系统工作流程

1. 文档处理：将知识库文档加载、分割成适当大小的块

2. 向量化存储：为每个文档块生成向量表示并存入向量数据库

3. 检索流程：
• 将用户查询向量化
• 在向量库中查找最相似文档
• 可选应用重排序优化结果
• 返回最终匹配文档

4. 集成接口：提供统一API供上层应用调用

关于金橙子的需求确认：