LlamaIndex优化：八种方法提升检索答案质量

分块策略、混合检索、重排序、HyDE、上下文压缩、元数据过滤、自适应k值——八个实用技巧快速改善检索质量

RAG系统答不准问题，本质上是检索精度的问题。LlamaIndex本身提供的调优空间还挺大，不用推翻重写就能把准确率往上拉一截。本文整理了八个实际用过的优化手段，针对性解决幻觉、上下文错位、答案不靠谱这些常见毛病。建议先选两三个测试效果，有改善再叠加其他的。

1) 分块要考虑语义完整性

把文档切得太碎不一定是好事。如果分块把定义、表格、列表这些结构性内容拦腰切断，模型拿到的上下文就是残缺的。

所以要用句子级别的分割器，设置合理的重叠区间，保证每个节点语义完整。

from llama_index.core.node_parser import SentenceSplitter
from llama_index.core import Settings
# Good default for most tech docs
splitter = SentenceSplitter(chunk_size=512, chunk_overlap=64)
nodes = splitter.get_nodes_from_documents(documents)
# Embed + index as usual
Settings.chunk_size = 512 # keep aligned

比如代码文档和API说明用384-768 tokens，重叠比例10-15%左右。长篇PDF文档可以放宽到768-1024，overlap设64基本够用，能保持引用关系不断。

2) 扩展命中句子的上下文窗口

单独一句话作为检索结果，用户看着没把握。LlamaIndex的sentence-window后处理器会在命中句子前后各补几句，让返回的片段更连贯，也更方便直接引用。

from llama_index.postprocessor.sentence_window import SentenceWindowNodePostprocessor
post = SentenceWindowNodePostprocessor(
window_size=2, # grab ±2 sentences
original_text=True
)
retriever = index.as_retriever(similarity_top_k=8, node_postprocessors=[post])

适用场景：FAQ、规章制度、会议纪要这类文档特别有用，往往一句话的差异就能改变整个答案的意思。

3) 向量检索配合BM25做混合召回

向量embedding擅长捕捉语义相似度，BM25擅长精确匹配关键词。两个方法各有偏向，融合起来用效果明显好于单一方案。

from llama_index.retrievers.bm25 import BM25Retriever
from llama_index.core.retrievers import VectorIndexRetriever
from llama_index.retrievers.fusion import QueryFusionRetriever
bm25 = BM25Retriever.from_defaults(docstore=index.docstore, similarity_top_k=10)
vec = VectorIndexRetriever(index=index, similarity_top_k=10)
hybrid = QueryFusionRetriever(
retrievers=[vec, bm25],
similarity_top_k=10, # final top-k after fusion
mode="reciprocal_rerank" # simple, strong baseline
)

内部知识库测试，混合检索+rerank（下一条会说）相比纯向量检索，correct@1指标能提升10-18%左右。

4) 用cross-encoder做二次排序

检索阶段只是粗筛候选，真正决定哪些结果靠谱还得靠reranker。一个轻量的cross-encoder模型（比如MiniLM）能有效把那些看起来相似但实际答非所问的结果往后排。

from llama_index.postprocessor import SentenceTransformerRerank
rerank = SentenceTransformerRerank(
model="cross-encoder/ms-marco-MiniLM-L-6-v2",
top_n=5
)
retriever = index.as_retriever(similarity_top_k=20, node_postprocessors=[rerank])

cross-encoder会同时看query和passage，不是简单的向量相似度比对而是直接判断段落是否真的在回答问题。

5) 查询重写：HyDE和多query生成

用户的问题经常描述不清楚。HyDE (Hypothetical Document Embeddings) 的思路是让LLM先生成一个理想答案，然后用这个假设答案去embedding和检索，能减少query本身表达不清造成的召回偏差。Multi-query则是生成多个改写版本，从不同角度去检索。

from llama_index.core.query_engine import RetrieverQueryEngine
from llama_index.core.query_transform.base import HyDEQueryTransform
from llama_index.core.query_transform import MultiQueryTransform
base_retriever = index.as_retriever(similarity_top_k=12)
hyde = HyDEQueryTransform() # creates hypothetical answer
multi = MultiQueryTransform(num_queries=4) # diverse paraphrases
engine = RetrieverQueryEngine.from_args(
retriever=base_retriever,
query_transform=[hyde, multi] # chain transforms
)

例如那种模糊的业务问题，像"怎么回滚计费系统"，或者行业术语有歧义的领域，这个方法效果不错。

6) 元数据过滤优先于向量检索

不是所有文档都需要参与检索。如果能提前用metadata把范围限定在特定产品、版本、团队、时间段，检索效率和准确性都会高很多。

from llama_index.core.vector_stores.types import MetadataFilters, ExactMatchFilter, FilterCondition
from llama_index.core.retrievers import VectorIndexRetriever
filters = MetadataFilters(
filters=[ExactMatchFilter(key="product", value="billing"),
ExactMatchFilter(key="version", value="v3")],
condition=FilterCondition.AND
)
retriever = VectorIndexRetriever(
index=index,
similarity_top_k=12,
filters=filters
)

