RAG与微调

从Naive RAG到Agentic RAG的演进 RAG技术的发展经历了三个阶段： Naive RAG (2023) → Advanced RAG (2024) → Agentic RAG (2025-2026) 朴素检索 增强检索 智能体检索 单次查询 多次优化 自主决策 固定管道 模块化 动态规划 传统RAG是一个"固定管道"：查询→检索→拼接→生成，一锤子买卖。Agentic RAG将LLM作为"大脑"，让它自主决定是否需要检索、检索什么、检索几次、何时停止。这就像从"查字典"升级为"咨询一个会查资料的研究员"。 Agentic RAG的核心架构 ┌─────────────────────────────────────────────────────┐ │ Agentic RAG Architecture │ ├─────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────────────────────┐ │ │ │ User │───▶│ Agent Controller │ │ │ │ Query │ │ (LLM + Planning + Memory) │ │ │ └──────────┘ └──────────┬───────────────────┘ │ │ │ │ │ ┌─────────┼─────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌───────┐ ┌─────────┐ │ │ │ Router │ │ Query │ │ Evaluator│ │ │ │ (路由) │ │Rewrite│ │ (评估器) │ │ │ └────┬────┘ └───┬───┘ └────┬────┘ │ │ │ │ │ │ │ ┌─────────┼──────────┼──────────┘ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐ │ │ │ Vector │ │ Web │ │ SQL │ │ Graph │ │ │ │ Store │ │ Search │ │ DB │ │ Store │ │ │ └──────────┘ └────────┘ └──────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────┘ 四大核心组件 组件 职责 关键能力 Agent Controller 任务规划与决策 分解问题、决定工具调用顺序 Router 工具路由 选择合适的数据源（向量库/搜索引擎/数据库） Query Rewriter 查询改写 将用户问题改写为更有效的检索查询 Evaluator 结果评估 判断检索结果是否充分，决定是否需要追加检索 核心模式解析 模式1：迭代检索（Iterative Retrieval） from langgraph.graph import StateGraph, END from typing import TypedDict, List, Annotated import operator class AgentState(TypedDict): question: str retrieved_docs: Annotated[List[str], operator.add] answer: str iteration: int sufficient: bool def retrieve_node(state: AgentState) -> dict: """基于当前问题+已有信息生成查询并检索""" query = query_rewriter(state["question"], state["retrieved_docs"]) docs = vector_store.similarity_search(query, k=5) return {"retrieved_docs": docs, "iteration": state["iteration"] + 1} def evaluate_node(state: AgentState) -> dict: """评估检索结果是否足以回答问题""" if state["iteration"] >= 3: return {"sufficient": True} prompt = f"""基于以下检索到的文档，能否完整回答用户问题？ 问题: {state['question']} 文档: {state['retrieved_docs']} 如果信息充分回答"SUFFICIENT"，否则回答"INSUFFICIENT"并说明缺什么。""" response = llm.invoke(prompt) sufficient = "SUFFICIENT" in response return {"sufficient": sufficient} def answer_node(state: AgentState) -> dict: """基于所有检索文档生成最终回答""" prompt = f"问题: {state['question']}\n\n参考资料:\n{state['retrieved_docs']}" return {"answer": llm.invoke(prompt)} # 构建工作流 workflow = StateGraph(AgentState) workflow.add_node("retrieve", retrieve_node) workflow.add_node("evaluate", evaluate_node) workflow.add_node("answer", answer_node) workflow.set_entry_point("retrieve") workflow.add_edge("retrieve", "evaluate") workflow.add_conditional_edges( "evaluate", lambda state: "answer" if state["sufficient"] else "retrieve" ) workflow.add_edge("answer", END) agent = workflow.compile() 模式2：多路检索（Multi-Route Retrieval） def route_query(state: AgentState) -> str: """根据问题类型选择检索路径""" routing_prompt = f""" 分析以下问题，选择最合适的数据源： 问题: {state['question']} 选项: - "vector": 适合从内部文档库检索事实性信息 - "web": 适合需要最新信息的时效性问题 - "sql": 适合结构化数据查询 - "graph": 适合关系推理和多方关联 返回JSON: {{"route": "...", "reason": "..."}} """ decision = llm.invoke(routing_prompt) return json.loads(decision)["route"] 模式3：自我纠正检索（Self-Corrective RAG） def grade_documents(state: AgentState) -> dict: """对检索文档打分，过滤低质量结果""" graded_docs = [] for doc in state["retrieved_docs"]: score_prompt = f"""评估文档与问题的相关性(0-10): 问题: {state['question']} 文档: {doc.page_content[:500]} 只返回数字。""" score = int(llm.invoke(score_prompt).strip()) if score >= 6: graded_docs.append(doc) # 如果所有文档都不相关，触发查询改写 if not graded_docs: new_query = llm.invoke(f"改写这个查询以获得更好的检索结果: {state['question']}") return {"retrieved_docs": [], "question": new_query} return {"retrieved_docs": graded_docs} 工程实现：基于LangGraph的完整Agentic RAG from langgraph.graph import StateGraph, END from langgraph.prebuilt import ToolNode from langchain_core.tools import tool from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage # 定义工具 @tool def vector_search(query: str) -> str: """从内部知识库检索相关文档""" docs = vector_store.similarity_search(query, k=5) return "\n\n".join([d.page_content for d in docs]) @tool def web_search(query: str) -> str: """从网络搜索最新信息""" results = search_api.search(query, num_results=5) return "\n\n".join([r["content"] for r in results]) @tool def sql_query(question: str) -> str: """查询业务数据库""" sql = text2sql(question) return db.execute(sql) # Agent决策循环 tools = [vector_search, web_search, sql_query] llm = ChatOpenAI(model="gpt-4o", temperature=0) llm_with_tools = llm.bind_tools(tools) def agent_decision(state): messages = state["messages"] response = llm_with_tools.invoke(messages) return {"messages": [response]} def should_continue(state): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return END # 构建Graph graph = StateGraph(dict) graph.add_node("agent", agent_decision) graph.add_node("tools", ToolNode(tools)) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") # 工具执行后回到agent做下一轮决策 app = graph.compile() # 执行 result = app.invoke({ "messages": [HumanMessage(content="对比2026年Q1三大云厂商的AI服务收入")] }) 性能基准对比 我们在三个数据集上对比了不同RAG架构的表现： ...

