LlamaIndex检索调优实战：七个能落地的技术细节

RAG系统搭完其实才是工作的开始，实际跑起来你会发现，答案质量参差不齐，有时候精准得吓人、有时候又会非常离谱。这个问题往往不模型本身，而是在检索环节的那些"小细节"。

这篇文章整理了七个在LlamaIndex里实测有效的检索优化点，每个都带代码可以直接使用。

1、语义分块 + 句子窗口

固定长度切分文档是最省事的做法，但问题也很明显：这样经常把一句话从中间劈开，上下文断裂，检索器只能硬着头皮匹配这些残缺的片段。

所以LlamaIndex提供了两个更聪明的解析器。SemanticSplitter会在语义边界处切分，不再机械地按字数来；SentenceWindow则给每个节点附加前后几句话作为上下文窗口。并且这两者还可以组合使用，能达到不错的效果：

# pip install llama-index

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

from llama_index.core.node_parser import (

  SemanticSplitterNodeParser, SentenceWindowNodeParser

)

docs = SimpleDirectoryReader("./knowledge_base").load_data()

# Step 1: Semantically aware base chunks

semantic_parser = SemanticSplitterNodeParser(buffer_size=1, breakpoint_percentile_threshold=95)

semantic_nodes = semantic_parser.get_nodes_from_documents(docs)

# Step 2: Add sentence-window context to each node

window_parser = SentenceWindowNodeParser(window_size=2, window_metadata_key="window")

nodes = window_parser.get_nodes_from_documents(semantic_nodes)

index = VectorStoreIndex(nodes)

检索模型打分的对象是单个节点，所以让每个节点包含完整的语义单元，再带上一点其他的附加信息，命中率自然就上去了。

2、BM25 + 向量的混合检索

向量嵌入擅长捕捉语义相似性，但碰到专业缩写、产品型号这类精确匹配场景就容易翻车。老牌的BM25算法恰好补上这个短板，它对精确词项敏感，长尾术语的召回能力很强。

把两种检索方式融合起来，LlamaIndex的QueryFusionRetriever可以直接搞定：

from llama_index.core.retrievers import QueryFusionRetriever

from llama_index.core import StorageContext

from llama_index.core.indices.keyword_table import SimpleKeywordTableIndex

# Build both indexes

vector_index = index  # from above

keyword_index = SimpleKeywordTableIndex.from_documents(docs)

retriever = QueryFusionRetriever(

  retrievers=[

      vector_index.as_retriever(similarity_top_k=5),

      keyword_index.as_retriever(similarity_top_k=5)

  ],

  num_queries=1,            # single query fused across retrievers

  mode="simple",            # RRF-style fusion

)

BM25抓精确匹配，向量抓语义关联，RRF融合后的top-k质量通常比单一方法好一截，而且不用写多少额外代码。

3、多查询扩展

用户的提问方式千奇百怪，同一个意图可以有很多种表达方法。所以单一query去检索很可能漏掉一些相关但措辞不同的文档。

多查询扩展的思路就是：自动生成几个query的变体，分别检索，再把结果融合起来。

from llama_index.core.retrievers import QueryFusionRetriever

multi_query_retriever = QueryFusionRetriever.from_defaults(

  retriever=vector_index.as_retriever(similarity_top_k=4),

  num_queries=4,            # generate 4 paraphrases

  mode="reciprocal_rerank", # more robust fusion

)

如果业务场景涉及结构化的对比类问题（比如"A和B有什么区别"），还可以考虑query分解：先拆成子问题，分别检索，最后汇总。

不同的表述会激活embedding空间里不同的邻居节点，所以这种融合机制保留了多样性，同时让多个检索器都认可的结果排到前面。

4、reranker

初筛拿回来的top-k结果，质量往往是"还行"的水平。如果想再往上提一个档次reranker是个好选择。

和双编码器不同，交叉编码器会把query和passage放在一起过模型，对相关性的判断更精细。但是问题就是慢，不过如果只跑在候选集上延迟勉强还能接受：

from llama_index.postprocessor.cohere_rerank import CohereRerank

# or use a local cross-encoder via Hugging Face if preferred

reranker = CohereRerank(api_key="COHERE_KEY", top_n=4)  # keep the best 4

