RAG与微调

为什么传统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是否能从检索上下文中找到支撑。 ...

前言：RAG从Demo到生产的鸿沟 写一个RAG Demo只需要30分钟——加载文档、Embedding、存向量库、检索、生成，完成。但把它放到生产环境，你会发现： 幻觉：LLM明明拿到了正确文档，还是编造了不存在的信息 漏检：库里明明有相关文档，检索就是找不到 延迟：用户等了8秒还没返回，体验崩溃 这三个问题构成了RAG生产环境的"不可能三角"。本文分享2026年我们在生产环境中踩过的坑和解决方案。 难题一：幻觉问题 幻觉的三种形态 类型 表现 根因 忠实性幻觉 答案与检索文档矛盾 LLM忽略上下文，依赖自身参数知识 编造型幻觉 答案包含文档中不存在的信息 LLM"脑补"细节 来源混淆 将多个文档的信息错误组合 多文档检索时上下文混淆 解决方案矩阵 方案1：强约束Prompt # ❌ 容易幻觉的Prompt prompt = f"""基于以下资料回答问题： {context} 问题：{question} """ # ✅ 抗幻觉的Prompt prompt = f"""你是一个严格的信息提取助手。请遵循以下规则： 1. **只使用**以下参考资料回答问题 2. 如果参考资料中没有相关信息，直接回答"根据现有资料无法回答此问题" 3. 不要添加任何参考资料中未提及的信息 4. 不要进行推理、猜测或补全 5. 回答中需要引用具体的资料来源 参考资料： --- {context} --- 问题：{question} 回答格式： [来源：文档名] 回答内容... """ 方案2：置信度校准 def answer_with_confidence(question, retrieved_docs): """带置信度的回答""" # 第一步：评估检索质量 relevance_prompt = f"""评估以下文档与问题的相关性(0-10): 问题: {question} 文档: {retrieved_docs[0].page_content[:500]} 只返回数字。""" relevance_score = int(llm.invoke(relevance_prompt).strip()) if relevance_score < 4: return { "answer": "抱歉，知识库中没有找到与您问题相关的信息。", "confidence": 0.2, "should_answer": False, } # 第二步：生成回答并自我验证 answer = rag_chain.invoke(question) # 第三步：验证回答是否忠于上下文 verify_prompt = f"""判断以下回答的每个陈述是否能在参考资料中找到支撑。 参考资料: {retrieved_docs} 回答: {answer} 返回JSON: {{"faithful": true/false, "unsupported_claims": [...]}}""" verification = json.loads(llm.invoke(verify_prompt)) return { "answer": answer if verification["faithful"] else "无法确认回答准确性", "confidence": relevance_score / 10.0, "should_answer": verification["faithful"], } 方案3：Citation机制 def generate_with_citations(question, retrieved_docs): """强制引用来源的生成""" # 给每个文档编号 numbered_context = "\n\n".join([ f"[{i+1}] {doc.page_content}" for i, doc in enumerate(retrieved_docs) ]) prompt = f"""基于以下编号的参考资料回答问题。每个陈述后必须标注来源编号[1]。 参考资料： {numbered_context} 问题：{question} 要求： - 每个事实陈述后标注来源编号，如"GraphRAG由微软提出[1]" - 如果某个陈述来自多个文档，标注所有来源，如"[1][3]" - 无法找到来源的陈述不要写出 回答：""" return llm.invoke(prompt) 幻觉抑制效果实测 方案 幻觉率↓ 答案完整度↓ 延迟增加 强约束Prompt 45% 15% +0s 置信度校准 68% 8% +1.5s Citation机制 72% 5% +0.8s 三者结合 85% 22% +2.3s 建议组合：强约束Prompt + Citation机制，性价比最高。 ...

为什么需要Reranker？ RAG检索分两个阶段： 第一阶段：召回（Recall） Embedding向量检索，快速从百万文档中召回Top-K（K=20-50） 优势：速度快（<50ms） 劣势：精度有限（Embedding模型容量小，语义理解浅） 第二阶段：精排（Precision） Cross-Encoder Reranker对Top-K重新打分排序 优势：精度高（Cross-Encoder能深度理解query-doc关系） 劣势：速度慢（需对每个候选单独计算） Reranker的本质：用更强的模型对初筛结果做精排，用少量延迟换取显著的精度提升。 Cross-Encoder vs Bi-Encoder Bi-Encoder (Embedding模型)： Query ──► Encoder ──► [向量] ◄── Encoder ◄── Document │ 余弦相似度 快但浅 Cross-Encoder (Reranker)： [Query, Document] ──► Encoder ──► 相关性分数 慢但深 Cross-Encoder将query和document拼接后一起输入模型，能捕捉两者间的细粒度交互关系，这是Bi-Encoder做不到的。 三大Reranker深度对比 1. Cohere Reranker import cohere co = cohere.Client(api_key="your-key") def cohere_rerank(query, documents, top_n=5): results = co.rerank( model="rerank-v3.5", query=query, documents=documents, top_n=top_n, ) reranked = [] for result in results.results: reranked.append({ "document": documents[result.index], "relevance_score": result.relevance_score, "index": result.index, }) return reranked 特点： ...