从RLHF到DPO的范式转变 RLHF（基于人类反馈的强化学习）是ChatGPT成功的关键技术，但其训练过程极其复杂：需要训练Reward Model、使用PPO算法、维护多个模型副本。 DPO（Direct Preference Optimization）直接绕过Reward Model和强化学习，用一个简单的分类损失函数实现偏好对齐： RLHF Pipeline (复杂): SFT → Reward Model → PPO → 对齐模型 (3个模型，4个训练阶段) DPO Pipeline (简洁): SFT → DPO → 对齐模型 (1个模型，2个训练阶段) DPO核心原理 DPO的损失函数基于一个关键洞察：最优的策略模型可以通过偏好数据直接推导，不需要显式的Reward Model。 # DPO Loss公式 # L_DPO = -log σ(β * (log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x))) # 其中： # π: 当前策略模型 # π_ref: 参考模型（SFT后的模型，冻结） # y_w: 偏好的回答 (winner) # y_l: 不偏好的回答 (loser) # β: 温度参数，控制偏离参考模型的程度 # σ: sigmoid函数 直觉理解：让模型对"好回答"的概率比参考模型更高，对"坏回答"的概率比参考模型更低。 ...

为什么Embedding模型决定RAG上限？ RAG系统的检索质量 = Embedding模型质量 × 向量库能力 × 检索策略。后两者已经相对成熟，Embedding模型成为拉开差距的关键变量。 一个差的Embedding模型，即使后面Reranker再强也无力回天——因为你根本检索不到相关文档。 测评模型清单 我们选取了2026年主流的10款Embedding模型进行测评： 模型 提供方 维度 参数量 最大长度 部署方式 text-embedding-3-large OpenAI 3072 - 8192 API text-embedding-3-small OpenAI 1536 - 8192 API BGE-large-zh-v1.5 BAAI 1024 326M 512 本地 BGE-M3 BAAI 1024 568M 8192 本地 GTE-large-zh 阿里 1024 326M 512 本地 GTE-Qwen2-7B-Instruct 阿里 3584 7B 32K 本地 Jina-embeddings-v3 Jina AI 1024 570M 8192 本地/API Cohere-embed-v4 Cohere 1024 - 512 API E5-large-v2 Microsoft 1024 335M 512 本地 UAE-large-v1 WhereIsAI 1024 335M 512 本地 测评设置 数据集 数据集 文档数 查询数 特点 C-Pack 100万 5000 中文通用检索基准 MTEB-ZH 10万 1000 中文检索评估集 行业知识库(自建) 5万 500 金融、法律、医疗领域 多跳QA(自建) 1万 200 需要多文档关联 评估指标 # 主指标：NDCG@10 (归一化折损累积增益) # 辅助指标：Recall@5, Recall@10, MRR@10 def evaluate_retrieval(qrels, results, k=10): """计算检索评估指标""" ndcg_scores = [] recall_scores = [] mrr_scores = [] for query_id, retrieved_docs in results.items(): relevant_docs = qrels.get(query_id, {}) # NDCG@k ndcg = compute_ndcg(retrieved_docs[:k], relevant_docs) ndcg_scores.append(ndcg) # Recall@k recall = len(set(retrieved_docs[:k]) & set(relevant_docs)) / len(relevant_docs) recall_scores.append(recall) # MRR@k mrr = compute_mrr(retrieved_docs[:k], relevant_docs) mrr_scores.append(mrr) return { "ndcg@10": np.mean(ndcg_scores), "recall@5": np.mean([compute_recall(r, q, 5) for r, q in zip(results, qrels)]), "recall@10": np.mean(recall_scores), "mrr@10": np.mean(mrr_scores), } 测评结果 总体排名（NDCG@10） 排名 模型 C-Pack MTEB-ZH 行业库 多跳QA 平均分 1 GTE-Qwen2-7B 0.823 0.801 0.782 0.698 0.801 2 text-embedding-3-large 0.815 0.792 0.768 0.671 0.787 3 BGE-M3 0.808 0.785 0.771 0.662 0.782 4 Jina-embeddings-v3 0.801 0.778 0.759 0.658 0.774 5 BGE-large-zh-v1.5 0.792 0.771 0.752 0.641 0.764 6 GTE-large-zh 0.788 0.768 0.748 0.635 0.760 7 Cohere-embed-v4 0.781 0.762 0.741 0.628 0.753 8 E5-large-v2 0.772 0.754 0.732 0.615 0.743 9 text-embedding-3-small 0.761 0.748 0.725 0.608 0.736 10 UAE-large-v1 0.752 0.738 0.718 0.601 0.727 关键发现 1. GTE-Qwen2-7B一骑绝尘 GTE-Qwen2-7B作为首款基于大语言模型（7B参数）的Embedding模型，在长文本理解上优势明显： ...

