检索增强生成实践指南架构设计与常见误区解析

首页

热心网友

转载

2026-05-18

RAG系统在演示时总能惊艳全场，但一到生产环境就频频“翻车”。这并非运气不佳，而是行业里反复上演的同一个根本性错误：太多团队把检索增强生成（RAG）当作一个简单的库函数来调用，而实际上，它是一个需要通盘考虑的架构问题。

想想看这个熟悉的场景：演示会上，你提出一个问题，系统精准地从文档中提取相关段落，大模型据此生成完美答案。在场所有人点头称赞，有人说：“可以发布了。”然而，六个月后，这个系统往往悄无声息地停止了使用。

用户开始抱怨：答案会“幻觉”出根本不存在的文档；无论问什么，检索结果总是那固定的五个文本块；一旦加入新的文档类型，情况反而变得更糟，而且没人能说清原因。

这几乎是常态。其根源在于，我们将一个复杂的多级流水线，简化成了“安装框架，配置默认值”的几步操作。每一步单独看都合理，但叠加在一起，就构成了一个注定会以特定方式崩溃的系统。

一、常见的调用陷阱场景

走进大多数RAG项目，你会发现流程大同小异：用文档加载器读取PDF为文本，用默认分块器切成512个标记的片段（带50个标记的重叠），通过嵌入API将每个块转为向量，最后存入向量数据库。查询时，将用户问题嵌入，取前k个相似片段，交给大模型生成答案。

这个流程的每一步默认设置，都在为生产故障埋下伏笔：

文本块可能包含来自两个主题的半句话，导致其向量无法准确代表任何一个主题。检索结果返回的片段看似与多个问题都沾边，实则与任何一个都不真正相关。精确匹配（如搜索策略编号“PR-442”）会静默失败，因为密集向量搜索不擅长字面匹配。最近更新的文档无法被优先检索，因为元数据层往往是事后添加的，缺乏按时间筛选的能力。模型被赋予了一段包含关键词但缺乏实质内容的文本块，于是它基于训练数据“自信地”编造了一个看似合理的答案。

这些故障在精心准备的演示中不会出现，却会在真实、复杂的生产环境中逐一暴露。

二、RAG究竟是什么？

抛开营销术语，RAG本质上是由三条共享数据的管道构成的系统：

摄取管道：负责接收源文档，并将其转化为可检索的表示形式。
检索管道：接收查询，并返回相关的上下文。
生成管道：结合上下文和查询，生成最终答案。

第三条管道的质量，严格受限于前两条。如果正确的信息从未进入检索结果的前列，那么任何提示词技巧都无法将其找回。遗憾的是，许多团队将精力过度投入在提示工程上，反而忽视了真正决定系统上限的数据摄取和检索环节。

三、摄入层：决定这一切是否奏效的关键层

分块（Chunking）是首要且最重要的设计选择，它直接决定了检索系统能找到什么。

默认的固定标记窗口分割策略，对绝大多数真实语料库而言几乎是最糟糕的选择。它将文档视为无差别的词元流，无视章节标题与正文的关联，也意识不到表格行仅在表格内才有意义。它甚至会毫不犹豫地将包含答案的单个句子切成两半，导致每个片段都无法独立表达完整信息。

更好的实践路径有以下几种：

1. 结构感知分块：尊重文档的固有边界。Markdown有标题，PDF有章节，HTML有语义标签，代码有函数和类。这种分块器生成的单元是人类可识别的：子章节、函数、表格、列表。仅在块过大时进一步拆分，且绝不跨越结构边界。

2. 层级分块：索引时用细粒度（如段落），存储和返回时用粗粒度（如章节）。检索匹配小片段以保证精度，生成时则提供完整的上下文。这解决了“答案在块内，但解释答案的背景在块外”的难题。

3. 语义分块：利用句子嵌入的相似性来检测主题边界。相邻句子嵌入相似度高则属同一主题，相似度骤降则预示主题转换。这种方法计算成本更高，调优更复杂，但对于散文类语料库，它能产生最清晰的语义单元。

以结构感知的Markdown分块器为例，其核心是为每个块保留标题路径信息：

from dataclasses import dataclass
from typing import Iterator

@dataclass
class Chunk:
    text: str
    source: str
    section_path: list[str]
    start_line: int
    end_line: int

def chunk_markdown(
    text: str,
    source: str,
    max_tokens: int = 400,
) -> Iterator[Chunk]:
    """根据标题结构拆分Markdown。在同一节内，
    仅当节的字数超过max_tokens时才进一步拆分。在每个块中保留标题路径
    ，以便检索时具有结构上下文。"""
    # ... 实现细节（如扫描行，识别#标题，维护缓冲区和路径）

注意，每个数据块都携带了“章节路径”。当系统检索到关于“供应商入驻政策”的块时，它能知道这个块来自[“供应商管理”， “入驻流程”， “审批环节”]。这种结构化元数据对后续的重排序和答案生成至关重要。

元数据必须前置设计，每个块都应包含：源文档标识（稳定不变）、章节或结构路径、源版本的时间戳、内容类型（文本、表格、代码等），如果是多租户系统，还需包含访问控制标签。事后补充元数据的想法，往往意味着永远无法补充。

