2024 年 Q1 我们给一家律所做内部知识库问答系统 把过去 10 年的判例 法条 内部备忘录全部喂给 RAG 系统 让律师问问题直接拿到精准答案。第一版我们用最简单的方案 sentence-transformers + ChromaDB + GPT-4 一周搞定 demo 给客户看效果惊艳。但真上线一个月就开始翻车 律师投诉一通接一通 系统经常找不到明显相关的判例 或者找到完全无关的内容 或者把 5 年前已废止的法条当现行有效 出庭前一天被骂得狗血淋头。然后我们陆续踩了一堆坑。第一种最让我傻眼 律师问 帮我找上海地区 2023 年劳动合同纠纷判例 系统返回北京 2019 年的合同纠纷 完全没考虑地区与时间过滤 因为我们只做了向量相似度没做 metadata filter 这是 naive RAG 最大死穴。第二种最难缠 我们用默认 512 token chunk 拆判例 一个判例 30 页拆 60 份 律师问"原告主张"系统返回 chunk 1 但"被告答辩"在 chunk 5 完全断裂 拆分粒度错让上下文支离破碎。第三种最离谱 检索召回 top 5 都很相似 全是判决摘要 真正律师需要的判决理由全在 top 50 之后 因为 embedding 模型只对相似句子敏感不对相关性敏感 这是单 embedding 检索的硬伤。第四种最致命 GPT-4 拿到 5 个检索结果 上下文 8000 token 它对中间的 chunk 视而不见 关键判例在中间被忽略 答案完全偏离 这是 lost in the middle 现象。第五种最莫名其妙 同一个问题问 100 次 GPT-4 给出 5 种不同答案 律师无法信任系统输出 因为我们没做引用追溯 没法验证答案来源 RAG 失去了可解释性这个最大优势。我盯着这一连串问题想了很久才彻底想明白第一版错在一个根本的认知上我以为 RAG 就是 embed + 向量检索 + LLM 拼接 跑通就行 可这个认知是错的真正能投产的 RAG 系统是一个 数据切分策略 加 多路检索召回 加 重排序 加 metadata 过滤 加 引用追溯 加 评估闭环 的整套工程方法论 任何一环没做都可能让你的 RAG 从"智能助手"变成"幻觉机器"本文从头梳理 RAG 工程化的要点 chunk 怎么切 检索怎么混合 重排怎么做 上下文怎么压 引用怎么追 评估怎么建 以及一些把 RAG 用扎实要避开的工程坑
问题背景:为什么 naive RAG 总翻车
2023 年下半年 RAG 概念火爆 LangChain LlamaIndex 让每个人都能 30 行代码搭一个 demo。但真到企业场景才发现 demo RAG 与生产 RAG 是两个量级。律所要的不是模糊匹配 而是精确召回所有相关判例;医疗要的不是流畅生成 而是引用真实文献。问题源头是:
- Chunk 切分粒度:512 token 默认对长文档是灾难 必须按语义切 + 重叠 + 按文档结构。
- 单一向量检索不够:embedding 对语义相似敏感 但对关键词精确匹配差 必须 hybrid search 混合 BM25。
- 缺重排序:粗排 top 100 后必须用 cross-encoder 精排 top 5 这是质量飞跃的关键。
- 缺 metadata 过滤:时间 地区 类型必须先过滤再向量检索 否则结果全乱。
- 缺引用追溯:输出必须带 source 链接 让用户能验证答案来源 否则没法信任。
- 缺评估闭环:不评估等于不知道质量 RAGAs Ragas 等工具必须用。
一 数据切分:chunk 策略决定 RAG 上限
RAG 的所有问题 80% 都源于 chunk 切错。固定长度 512 token 切是最大反模式 一份完整文档被切碎后语义支离破碎 检索到的 chunk 缺乏上下文 LLM 就只能瞎编。下面是经过踩坑总结的 chunk 策略。
# 1 RecursiveCharacterTextSplitter 推荐 默认起手
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # 中文 500 字符约 250 token
chunk_overlap=50, # 10% 重叠保上下文
separators=["\n\n", "\n", "。", "!", "?", ";", ",", " "], # 中文分隔符
length_function=len
)
chunks = splitter.split_text(document)
# 2 按文档结构切 法律判决/合同必用
def split_by_structure(text):
"""按章节标题切 保持完整段落"""
import re
# 识别"一、二、三"或"第X条"
sections = re.split(r'(?=第\s*[一二三四五六七八九十百\d]+\s*条|^[一二三四五六七八九十]+、)', text, flags=re.M)
chunks = []
for sec in sections:
if len(sec) < 200:
chunks.append(sec)
else:
# 长段落再细分
sub_chunks = splitter.split_text(sec)
chunks.extend(sub_chunks)
return chunks
# 3 句子边界切 + 滑动窗口
import jieba
def sentence_window_split(text, window=3, stride=1):
"""每个 chunk 是 N 句话 滑动 stride 句"""
sentences = re.split(r'[。!?]', text)
sentences = [s for s in sentences if len(s.strip()) > 10]
chunks = []
for i in range(0, len(sentences), stride):
chunk = '。'.join(sentences[i:i+window])
chunks.append(chunk)
return chunks
# 4 Parent-Child 索引 关键技巧
# 检索时用小 chunk(精确匹配) 返回时用大 chunk(完整上下文)
class ParentChildIndex:
def __init__(self):
self.children = [] # 小 chunk 用于检索
self.parents = {} # 大 chunk 用于上下文
def add_document(self, doc):
parent_chunks = self.split_large(doc, size=2000) # 大 chunk
for i, parent in enumerate(parent_chunks):
parent_id = f"p_{i}"
self.parents[parent_id] = parent
# 每个 parent 切成 5-10 个 children
for child in self.split_small(parent, size=300):
self.children.append({
"text": child,
"parent_id": parent_id
})
def search(self, query, top_k=5):
# 用 children 检索
matched_children = vector_search(query, self.children, top_k)
# 返回 parent
parent_ids = list(set(c["parent_id"] for c in matched_children))
return [self.parents[pid] for pid in parent_ids]
实战经验:chunk 大小 200-500 token 是甜区 太小语义不全 太大检索精度差;按文档结构切优于按字符切;Parent-Child 索引是质量飞跃 检索精度提升 30% 上下文完整性提升 50%。律所场景我们最后用 按"条款 + 案号"双层切 每个条款独立 chunk 整个判例做 parent。
二 混合检索:Hybrid Search 才是真生产
纯向量检索的硬伤是关键词不敏感 律师问"张三诉李四"向量模型可能返回"李四诉王五"因为名字向量太相似。生产 RAG 必须混合 BM25(精确关键词)+ 向量(语义相似) 用 RRF 融合两路结果。
# 1 BM25 + 向量混合
from rank_bm25 import BM25Okapi
import numpy as np
# 准备 BM25 索引
tokenized_corpus = [list(jieba.cut(doc)) for doc in documents]
bm25 = BM25Okapi(tokenized_corpus)
# 向量索引
from sentence_transformers import SentenceTransformer
encoder = SentenceTransformer("BAAI/bge-large-zh-v1.5")
embeddings = encoder.encode(documents)
def hybrid_search(query, top_k=20):
# BM25 召回
tokenized_query = list(jieba.cut(query))
bm25_scores = bm25.get_scores(tokenized_query)
bm25_top = np.argsort(bm25_scores)[::-1][:top_k]
# 向量召回
query_vec = encoder.encode([query])[0]
vec_scores = np.dot(embeddings, query_vec)
vec_top = np.argsort(vec_scores)[::-1][:top_k]
# RRF 融合 Reciprocal Rank Fusion
rrf_scores = {}
k = 60
for rank, idx in enumerate(bm25_top):
rrf_scores[idx] = rrf_scores.get(idx, 0) + 1 / (k + rank)
for rank, idx in enumerate(vec_top):
rrf_scores[idx] = rrf_scores.get(idx, 0) + 1 / (k + rank)
# 排序返回
sorted_ids = sorted(rrf_scores.items(), key=lambda x: -x[1])
return [documents[i] for i, _ in sorted_ids[:top_k]]
# 2 Qdrant/Weaviate 等向量库内置 hybrid
# Qdrant 示例
from qdrant_client import QdrantClient
from qdrant_client.models import Fusion, FusionQuery, Prefetch
client = QdrantClient(host="localhost")
results = client.query_points(
collection_name="legal_docs",
prefetch=[
Prefetch(query=query_vec, using="dense", limit=20),
Prefetch(query=sparse_vec, using="sparse", limit=20)
],
query=FusionQuery(fusion=Fusion.RRF),
limit=10
)
用户问题往往表述不规范 同一个意图可能有 5 种不同问法。multi-query 用 LLM 改写原始问题 生成多个语义等价的查询 各自检索后合并去重 召回率能再提 10% 但要付出额外 LLM 调用成本。
# 3 多查询 multi-query 召回更全
def multi_query_search(original_query, top_k=20):
"""让 LLM 生成 N 个相似查询 各自检索后合并"""
similar_queries = llm_rewrite(original_query, n=3)
# 例如:
# "上海2023年劳动合同纠纷"
# 生成: "上海地区 2023 年员工劳动争议判例"
# "沪 2023 劳动合同诉讼"
# "2023 上海劳工权益案件"
all_results = []
for q in [original_query] + similar_queries:
all_results.extend(hybrid_search(q, top_k))
# 去重 + 按出现频次排序
return dedupe_and_rerank(all_results)
实战经验:BM25 + 向量 RRF 融合是生产 RAG 标配 比单路检索召回率提升 20-30%;多查询 multi-query 再提 10% 但加 LLM 调用成本;Qdrant 1.10+ 与 Weaviate 都内置 hybrid 不用自己拼。
三 重排序:cross-encoder 决定最终质量
检索得到 top 100 之后必须用 cross-encoder 重排 top 5。bi-encoder(向量模型)对每个文档独立打分 cross-encoder 对 query+doc pair 联合打分 精度高 5-10 倍 但慢 100 倍 所以只能用在精排小集合。
# 1 cross-encoder 重排
from sentence_transformers import CrossEncoder
reranker = CrossEncoder("BAAI/bge-reranker-large")
def rerank(query, candidates, top_k=5):
"""对粗排结果用 cross-encoder 精排"""
pairs = [(query, doc) for doc in candidates]
scores = reranker.predict(pairs)
# 按分数排序
ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
return [doc for doc, _ in ranked[:top_k]]
# 完整 pipeline:
def production_retrieve(query, top_k=5):
# 1. 粗排 hybrid search 取 top 100
candidates = hybrid_search(query, top_k=100)
# 2. 精排 cross-encoder 取 top 5
final = rerank(query, candidates, top_k=top_k)
return final
# 2 用 Cohere Rerank API 商业方案
import cohere
co = cohere.Client(api_key="YOUR_KEY")
results = co.rerank(
query="上海2023劳动合同",
documents=candidates,
top_n=5,
model="rerank-multilingual-v3.0"
)
for r in results.results:
print(f"Score: {r.relevance_score:.3f} Doc: {r.document['text'][:100]}")
# 3 LLM-as-reranker 终极方案 慢但准
def llm_rerank(query, candidates, top_k=5):
"""用 GPT-4 做 reranker"""
prompt = f"""给定查询"{query}"
判断下面每个文档与查询的相关性 0-10 打分。
文档:
"""
for i, doc in enumerate(candidates):
prompt += f"\n[{i}] {doc[:300]}"
prompt += "\n输出 JSON {\"scores\": [0, 8, 3, ...]}"
response = openai_client.chat.completions.create(
model="gpt-4o-mini", # mini 够用 还便宜
messages=[{"role": "user", "content": prompt}]
)
scores = json.loads(response.choices[0].message.content)["scores"]
ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
return [doc for doc, _ in ranked[:top_k]]
实战经验:加上 reranker 是 RAG 质量飞跃的最关键一步 我们实测从 60% 准确率提升到 89%;bge-reranker-large 开源最佳 中文场景实测优于 cohere 多语言版;延迟可接受范围内 top 100 重排 5 大约 500ms。
四 Metadata 过滤:精准检索的命门
律所场景"上海 2023 劳动合同纠纷"必须先按地区+时间+案由过滤 再做向量检索 否则返回的是全国 5 年内所有合同纠纷 准确率必崩。metadata filter 是生产 RAG 必备工程能力。
# 1 文档入库时打 metadata
documents = [
{
"text": "张三诉李四劳动合同纠纷判决...",
"metadata": {
"case_id": "2023沪01民终123号",
"region": "上海",
"year": 2023,
"court_level": "中级",
"case_type": "劳动合同纠纷",
"judge": "王法官",
"status": "生效",
"valid_law": ["劳动合同法 2008 修订"]
}
}
]
# 2 Qdrant 支持 metadata filter
from qdrant_client.models import Filter, FieldCondition, Range, MatchValue
filter_condition = Filter(
must=[
FieldCondition(key="region", match=MatchValue(value="上海")),
FieldCondition(key="year", range=Range(gte=2023, lte=2024)),
FieldCondition(key="case_type", match=MatchValue(value="劳动合同纠纷")),
FieldCondition(key="status", match=MatchValue(value="生效"))
]
)
results = client.search(
collection_name="legal_docs",
query_vector=query_vec,
query_filter=filter_condition,
limit=10
)
# 3 LLM 提取 filter 条件 自动化
def extract_filters(query):
"""让 LLM 从自然语言提取 metadata filter"""
prompt = f"""从查询中提取 filter 条件 JSON 格式
查询: "{query}"
可能字段: region year case_type court_level status
输出: {{"region": "上海", "year": 2023, ...}}
没有的字段省略。
"""
response = openai_client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"}
)
return json.loads(response.choices[0].message.content)
# 自动化检索
def smart_retrieve(query):
filters = extract_filters(query)
filter_obj = build_qdrant_filter(filters)
return client.search(
collection_name="legal_docs",
query_vector=encoder.encode(query),
query_filter=filter_obj,
limit=10
)
# 4 时间衰减 score boost 让新文档优先
def time_decay_boost(results, decay_rate=0.1):
"""新文档加 boost 旧文档降权"""
now = datetime.now().year
for r in results:
age = now - r.payload["year"]
decay = (1 - decay_rate) ** age
r.score *= decay
return sorted(results, key=lambda x: -x.score)
实战经验:metadata filter 是粗暴但有效的精度提升 律所场景加上区域 + 年份 + 案由三层 filter 后准确率从 70% 提到 92%;LLM 自动提取 filter 比规则灵活;时间衰减让新法律优先 避免引用废止条款。
五 引用追溯与上下文压缩
RAG 最大优势是可解释 每个答案都能溯源到具体文档。但 naive RAG 把 5 个 chunk 拼成 prompt 让 GPT 生成 用户根本不知道答案来自哪。引用追溯 + 上下文压缩 是企业级 RAG 的关键工程能力。
# 1 强制引用 prompt 设计
RAG_PROMPT = """你是一个专业的法律助手。基于下面提供的判例片段回答用户问题。
要求:
1. 答案必须基于提供的片段 不要编造
2. 每个论点后必须标注来源 [^N]
3. 如果片段不足以回答 直接说"提供的资料不足"
提供的片段:
{context}
用户问题: {question}
答案(必须带引用):
"""
def build_context_with_ids(retrieved_docs):
"""每个 chunk 加 ID 用于引用"""
context = ""
sources = []
for i, doc in enumerate(retrieved_docs, 1):
context += f"\n[{i}] {doc['text']}\n"
sources.append({
"id": i,
"case_id": doc["metadata"]["case_id"],
"url": f"/docs/{doc['metadata']['case_id']}"
})
return context, sources
def rag_answer(question):
docs = production_retrieve(question, top_k=5)
context, sources = build_context_with_ids(docs)
prompt = RAG_PROMPT.format(context=context, question=question)
answer = llm.generate(prompt)
# 后处理 把 [^N] 替换成可点击链接
for s in sources:
answer = answer.replace(f"[^{s['id']}]",
f"[[{s['case_id']}]({s['url']})]")
return answer, sources
引用追溯解决"答案从哪来"问题 但还有另一个棘手问题:LLM 对长上下文中间部分的关注度显著低于头尾 这就是著名的 lost in the middle 现象。解决思路是双管齐下 一是压缩上下文减少噪音 二是重新排列让关键信息出现在头尾位置。
# 2 上下文压缩 解决 lost in the middle
# 长上下文 LLM 对中间内容关注度低 必须压缩
def compress_context(query, docs):
"""用小 LLM 提取每个 doc 与 query 相关的核心句"""
compressed = []
for doc in docs:
prompt = f"""从下面文档中提取与问题最相关的 1-3 句话
问题: {query}
文档: {doc['text']}
仅输出相关句子 不要解释。
"""
response = small_llm.generate(prompt) # 用 GPT-4o-mini
compressed.append({**doc, "text": response})
return compressed
# 3 关键信息前置 解决 lost in the middle
def reorder_for_attention(docs):
"""高相关性放头尾 低相关性放中间
LLM 对头尾 token 关注度最高"""
docs_sorted = sorted(docs, key=lambda x: -x.score)
n = len(docs_sorted)
reordered = [None] * n
# 奇偶交替放置
for i, doc in enumerate(docs_sorted):
if i % 2 == 0:
reordered[i // 2] = doc
else:
reordered[n - 1 - i // 2] = doc
return reordered
# 4 引用验证 防 LLM 编造引用
def verify_citations(answer, sources):
"""检查答案中的引用是否真存在"""
import re
cited = re.findall(r'\[\^?(\d+)\]', answer)
valid_ids = {s["id"] for s in sources}
for c in cited:
if int(c) not in valid_ids:
return False, f"引用了不存在的 [{c}]"
return True, "OK"
实战经验:强制引用 prompt 让 RAG 可信度暴涨 用户能验证 LLM 不敢瞎编;上下文压缩节省 60-80% token 还提升答案质量;reorder 解决 lost in the middle 实测对 8K+ 上下文有效;引用验证防 LLM 编造引用号 是必备最后一道防线。
[mermaid]
flowchart TD
A[用户问题] --> B[LLM 提取 metadata filter]
B --> C[多查询改写]
C --> D[BM25 检索 top 100]
C --> E[向量检索 top 100]
D --> F[RRF 融合]
E --> F
F --> G[metadata filter 过滤]
G --> H[cross-encoder 重排 top 5]
H --> I[上下文压缩]
I --> J[关键信息前置 reorder]
J --> K[LLM 生成带引用答案]
K --> L[引用验证]
L -->|失败| M[Fallback 提示资料不足]
L -->|成功| N[返回答案 + sources]
六 评估闭环:让 RAG 持续改进
RAG 没有评估等于裸奔 你不知道改一个 chunk 大小是好是坏 不知道换一个 embedding 模型是涨是跌。生产 RAG 必须有评估体系 离线评测 + 在线 A/B + 用户反馈 三位一体。
# 1 RAGAs 标准评估 4 个核心指标
# pip install ragas
from ragas import evaluate
from ragas.metrics import (
faithfulness, # 答案是否基于上下文(防幻觉)
answer_relevancy, # 答案是否回答问题
context_precision, # 检索精度(top 排序质量)
context_recall # 检索召回率(应该召回的有没有召回)
)
from datasets import Dataset
# 构造评估集
eval_data = Dataset.from_dict({
"question": ["上海2023劳动合同纠纷如何举证"],
"answer": [generated_answer],
"contexts": [[doc["text"] for doc in retrieved_docs]],
"ground_truth": ["按 2008 劳动合同法第 8 条..."]
})
result = evaluate(
eval_data,
metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)
# {faithfulness: 0.85, answer_relevancy: 0.92, context_precision: 0.78, context_recall: 0.83}
# 2 测试集自动构造
def generate_test_set(documents, n=100):
"""用 LLM 从文档自动构造 question-answer pair"""
test_set = []
for doc in random.sample(documents, n):
prompt = f"""基于下面文档生成 1 个问题和答案
文档: {doc}
输出 JSON {{"question": "...", "answer": "..."}}"""
response = llm.generate(prompt)
test_set.append(json.loads(response))
return test_set
# 3 持续评估 CI 集成
def regression_eval(new_pipeline, test_set, baseline_metrics):
"""每次 pipeline 改动都跑回归"""
new_metrics = run_evaluation(new_pipeline, test_set)
for metric, baseline in baseline_metrics.items():
if new_metrics[metric] < baseline - 0.02: # 下降超过 2% 报警
raise Exception(f"{metric} regressed from {baseline} to {new_metrics[metric]}")
return new_metrics
# 4 用户反馈闭环
class FeedbackCollector:
def log(self, question, answer, sources, user_feedback):
"""收集 thumbs up/down + 修正答案"""
db.insert("rag_feedback", {
"question": question,
"answer": answer,
"sources": sources,
"rating": user_feedback["rating"], # 1-5
"correction": user_feedback.get("correction"),
"timestamp": datetime.now()
})
def analyze_failures(self):
"""分析低分案例 找共性问题"""
failures = db.query("SELECT * FROM rag_feedback WHERE rating <= 2")
# 用 LLM 聚类原因
# - 检索失败(没找到相关 doc)
# - 重排错误(找到了但排序差)
# - 生成幻觉(上下文有但答案错)
# - 引用错误
return cluster_failures(failures)
实战经验:RAGAs 是开源最佳评估框架 4 个指标缺一不可;每周从用户反馈中挑 50 个低分案例分析改进;每次 pipeline 改动都跑回归 防止退化。我们 RAG 系统迭代 6 个月 准确率从 60% 提升到 91% 全靠这套评估闭环。
关键概念速查
| 概念 | 说明 | 推荐 | 备注 |
|---|---|---|---|
| Chunk 切分 | 文档拆分粒度 | 200-500 token | 按结构 + 重叠 |
| Parent-Child | 双层索引 | 必用 | 检索精上下文完 |
| Hybrid Search | BM25 + 向量 | RRF 融合 | 召回率+20% |
| Reranker | cross-encoder 精排 | bge-reranker-large | 质量飞跃关键 |
| Metadata Filter | 结构化过滤 | 必用 | 地区时间类型 |
| Multi-query | 查询改写 | +10% 召回 | LLM 改写 |
| 引用追溯 | source 链接 | 必备 | 企业级可解释 |
| 上下文压缩 | 提取相关句 | 省 60% token | 解 lost middle |
| RAGAs | 评估框架 | 必用 | 4 个核心指标 |
| 用户反馈 | 持续改进闭环 | thumbs + 修正 | 迭代源泉 |
避坑清单
- 不要用默认 512 token 固定切 必须按语义 + 文档结构 + 重叠切。
- 不要只用向量检索 必须 BM25 + 向量 hybrid 否则关键词查询会废。
- 不要省 reranker 这是质量飞跃最关键一步 准确率提升 30%。
- 不要忽视 metadata filter 时间地区类型先过滤再向量是精度命门。
- 不要让 LLM 无引用回答 必须 prompt 强制引用 + 后处理验证。
- 不要 8K+ 上下文堆在中间 解 lost in the middle 把关键信息前置。
- 不要不评估 必须 RAGAs 4 指标 + 测试集 + 回归 + 用户反馈四位一体。
- 不要忽视 embedding 模型选择 BAAI/bge 系列中文场景远优于 OpenAI ada。
- 不要把 top 5 直接喂 LLM 必须先压缩 否则 token 浪费 60% 还影响质量。
- 不要一次性上完整 pipeline 必须分阶段:naive RAG → hybrid → rerank → metadata → 评估闭环。
总结
把 RAG 这套从我们踩过的所有坑里反过来看 你会发现真正影响投产成败的不是 LLM 不是 embedding 模型 而是工程化的全栈能力。同样一份判例库 naive RAG 律师骂街准确率 60% 加上 hybrid + rerank + metadata filter + 引用追溯 + 评估闭环 准确率 91% 律师反过来主动推广;同样一个 LLM GPT-4 喂错 chunk 给瞎答案 喂精排好的 chunk 给精准引用。RAG 不是 LangChain demo 30 行代码就够的玩具 它是一个 切分策略 + 混合检索 + 重排序 + metadata 过滤 + 引用追溯 + 上下文压缩 + 评估闭环 的完整系统工程。
另一个常见的认知误区是把 RAG 当成 LLM 的补丁 觉得只要把文档塞 prompt LLM 就懂了。但事实是 RAG 是一个完整的检索系统 LLM 只是最后一步生成器 真正的难点在检索质量。检索差 LLM 再强也救不了;检索好 即使用 GPT-4o-mini 也能输出企业级答案。RAG 的核心竞争力在 retrieval 不在 generation。
打个比方 RAG 像企业法务部的工作流。文档库是判例库 chunk 切分是按案号建索引卡片 hybrid search 是同事用关键词 + 同事用主题词双重检索 reranker 是资深律师初筛后精挑 metadata filter 是按地区/年份/案由先分类再找 上下文压缩是把判决书摘出核心论点 引用追溯是每个论点都标案号 评估闭环是法官打分 + 律师反馈。哪一环缺了 这个法务部的输出就不能交客户 即使你的律师团队水平再高。
所以下一次再有人跟你说 RAG 就是 embed + 检索 + LLM 你可以反问他 你 chunk 怎么切的 hybrid 上了吗 reranker 用了吗 metadata filter 设了吗 引用追溯做了吗 lost in the middle 解了吗 RAGAs 跑了吗 用户反馈闭环了吗 这些工作没做完 RAG 只是一个能跑通 demo 的玩具 不是一个能扛企业客户的智能问答系统。从踩坑到投产 中间隔着一整套工程方法论 这条路没有捷径 但走完之后 你的 RAG 系统会从客户投诉变成客户依赖 从准确率 60% 变成 91% 从烧 token 烧到亏损变成 ROI 正向。
—— 别看了 · 2026