对于政策文档和release notes，可以在后处理阶段加个时间过滤，防止过时信息混进来。

7) 压缩冗余上下文

长context不仅费token，还会引入噪声。Contextual compression能把检索到的内容再过滤一遍，只留下跟当前问题强相关的部分。

from llama_index.retrievers import ContextualCompressionRetriever
from llama_index.postprocessor import LLMRerank
base = index.as_retriever(similarity_top_k=12)
# Use an LLM-powered deephub relevance filter or a local mini model
compressor = LLMRerank(top_n=6)
compressed_retriever = ContextualCompressionRetriever(
base_retriever=base,
compressor=compressor
)

这样prompt变短，答案也更聚焦，成本降下来了，这种方式对于处理那种章节很长的PDF特别管用。

8) 动态调整top_k：基于相似度阈值

写死top_k其实挺粗的。如果检索出来的结果分数都很低，硬塞进prompt反而干扰模型；如果前几个结果分数已经很高，后面的也没必要全要。

from llama_index.postprocessor import SimilarityPostprocessor
cut = SimilarityPostprocessor(similarity_cutoff=0.78)
retriever = index.as_retriever(similarity_top_k=20, node_postprocessors=[cut])
# Optional: shrink k dynamically deep hub based on score slope
def dynamic_k(scores, min_k=3, max_k=12, drop=0.08):
# when score difference flattens, stop
k = min_k
for i in range(1, min(len(scores), max_k)):
if scores[i-1] - scores[i] > drop:
k = i+1
return max(min_k, min(k, max_k))

把"总是塞进一堆垃圾"变成"只要有用的部分",单靠这一条改动，幻觉率就能明显下降。

组合使用的一个完整pipeline示例

实际项目里这些技巧通常会组合用：

数据准备阶段：用sentence-aware splitter切分文档（512/64），同时给每个chunk打上metadata（product、version、date、author等）

检索阶段：混合检索（vector + BM25）→ 相似度阈值过滤 → cross-encoder重排序

Query处理：对模糊问题用HyDE + multi-query做改写

结果精简：用LLM或embedding rerank压缩到4-8个高相关句子

生成答案：把精简后的context喂给LLM，记得标注引用来源

实测：某个2400份文档的内部知识库，上了混合检索 + rerank + 元数据过滤这套组合，correct@1从63%涨到78%，"我不确定"这类回答少了30%左右。具体效果会因数据而异，但宽召回、严过滤、精确引用这个思路基本适用。

一个可运行的代码示例

from llama_index.core import VectorStoreIndex
from llama_index.retrievers.bm25 import BM25Retriever
from llama_index.retrievers.fusion import QueryFusionRetriever
from llama_index.postprocessor import SentenceTransformerRerank, SimilarityPostprocessor
from llama_index.postprocessor.sentence_window import SentenceWindowNodePostprocessor
from llama_index.core.query_engine import RetrieverQueryEngine
from llama_index.core.query_transform.base import HyDEQueryTransform
from llama_index.core.query_transform import MultiQueryTransform
# Build your index deep elsewhere; assume `index` hub exists.
bm25 = BM25Retriever.from_defaults(docstore=index.docstore, similarity_top_k=10)
vec = index.as_retriever(similarity_top_k=12)
hybrid = QueryFusionRetriever(
retrievers=[vec, bm25],
similarity_top_k=16,
mode="reciprocal_rerank"
)
post = [
SimilarityPostprocessor(similarity_cutoff=0.78),
SentenceTransformerRerank(model="cross-encoder/ms-marco-MiniLM-L-6-v2", top_n=6),
SentenceWindowNodePostprocessor(window_size=2, original_text=True),
]
engine = RetrieverQueryEngine.from_args(
retriever=hybrid,
node_postprocessors=post,
query_transform=[HyDEQueryTransform(), MultiQueryTransform(num_queries=4)]
)
resp = engine.query("How do we safely roll back billing in v3?")
print(resp)

评估指标

衡量检索好坏真正有用的指标就这几个：

Correct@1— 人工评判或抽样标注。全量标注不现实的话，每个迭代周期标50个query就够看出趋势

可引用性— 平均context长度和引用片段数。越短越清晰的引用，用户信任度越高

延迟预算— p95首token时间。压缩带来的收益通常能cover掉rerank的开销

安全机制— 当top结果分数都低于阈值时，明确返回"未找到可靠信息"，别硬答

RAG质量其实就是工程问题。几个靠谱的默认配置加上精细的后处理，效果就能上一个台阶。

总结

先从chunking和sentence window入手，这两个改动成本最低。然后加混合检索和cross-encoder，这是性价比最高的组合。后面再根据实际问题针对性地补充HyDE/multi-query（解决query不清晰）、metadata filter（限定范围）、compression（降噪）、adaptive k（提升置信度）。第一次demo就能看出明显差异。

https://avoid.overfit.cn/post/208912f9e31f413ab3c7bc9807a467ec

作者：Hash Block