固定长度分块（512 或 1024 token）很方便但具有破坏性——它在概念中间切断，把相关信息打散，并强加与数据结构不对齐的任意边界。

三种更好的做法：

1. 语义分块：用 embedding 测量相邻句子的距离，超过阈值就切。保持相关的信息在一起，代价是预处理开销

2. 结构感知分块：边界对齐你的领域。代码按函数，医疗记录按就诊，支持工单按问题线程，技术文档按章节和代码块

3. 层次分块：多个抽象层级。短块用于细粒度检索，长摘要块用于上下文

元数据：每个 chunk 都该带

{
  "content": "chunk 文本",
  "metadata": {
    "source_url": "https://...",
    "section_title": "2.3 环境要求",
    "page": 12,
    "doc_type": "manual",
    "updated_at": "2026-08-15",
    "department": "运维"
  }
}

元数据有两个用途：过滤检索（只从当前生效文档里找）和让模型判断来源相关性。

把元数据做成可检索字段，在向量检索之前先缩小候选集——这是零成本的延迟优化。

二、混合检索：纯向量搜索不够

向量搜索擅长概念，但对精确术语很弱——产品型号、规范编号、函数名、错误码。

混合检索并行跑两者再融合结果。融合算法通常是 RRF（Reciprocal Rank Fusion）——它只依赖排名，绕开了两套系统分数不可比的问题。

具体收益：一个查 "错误码 ORA-12514" 的请求，纯向量检索效果很差，BM25 精准命中。

2026 年 Q1 有报告称企业混合检索采用率翻了三倍，驱动力正是生产团队发现纯向量搜索在精度敏感场景不够用。

RRF 的实现

def reciprocal_rank_fusion(rankings, k=60):
    """rankings: [(doc_id, rank), ...] 的列表，每个检索系统一个"""
    scores = {}
    for ranking in rankings:
        for doc_id, rank in ranking:
            scores[doc_id] = scores.get(doc_id, 0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda x: -x[1])

k=60 是常用默认值。含义是排第 1 的贡献远大于第 50 的，但不会让前几名完全支配结果。

三、重排序：投入产出比最高的一层

这是性价比最高的单点优化。

标准向量搜索按余弦相似度返回 top-K，这是粗筛。reranker（Cohere Rerank、BGE-Reranker 或微调的小模型）拿这 K 个候选，基于与查询的真实语义相关性重新排序。

成本是一次额外的 API 调用，收益常常是"demo 能用"和"用户敢信"的差别。

量化收益

• 交叉编码器重排序带来 +33–40% 准确率提升，平均只增加 约 120ms 延迟

• 某金融问答基准上，重排序把 MRR@3 提升了 39%

• 跳过重排序，质量下降约 20%

两阶段架构

用户问题
   │
   ├─ [阶段一：召回] bi-encoder 向量 + BM25 → top 50 候选
   │                （快，但有损——把语义压成单个向量）
   │
   ├─ [阶段二：精排] cross-encoder 逐对打分 → top 5
   │                （慢，但准——query 和 chunk 一起看）
   │
   └─ [生成] 送入 LLM

为什么 bi-encoder 不够：embedding 把语义压缩成单个向量，两个语义相近的 chunk 未必是对特定查询最相关的那个。cross-encoder 能同时看到 query 和 chunk，判断准确得多。

2026 年主流 reranker：Cohere Rerank、Voyage rerank、BGE reranker-v2、Jina Reranker v2，多数是一个 HTTP 调用。

四、查询改写：弥合词汇鸿沟

用户用自己的话提问，文档用作者的话写。

廉价版本：检索前让 LLM 把查询改写成 2-3 个替代表述，把结果取并集。

昂贵版本：在你的领域数据上微调一个小改写模型。

HyDE：反直觉但有效

Hypothetical Document Embeddings：让 LLM 先生成一个"理想答案"，然后把这个假想文档去 embedding 做检索，而不是用原始查询。

直觉上很奇怪，实际往往带来 10-15% 的召回提升。原因是：查询和文档的分布本来就不同，生成的假想文档更接近文档的分布。

五、上下文长度：抵抗的冲动

现代模型有 100K+ 的上下文窗口。克制住全部塞进去的冲动。

大多数问答任务在 3000-5000 token 之后收益就递减了。更多 token 意味着更高的延迟和成本，而质量提升微乎其微。

一句结构良好的 4000 token，胜过无结构的 8000 token。

这个判断要在你自己的评估集上验证，不要照搬。

六、评估：不测就是盲飞

RAGAS 是标准评估框架，四个核心指标：

建一个 50-200 条问题 + 期望答案的黄金集，在 CI 里对每次 prompt 或检索改动跑一遍。 数字涨了你知道，数字跌了你也知道是哪次改动导致的。

排查链路

出问题时按这个顺序查：

召回对不对？ →  记录 rerank 前后的 top-K
                ↓
embedding 一致吗？ → 索引和查询用同一模型吗
                ↓
chunk 质量如何？ → 语义连贯吗？有句子中间切断吗
                ↓
模型在无视上下文吗？ → 加 grounding 指令
                ↓
哪一阶段最慢？ → 延迟分解

先过滤，后变换：永远先用 geom 这类裸列做索引过滤，再做投影和几何计算，否则索引完全失效。

七、向量量化：规模上来后的成本杠杆

当语料超过几百万 chunk，全精度 float32 向量成为主要成本。

几乎总是值得做 int8。Pinecone、Weaviate、Qdrant、pgvector（HNSW）都开箱支持。

八、什么时候不该用 RAG

这是被跳过最多的一步。先做判断，再决定是否投入检索基础设施。