为什么传统RAG不够用？ 传统向量检索RAG在处理多跳推理、全局摘要类问题时表现不佳。当用户问"2025年诺贝尔物理学奖得主的核心贡献是什么？"，传统RAG可能只能检索到获奖者名单，而无法关联到具体贡献的文档片段。GraphRAG通过引入知识图谱的结构化关系，解决了这一痛点。 微软研究院在2024年开源的GraphRAG框架掀起了一波浪潮，到2026年，社区已经发展出更成熟的工具链和最佳实践。本文将带你从零搭建一个生产级GraphRAG系统。 GraphRAG核心架构 GraphRAG的工作流分为四个阶段： 1. 知识图谱构建 从原始文档中抽取实体和关系，构建知识图谱： from graphrag.index import build_index from graphrag.config import create_config_from_yaml # 配置文件定义LLM、嵌入模型等 config = create_config_from_yaml("config.yaml") # 构建索引：实体抽取 → 关系建模 → 社区检测 build_index( config=config, input_dir="./documents", output_dir="./graph_index" ) 实体抽取的Prompt模板： ENTITY_EXTRACTION_PROMPT = """ 你是一个知识图谱构建专家。从以下文本中抽取实体和关系。 文本：{text} 输出JSON格式： {{ "entities": [ {{"name": "实体名", "type": "PERSON|ORG|LOCATION|CONCEPT", "description": "描述"}} ], "relations": [ {{"source": "实体A", "target": "实体B", "relation": "关系类型", "description": "描述"}} ] }} """ 2. 社区检测与摘要 使用Leiden算法对图谱进行层次化社区检测，每个社区生成一个摘要： import networkx as nx from graspologic.partition import hierarchical_leiden # 构建NetworkX图 G = nx.Graph() for entity in entities: G.add_node(entity.name, **entity.metadata) for rel in relations: G.add_edge(rel.source, rel.target, relation=rel.relation) # 层次化社区检测 partitions = hierarchical_leiden(G, max_cluster_size=10) # 为每个社区生成LLM摘要 for community in partitions: community_summary = llm.summarize( entities=community.entities, relations=community.relations ) 3. 检索策略 GraphRAG支持两种检索模式： ...