四、嵌入：一个更难撤销的选择

更换嵌入模型意味着需要重新嵌入语料库中的每一个块。对于百万级的中等规模语料库，这需要数小时的计算和不菲的成本。因此，初始选型必须慎重。

评估嵌入模型有三个关键维度：

1. 维度：常见的有384、768、1536等。维度越高，表征能力通常越强，但存储开销和近似最近邻（ANN）查询时间也相应增加。简单算一下：1000万个1536维的float32向量，仅原始数据就需约61GB。

2. 领域适配度：公开基准（如MTEB）反映的是通用表现，不能代表模型在你的特定语料库（法律、代码、临床笔记、营销文案）上的效果。唯一可靠的方法是进行实际测试。

3. 稳定性：嵌入服务提供商会更新模型。托管API有时会静默更改默认版本。如果一次更新导致你的检索质量下降，系统就可能被破坏。因此，需要考虑版本锁定或自行托管。

一个有效的工作流是：整理100-300个已知正确答案的查询/段落对作为“黄金数据集”；用2-3个候选模型分别对你的语料库进行嵌入；在黄金集上测量召回率（如Recall@10）；选择优势明显且成本合理的模型。并保留这个黄金集，用于未来任何模型变更前的回归测试。

跳过这一步，直接选用供应商的默认推荐，是检索质量平庸的常见原因。

五、向量存储：pgvector 与专用系统

这里有一个可能反直觉的观点：对于大多数企业级RAG系统，pgvector是正确的选择，而盲目选择专用向量数据库往往是过早优化。

pgvector 带来以下好处：

统一的运维界面（PostgreSQL），团队通常已掌握其备份、监控和复制。向量、元数据和块文本之间具备事务一致性，避免了“向量已更新但元数据未同步”这类错误。强大的SQL过滤能力与向量搜索相结合，其重要性远超许多团队的想象。一切都是标准工具和协议，降低了复杂度。

那么，何时才需要考虑专用向量数据库？当你的语料库向量数达到约5000万至1亿，且延迟要求低于20毫秒时；当需要高度选择性的预过滤，而pgvector的HNSW实现所采用的后过滤方法会严重损害召回率时；或者需要存储层严格隔离的多租户场景。

“pgvector太慢”的抱怨，通常源于没有建立索引、索引参数错误或实例配置过低。一个经过适当调优的HNSW索引，pgvector可以轻松应对数千万向量。

一个合理的初始表结构设计如下：

CREATE TABLE chunks (
    id bigserial PRIMARY KEY,
    source_id text NOT NULL,
    section_path text[] NOT NULL,
    content text NOT NULL,
    content_tsv tsvector GENERATED ALWAYS AS
                    (to_tsvector('english', content)) STORED,
    embedding vector(768) NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now(),
    metadata jsonb NOT NULL DEFAULT '{}'::jsonb
);

CREATE INDEX chunks_embedding_hnsw_idx
    ON chunks
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);
CREATE INDEX chunks_content_tsv_idx ON chunks USING gin (content_tsv);
CREATE INDEX chunks_metadata_gin_idx ON chunks USING gin (metadata);
CREATE INDEX chunks_source_idx ON chunks (source_id);

这里有几个设计要点：表中包含一个由内容生成的tsvector列，用于全文（稀疏）检索。因为你需要同时支持密集和稀疏检索，而在同一存储中完成可以避免复杂的连接操作。HNSW索引的参数m=16, ef_construction=64是合理的起点，查询时的ef_search参数可用于在召回率和延迟之间进行权衡。

除非你确凿无疑地遇到了pgvector的瓶颈，否则，管理一个数据库总比管理两个简单。

六、混合检索：最大的质量优势

要显著提升RAG系统质量，最有效的方法之一就是在默认的密集检索之外，加入稀疏检索，形成混合检索。

密集向量检索擅长捕捉语义相似性。当查询和文档用不同词汇表达相同概念时（如“汽车”和“车辆”），它表现出色。但对于需要精确匹配的信号——如产品代码、法律条款引用、嵌入模型未训练过的专有名词、罕见技术术语或票据号——它很容易失效。

BM25等稀疏检索算法则恰恰相反。它基于精确的词元匹配进行加权，擅长处理字面匹配，但无法应对同义替换和语义变化。

同时运行两者并将结果融合，可以取长补短。最简单有效的融合方法是互惠秩融合（RRF）：

def reciprocal_rank_fusion(
    rankings: list[list[str]],
    k: int = 60,
) -> list[tuple[str, float]]:
    """
    将多个排名列表合并为一个排名。`rankings`是一个排名ID列表的列表，每个检索器对应一个列表。
    返回按合并分数排序的(id, score)对。
    """
    scores: dict[str, float] = {}
    for ranking_ids in rankings:
        for rank, doc_id in enumerate(ranking_ids):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

例如，从密集和稀疏检索器各取前50个结果，用RRF融合，再取融合后的前20-30个结果送入下一阶段。这个约50行代码的策略，可以消除一整类检索失败。

