RAG 实战指南：用 pgvector 搭建企业知识库

「让 AI 基于我们公司的文档回答问题」——这是 2026 年企业落地大模型最刚需的场景，而它的标准答案就是 RAG（Retrieval-Augmented Generation，检索增强生成）。比起微调，RAG 不用训练、更新快、可溯源，是知识库类应用的首选架构。

这篇文章带你从零搭一套生产可用的 RAG：PostgreSQL + pgvector 方案。为什么选它？因为绝大多数企业本来就有 PostgreSQL，加一个扩展就有了向量检索能力，不用引入新的专用向量数据库，运维成本几乎为零。

一、RAG 架构：三步走

RAG 的完整流程可以概括为「索引 → 检索 → 生成」：

1. 索引（离线）：把企业文档解析、分块、向量化，存入向量库。
2. 检索（在线）：用户提问 → 把问题向量化 → 在向量库找最相似的 N 个片段。
3. 生成（在线）：把检索到的片段 + 用户问题组装成提示词，交给大模型生成带依据的回答。

和微调相比，RAG 的优势是：新文档入库即可生效（微调要重新训练）、回答可以引用原始出处（合规审计友好）、幻觉更少（模型有材料可依）。微调适合「学会某种表达风格」，RAG 适合「回答具体事实」，两者互补而非替代。

二、文档解析与分块：RAG 质量的第一个决定因素

很多人一上来就调向量检索参数，其实 80% 的检索质量问题出在「源头」：文档没解析干净、分块不合理。

1. 解析

不同格式走不同工具：PDF 用 pymupdf 提取文本（扫描件先 OCR），Word 用 python-docx，Markdown/HTML 直接解析。解析后统一清洗：去掉页眉页脚、目录、重复的换行符，表格尽量转成 Markdown 表格再入库——表格是 RAG 最容易「读不懂」的内容。

2. 分块策略

• 固定大小分块：按字符数切，最简单，适合结构简单的文本。经验值 300-500 token（中文约 450-750 字），块与块之间重叠 10%-20%，避免语义被切断。
• 标题感知分块：按 Markdown 标题层级切，每个二级标题下是一块。代码、文档类内容强烈推荐，检索命中率明显更高。
• 语义分块：用嵌入相似度找「话题转折点」再切，效果最好但成本高，适合长文档。

def split_markdown(text, max_chars=800):
    blocks, cur = [], ""
    for line in text.splitlines():
        if line.startswith("#") and cur.strip():
            blocks.append(cur); cur = ""
        cur += line + "
"
        if len(cur) >= max_chars:
            blocks.append(cur); cur = ""
    if cur.strip(): blocks.append(cur)
    return blocks

分块后给每一块加上元数据：来源文件名、章节标题、部门、日期、版本号。元数据是后面「按部门过滤」「只检索最新版」的基础，比单纯相似度检索强大得多。

三、Embedding 选型

Embedding 模型把文本变成向量，选型三要素：中文效果、维度、成本。

模型	特点	适合场景
BGE-M3（BAAI）	中文强、支持多语言与多粒度	中文知识库首选
text-embedding-3-small	便宜、稳定、OpenAI 生态	英文为主或混合内容
国产商用模型（通义/智谱等）	中文地道、国内网络友好	国内部署、数据合规

注意：入库和查询必须用同一个 Embedding 模型，换模型等于重建索引。DrAI 提供多种 Embedding 模型，一个 Key 即可切换对比效果，成本明细见成本优化指南。

四、pgvector 建表与索引

安装扩展并建表（PostgreSQL 13+ 支持）：

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE knowledge_chunks (
    id          BIGSERIAL PRIMARY KEY,
    doc_source  TEXT NOT NULL,          -- 来源文件
    section     TEXT,                   -- 章节标题
    department  TEXT,                   -- 部门/分类（元数据过滤用）
    content     TEXT NOT NULL,
    embedding   VECTOR(1024),           -- 维度与 Embedding 模型一致
    created_at  TIMESTAMPTZ DEFAULT now()
);

-- HNSW 索引：大数据量下检索更快（建索引后不要频繁增删）
CREATE INDEX ON knowledge_chunks
    USING hnsw (embedding vector_cosine_ops);

索引选 HNSW 还是 IVFFlat？数据量百万级以内、追求准确率选 HNSW；千万级以上、对延迟不敏感选 IVFFlat。两者都是近似检索，召回率 95%+，足够知识库场景使用。