引言：为什么传统RAG不够用？ 传统向量RAG在处理"全局性"问题时表现糟糕。比如你问"2026年AI芯片市场的主要竞争格局是什么？"，基于文档块的向量检索只能返回零散片段，无法构建全局视图。Microsoft Research在2024年提出的GraphRAG正是为解决这一痛点而生，到2026年，这套方法已经成熟并衍生出多种变体。 GraphRAG的核心思想：先从文档中抽取实体和关系构建知识图谱，再用社区检测算法将图谱分层聚类，最后基于社区摘要进行全局检索。 GraphRAG架构总览 ┌─────────────────────────────────────────────┐ │ GraphRAG Pipeline │ ├─────────────────────────────────────────────┤ │ 1. Document Chunking (文档分块) │ │ 2. Entity Extraction (实体抽取) │ │ 3. Relationship Building (关系构建) │ │ 4. Community Detection (社区检测) │ │ 5. Community Summarization (社区摘要) │ │ 6. Query-focused Summarization (查询摘要) │ └─────────────────────────────────────────────┘ 两种检索模式 模式 适用场景 原理 延迟 Local Search 具体实体相关问题 从匹配节点出发，遍历相邻实体和关系 低 (200-500ms) Global Search 全局性、摘要性问题 遍历所有社区摘要，Map-Reduce式汇总 高 (2-5s) 环境搭建与代码实践 安装GraphRAG pip install graphrag==0.6.0 初始化项目 # 创建工作目录 mkdir my_graphrag_project && cd my_graphrag_project # 初始化配置 python -m graphrag.init --root . 初始化后会生成以下结构： ...

LoRA的核心价值再认识 LoRA（Low-Rank Adaptation）在2026年仍然是性价比最高的微调方案。相比全量微调： 对比维度 全量微调 LoRA微调 显存占用 70B模型需8×A100 70B模型需2×A100 训练成本 $50-100/次 $5-10/次 模型体积 每次全量模型 仅Adapter权重(几十MB) 训练速度 基线 快30-50% 效果差距 基线 相差<3% LoRA的本质：冻结原模型权重，只训练低秩分解矩阵。 原模型权重 W ∈ R^(d×k)，参数量 d×k LoRA分解： W' = W + ΔW = W + B×A 其中： B ∈ R^(d×r)，A ∈ R^(r×k) r << min(d, k) # 典型值 r=8-64 参数量：d×r + r×k = r×(d+k) << d×k 完整微调流程 第一步：数据准备（最关键） 数据质量 > 数据数量，这是2026年行业的共识。 数据格式 { "instruction": "解释什么是GraphRAG，并说明它的核心优势", "input": "", "output": "GraphRAG是一种结合知识图谱的检索增强生成技术..." } 或对话格式： ...