知识蒸馏：用小成本获得大能力 GPT-5很强大但很贵——每次API调用$0.06/1K tokens。如果每天处理10万次查询，月成本$18,000。而7B模型自部署的成本仅为$500/月。 知识蒸馏的核心思想：让小模型学习大模型的"思维方式"，而不只是模仿其输出。 Teacher模型 (GPT-5, 175B+) │ │ 知识转移 ▼ Student模型 (Qwen2.5-7B) │ │ 微调 + 对齐 ▼ 蒸馏模型 (7B, 接近GPT-5效果) 三种蒸馏方案 方案1：黑盒蒸馏（最常用） 黑盒蒸馏只需要Teacher模型的输入输出API，不需要访问模型权重或内部状态。 Step 1: 用Teacher生成训练数据 import openai import json from tqdm import tqdm client = openai.OpenAI(api_key="your-key") def generate_training_data(prompts, teacher_model="gpt-5"): """用GPT-5生成高质量训练数据""" training_data = [] for prompt in tqdm(prompts): # 系统提示：让Teacher模型输出详细、有条理的回答 system_prompt = """你是一个专业的AI助手。请按照以下要求回答问题： 1. 回答要详细且有条理 2. 使用适当的格式（标题、列表、代码块） 3. 如果适用，提供示例 4. 确保回答准确且有帮助""" response = client.chat.completions.create( model=teacher_model, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": prompt}, ], temperature=0.7, # 适度多样性 max_tokens=2000, ) training_data.append({ "instruction": prompt, "output": response.choices[0].message.content, "metadata": { "teacher_model": teacher_model, "temperature": 0.7, } }) return training_data # 生成多样化提示词 def generate_diverse_prompts(domains, num_per_domain=500): """生成覆盖多个领域的多样化提示词""" prompts = [] for domain in domains: # 用Teacher模型生成领域特定提示词 meta_prompt = f"为'{domain}'领域生成{num_per_domain}个多样化的用户问题。" domain_prompts = client.chat.completions.create( model="gpt-5", messages=[{"role": "user", "content": meta_prompt}], ) prompts.extend(domain_prompts.choices[0].message.content.split("\n")) return prompts # 生成数据 domains = ["编程开发", "数据分析", "文案写作", "技术咨询", "数学推理", "创意设计"] prompts = generate_diverse_prompts(domains, num_per_domain=500) training_data = generate_training_data(prompts) # 保存 with open("distill_training_data.json", "w", encoding="utf-8") as f: json.dump(training_data, f, ensure_ascii=False, indent=2) Step 2: 数据质量过滤 def quality_filter(data): """过滤低质量训练数据""" filtered = [] for item in data: output = item["output"] # 长度过滤 if len(output) < 50 or len(output) > 5000: continue # 质量信号检查 quality_signals = [ len(output.split("\n")) > 3, # 有结构 any(kw in output for kw in ["1.", "首先", "因为", "因此"]), # 有逻辑 not output.startswith("I cannot") and not output.startswith("我无法"), # 非拒答 ] if sum(quality_signals) >= 2: filtered.append(item) return filtered Step 3: SFT训练Student模型 from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from trl import SFTTrainer from peft import LoraConfig, get_peft_model # 加载Student模型 model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B", torch_dtype=torch.bfloat16, device_map="auto", ) # LoRA配置 lora_config = LoraConfig( r=64, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) # 训练 training_args = TrainingArguments( output_dir="./distilled-7b", num_train_epochs=3, per_device_train_batch_size=4, gradient_accumulation_steps=4, learning_rate=2e-4, lr_scheduler_type="cosine", warmup_ratio=0.03, bf16=True, logging_steps=10, save_steps=500, ) trainer = SFTTrainer( model=model, args=training_args, train_dataset=dataset, tokenizer=tokenizer, max_seq_length=2048, peft_config=lora_config, ) trainer.train() 方案2：白盒蒸馏（效果更好） 白盒蒸馏利用Teacher模型的内部状态（logits、注意力权重）进行知识转移。 ...