query_engine = vector_index.as_query_engine(

  similarity_top_k=12,

  node_postprocessors=[reranker],

)

response = query_engine.query("How does feature X affect Y?")

先用向量检索快速圈出候选（比如top-12），再用交叉编码器精排到top-4。速度和精度之间取得了不错的平衡。

5、元数据过滤与去重

不是所有检索回来的段落都值得信任，文档有新有旧，有的是正式发布版本，有的只是草稿。如果语料库里混着不同版本、不同产品线的内容，不加过滤就是给自己挖坑。

元数据过滤能把检索范围限定在特定条件内，去重则避免相似内容重复占用上下文窗口，时间加权可以让新文档获得更高权重：

from llama_index.core.retrievers import VectorIndexRetriever

from llama_index.postprocessor import (

  SimilarityPostprocessor, DuplicateRemovalPostprocessor

)

retriever = VectorIndexRetriever(

  index=vector_index,

  similarity_top_k=12,

  filters={"metadata": {"product": "alpha"}}  # simple example

)

post = [

  DuplicateRemovalPostprocessor(),

  SimilarityPostprocessor(similarity_cutoff=0.78),

]

nodes = retriever.retrieve("Latest install steps for alpha build?")

nodes = [p.postprocess_nodes(nodes) for p in post][-1]

过滤器挡住不相关的文档，相似度阈值过滤掉弱匹配，去重保证多样性。这套组合操作下来，检索结果的下限被抬高了。

6、响应合成模式的选择

检索只是手段，最终目的是生成靠谱的答案。如果合成阶段没控制好，模型很容易脱离检索内容自由发挥，幻觉就来了。

LlamaIndex的"compact"模式会让模型更紧密地依赖检索节点，减少跑题的概率：

from llama_index.core.response_synthesizers import TreeSummarize, CompactAndRefine

# Balanced, citation-friendly option

qe = vector_index.as_query_engine(

  similarity_top_k=8,

  response_mode="compact",           # leans terse & grounded

  use_async=False,

)

ans = qe.query("Summarize the security model, cite sources.")

print(ans)   # includes source refs by default

严格来说这不算检索优化，但它形成了一个反馈闭环——如果发现答案经常跑偏，可能需要回头调整top-k或者相似度阈值。

7、持续评估

没有量化指标，优化就是在黑箱里瞎摸。建议准备一个小型评估集，覆盖核心业务场景的10到50个问题，每次调参后跑一遍，看看忠实度和正确率的变化。

from llama_index.core.evaluation import FaithfulnessEvaluator, CorrectnessEvaluator

faith = FaithfulnessEvaluator()  # checks grounding in retrieved context

corr  = CorrectnessEvaluator()   # compares to reference answers

eval_prompts = [

  {"q": "What ports do we open for service Z?", "gold": "Ports 443 and 8443."},

  # add 20–50 more spanning your taxonomy

]

qe = multi_query_retriever.as_query_engine(response_mode="compact", similarity_top_k=6)

scores = []

for item in eval_prompts:

  res = qe.query(item["q"])

  scores.append({

      "q": item["q"],

      "faithful": faith.evaluate(res).score,

      "correct":  corr.evaluate(res, reference=item["gold"]).score

  })

# Now look at averages, find weak spots, iterate.

当你发现系统在某类问题上总是出错：比如漏掉具体数字、把策略名称搞混等等，就就可以根据问题来进行调整了，比如加大BM25权重？提高相似度阈值？换个更强的reranker？

几个容易踩的坑

分块太长会拖累召回率，节点应该保持聚焦，让句子窗口来承担上下文补充的任务。

Rerank不要对全量结果做，应该只在初筛的候选集上。

语料库如果混着多个产品版本，一定要在建索引时就加好version、env、product这些元数据字段，否则检索回来的可能是过时内容。

最后别凭感觉判断效果好不好，维护一个评估用的表格，记录每次调参后的分数变化，时间长了你会发现哪些参数对哪类问题影响最大。

总结

RAG的答案质量不靠单一银弹，而是一系列合理配置的叠加。建议先从混合检索和句子窗口两个点入手，观察效果，再逐步加入多查询扩展和reranker。

量化、调整、再量化，循环往复。

作者：Modexa

点个在看你最好看！