在SQL层面，针对上述表结构的混合检索查询类似这样：

WITH dense AS (
    SELECT id, 1 - (embedding <=> :query_vec) AS score
    FROM chunks
    WHERE metadata @> :access_filter
    ORDER BY embedding <=> :query_vec
    LIMIT 50
),
sparse AS (
    SELECT id,
           ts_rank_cd(content_tsv, plainto_tsquery('english', :q)) AS score
    FROM chunks
    WHERE content_tsv @@ plainto_tsquery('english', :q)
      AND metadata @> :access_filter
    ORDER BY score DESC
    LIMIT 50
)
SELECT id, score, 'dense' AS retriever FROM dense
UNION ALL
SELECT id, score, 'sparse' AS retriever FROM sparse;

在应用层执行RRF融合更为灵活，便于未来引入基于元数据、图谱关系等更多检索器。

七、重新排序：将前50名召回率转化为前5名精确率

检索的目标是召回——把正确答案塞进前50个候选。而生成则需要精确——把最相关的答案排进前3到5名，因为这是上下文窗口能容纳的极限。

交叉编码器（Cross-Encoder）正是用来填补这个鸿沟的。与分别编码查询和段落的双编码器不同，交叉编码器将两者联合编码，直接输出一个相关性分数。这种联合建模能捕捉到双编码器忽略的细微交互：否定词、特定实体匹配、措辞的微妙差异等。当然，它的计算代价也高得多，无法用于百万级语料库，但处理经过混合检索筛选出的50个候选则绰绰有余。

标准模式是：通过混合检索得到Top 50候选；用交叉编码器对这50个（查询，段落）对进行评分；按新分数重排序；取Top 5-10送入生成环节。

除了引入混合检索外，添加交叉编码器重排序器带来的质量提升，通常是所有单一改动中最大的。而且，由于它只对少量候选进行一次额外的模型调用，集成成本相对较低。

八、知识图谱：检索与意义的交汇点

前述方法都将文档视为具有语义相似性的文本块的集合。这对于许多问题足够了，但当问题依赖于实体间的关系而非文本间的相似性时，这种方法就会失效。

例如：“哪些供应商合同引用了第3.4.2条规定，并且将在未来90天内到期？”

任何混合检索都难以直接回答。这里的关系——“合同引用法规”、“合同有到期日”——是结构化的，最适合用图来表征。

在生产中，知识图谱与RAG的集成主要有三种模式：

1. 实体范围检索：从查询中提取实体，在知识图中查找它们，扩展到直接关联的实体，然后将向量搜索的范围限定在提及这些实体的文本块内。当查询涉及具体命名实体时，此法能极大提升精度。

2. 基于图的重排序：先进行混合检索，然后利用知识图提升那些在图中与查询实体有更短路径的文本块的排名。连接了查询中多个实体的块，显然比只提及其中一个的更相关。

3. 路径遍历式回答：对于纯粹的关系型问题（如“谁向谁汇报”、“A依赖于什么”），图查询成为主检索方式，文本块则作为证据。运行图查询语言（如Cypher）找到匹配的实体和关系，提取记录这些关系的文本块，将图和文本证据一并交给生成模型。

一个最小化的集成方案是，在数据摄取时，从文本块中提取实体后，同时写入向量数据库和图数据库：

# 写入Postgres (向量存储)
cur.execute(
    """
    INSERT INTO chunks
        (id, source_id, section_path, content, embedding, metadata)
    VALUES (%s, %s, %s, %s, %s, %s)
    """,
    (chunk_id, source_id, section_path, text, embedding, meta_json),
)

# 写入Neo4j (图数据库)
session.run(
    """
    UNWIND $entities AS ent
    MERGE (e:Entity {id: ent.id})
      ON CREATE SET e.canonical_name = ent.name, e.type = ent.type
    MERGE (c:Chunk {id: $chunk_id})
    MERGE (e)-[:MENTIONED_IN {salience: ent.salience}]->(c)
    """,
    chunk_id=chunk_id,
    entities=entities,
)

查询时，实体范围检索的逻辑大致如下：

def entity_scoped_retrieve(query_text: str, top_k: int = 30) -> list[str]:
    entities = extract_entities(query_text)
    if not entities:
        return hybrid_retrieve(query_text, top_k) # 降级到普通混合检索

    entity_ids = [e.id for e in entities]
    related_chunk_ids = neo4j_session.run(
        """
        MATCH (e:Entity)-[:MENTIONED_IN]->(c:Chunk)
        WHERE e.id IN $entity_ids
        RETURN DISTINCT c.id AS chunk_id
        """,
        entity_ids=entity_ids,
    ).value()

    if not related_chunk_ids:
        return hybrid_retrieve(query_text, top_k) # 降级
    return hybrid_retrieve(query_text, top_k, candidate_ids=related_chunk_ids)

备用降级方案至关重要。如果实体提取失败或图中没有匹配实体，系统应能无缝降级到普通混合检索，而不是返回空结果。

知识图谱由此成为检索系统的“骨架”。它并非锦上添花，而是从根本上改变了系统能够理解和检索的信息维度。