QLoRA解决了什么问题？ LoRA已经大幅降低了微调成本，但对于70B模型，仍然需要2×A100(80GB)。QLoRA（Quantized LoRA）通过4-bit量化基座模型，将显存需求再降一个数量级： 模型 全量微调 LoRA QLoRA 7B 80GB 16GB 6GB 14B 160GB 32GB 12GB 70B 800GB 160GB 24GB 这意味着：用一张RTX 4090就能微调70B模型。 QLoRA核心原理 三大创新 1. NF4（NormalFloat 4-bit）量化 传统4-bit量化（INT4）假设数据均匀分布，但神经网络权重通常服从正态分布。NF4专门为正态分布设计量化区间： # NF4量化原理 import numpy as np # INT4: 均匀量化 int4_levels = np.linspace(-1, 1, 16) # 16个均匀区间 # NF4: 正态分布感知量化 from scipy.stats import norm # 16个分位点对应正态分布的分位 nf4_levels = norm.ppf(np.linspace(0, 1, 17)[1:-1]) nf4_levels = nf4_levels / np.max(np.abs(nf4_levels)) # 归一化到[-1, 1] print(f"INT4 levels: {int4_levels}") print(f"NF4 levels: {nf4_levels}") # NF4在0附近更密集，在两端更稀疏，匹配权重分布 2. Double Quantization 对量化后的缩放因子本身再量化，进一步节省显存： 原始权重 W → 4-bit量化 → 量化值 + 缩放因子(32bit) ↓ 缩放因子再量化为8-bit ↓ 额外节省约0.4bit/参数 3. Paged Optimizer 使用NVIDIA的统一内存，当显存不够时自动将优化器状态转移到CPU内存： ...

核心矛盾：检索 vs 全量上下文 随着GPT-5（2M token）、Claude 4（200K token）、Gemini 2.5 Pro（1M token）的发布，“长上下文模型能否替代RAG"成为2026年最热门的技术争论之一。 两种思路的对比： RAG思路：只给LLM看相关的片段 ┌─────────┐ ┌──────────┐ ┌─────────┐ │ 用户查询 │───▶│ 检索Top-K │───▶│ LLM生成 │ └─────────┘ │ 相关文档 │ └─────────┘ └──────────┘ Long Context思路：把所有文档都塞给LLM ┌─────────┐ ┌────────────────────┐ ┌─────────┐ │ 用户查询 │───▶│ 全部文档(长上下文) │───▶│ LLM生成 │ └─────────┘ └────────────────────┘ └─────────┘ 表面上看，长上下文模型让RAG变得多余——既然能塞下整个知识库，为什么还要检索？但实际情况远没有这么简单。 六大维度全面对比 1. 上下文利用率（Context Utilization） LLM对长上下文的中间部分利用率低，这是经过大量研究验证的"Lost in the Middle"现象。 文档位置对注意力的影响（GPT-5实测）： 文档开头 ──► 注意力权重高 ▼ ──► 文档结尾 ▲ ▲ 用户问题 系统提示 容易引用 容易引用 文档中间 ──► 注意力权重低 ◄── 关键信息 ▼ 容易被忽略 实测数据（1000份文档，每篇500字，共500K token上下文）： ...