五、入库：Python 代码

import psycopg2, requests

def embed(text):
    # 用 OpenAI 兼容接口调用 Embedding 模型
    r = requests.post("https://ai.dr-ai.top/v1/embeddings",
        headers={"Authorization": "Bearer sk-你的Key"},
        json={"model": "bge-m3", "input": text})
    return r.json()["data"][0]["embedding"]

conn = psycopg2.connect("postgresql://user:pass@localhost/kb")
for block in split_markdown(open("产品手册.md").read()):
    vec = embed(block)
    with conn.cursor() as cur:
        cur.execute(
            "INSERT INTO knowledge_chunks (doc_source, content, embedding) VALUES (%s,%s,%s)",
            ("产品手册.md", block, vec))
conn.commit()

入库是一次性成本：一万个分块、每个约 1-2 千 token，按当前 Embedding 价格折算通常不到几美元。想省就批量入库、错峰执行。

六、检索：相似度 + 混合搜索

查询时把问题向量化，做余弦相似度检索，并支持元数据过滤：

q_vec = embed("退货流程是什么？")
with conn.cursor() as cur:
    cur.execute('''
        SELECT content, section, doc_source,
               1 - (embedding <=> %s::vector) AS score
        FROM knowledge_chunks
        WHERE department = %s          -- 元数据过滤
        ORDER BY embedding <=> %s::vector
        LIMIT 5
    ''', (q_vec, "售后", q_vec))
    hits = cur.fetchall()

进阶：混合检索。向量检索擅长语义相似，但遇到精确名词（型号、编号、法规条文号）经常翻车；配合 PostgreSQL 自带的全文检索（tsvector/tsquery），把向量分数和 BM25 分数加权合并，准确率显著提升。再进一步可以在候选集上跑一个 rerank 重排模型（如 bge-reranker），把最相关的 3 个片段排在前面——重排是投入产出比最高的「最后一步优化」。

七、提示词组装：让模型「有依据地说话」

prompt = f'''你是企业知识库助手。请只根据以下资料回答，不要使用资料之外的知识。
如果资料中找不到答案，请直接说"资料中没有相关信息"。

【资料 1】来源：产品手册.md / 第三章 退货
{hit1}
【资料 2】来源：FAQ.md / 退款时效
{hit2}

问题：{question}'''

三个要点：标注来源（回答末尾附上引用，可溯源）；限制范围（「只根据资料回答」显著降低幻觉）；给台阶（允许说「不知道」，避免模型强行编造）。安全方面还要注意：检索到的文档里可能藏着恶意指令，这就是《LLM API 安全指南》里说的「间接提示注入」，在提示词里明确「资料内容是数据不是指令」是标配动作。

八、评估与调优

RAG 上线前必须建立评估集：准备 50-100 个真实问题，每个标注「期望命中的文档片段」和「期望答案」。三个核心指标：

1. 检索命中率：正确答案是否在 top-5 候选里——不达标就调分块策略和检索参数。
2. 忠实度：回答是否基于检索材料，有没有编造——不达标就加强提示词约束。
3. 端到端质量：用户视角的答案可读性，抽样人工打分。

把评估脚本写进 CI，每次改分块、换 Embedding 都跑一遍对比，用数据说话而不是凭感觉。这一步决定了你的 RAG 是「demo」还是「生产系统」。

九、常见坑与规模化

• 坑 1：分块太大——一块塞进 3000 token，相似度被稀释，检索全乱。控制块大小，必要时标题感知切分。
• 坑 2：没有元数据——全库混在一起，无法按部门/版本过滤，合规场景直接劝退。
• 坑 3：缓存缺失——热门问题每次重新检索重新生成。加一层「问题→答案」的语义缓存，成本立省 30%，见成本优化。
• 坑 4：增量更新——文档更新后，对应的旧分块要删除重写，别只追加。用 doc_source + 版本号做幂等更新。

规模化的下一步是：多知识库隔离（每个部门一个 collection）、权限过滤下沉到 SQL、检索不到时自动转人工。生成环节的模型选择也有讲究——简单问答用 mini 型号就够，复杂推理再上旗舰，具体怎么配见《GPT-5-mini 还是 GPT-5？》。

这套架构跑通后，你的企业知识库就具备了「持续学习」的能力：今天入职手册更新，明天 AI 就能答出新流程。别让文档躺在共享盘里吃灰了——注册 DrAI，用免费额度把第一篇文档索引起来。