为什么分块策略如此重要？ 在RAG系统中，分块（Chunking）是影响检索质量的第一道关卡。同样的文档、同样的Embedding模型、同样的LLM，仅仅因为分块策略不同，检索准确率可以相差30%以上。 核心矛盾在于：块太大，检索精度下降（噪声多）；块太小，上下文不足（语义不完整）。 好的分块策略要在这两端之间找到最优解。 六种分块策略全面对比 1. 固定大小分块（Fixed-Size Chunking） 最简单的策略：按固定token数切分，带overlap。 from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", "，", " "], ) chunks = splitter.split_text(document) 参数 推荐值 说明 chunk_size 256-1024 取决于文档类型，技术文档建议512 chunk_overlap 10-20% 防止语义在切分边界断裂 优点：实现简单、速度快、可预测 缺点：可能在句子中间切断，破坏语义完整性 适用：快速原型、均匀文本（如日志、评论） 2. 语义分块（Semantic Chunking） 不按固定大小切，而是按语义相似度断点切。当相邻句子的语义相似度低于阈值时，在此处分块。 from semantic_chunker import SemanticChunker from langchain_openai import OpenAIEmbeddings # 基于Embedding相似度的语义分块 chunker = SemanticChunker( OpenAIEmbeddings(model="text-embedding-3-large"), breakpoint_threshold_type="percentile", # 或 "standard_deviation" breakpoint_threshold_amount=95, # 百分位阈值 ) chunks = chunker.split_text(document) 工作原理： 句子1 → 句子2 → 句子3 → 句子4 → 句子5 0.92 0.88 0.45↓ 0.91 0.87 ↑ 语义断点（相似度骤降） 在这里切分 # 自定义语义分块实现 import numpy as np from sklearn.metrics.pairwise import cosine_similarity def semantic_chunk(text, embeddings_model, threshold=0.5): """基于句子间语义相似度的自适应分块""" sentences = split_into_sentences(text) # 计算每对相邻句子的相似度 embeddings = [embeddings_model.embed(s) for s in sentences] similarities = [ cosine_similarity([embeddings[i]], [embeddings[i+1]])[0][0] for i in range(len(embeddings) - 1) ] # 找到相似度低于阈值的位置作为断点 chunks = [] current_chunk = [sentences[0]] for i, sim in enumerate(similarities): if sim < threshold: chunks.append(" ".join(current_chunk)) current_chunk = [sentences[i + 1]] else: current_chunk.append(sentences[i + 1]) chunks.append(" ".join(current_chunk)) return chunks 优点：语义完整、适应文档结构 缺点：计算开销大（每句话都要Embedding）、块大小不可控 适用：长文章、研究报告、新闻 ...

RAG评估的困境 大多数RAG系统在上线时面临一个尴尬的问题：你知道它在工作，但你不知道它工作得有多好。 没有系统化的评估框架，调参就像蒙眼开车——你不知道改chunk_size从512到1024到底是好了还是坏了。 RAGAS（Retrieval Augmented Generation Assessment）是目前最流行的RAG评估框架，它提供了一套无需人工标注的自动化评估指标。 RAGAS核心指标体系 指标全景图 RAGAS 指标体系 │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ 检索指标 生成指标 端到端指标 │ │ │ ┌─────┼─────┐ ┌────┼────┐ ┌────┼────┐ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ 上下文 上下文 ─ 忠实 答 答 语义 答案 精确率 召回率 度 案 案 相似 相关 相 完 关 整 性 性 四大核心指标详解 指标 评估什么 范围 理想值 Faithfulness（忠实度） 答案是否忠于检索到的上下文 0-1 >0.95 Answer Relevancy（答案相关性） 答案是否回答了用户问题 0-1 >0.85 Context Precision（上下文精确率） 检索到的上下文有多少是相关的 0-1 >0.80 Context Recall（上下文召回率） 回答问题所需的信息是否都检索到了 0-1 >0.85 指标计算原理 Faithfulness（忠实度） 衡量答案中的每个claim是否能从检索上下文中找到支撑。 ...