不想受制于现成SaaS平台？从零开发AI知识库必须掌握的API调用与召回全链路

很多人刚做 AI 知识库时，第一反应是直接用现成的 SaaS 平台。点几下鼠标，传几份 PDF，一个问答界面就出来了。前两天看起来很方便，但只要业务跑上正轨，问题就会接踵而至。

最常见的情况有两类：一是数据合规与私有化要求，公司的内部技术文档、财务凭证根本不能往公网第三方平台上传；二是检索效果黑盒，当用户搜一个特定的零件型号或者错误代码时，平台给出的回答错得离谱，你想调优却发现后台只给你留了一个简单的“相似度阈值”滑块，根本没办法深入底层调整切分和召回逻辑。

其实自己写一套全链路的检索增强生成（RAG）知识库，核心骨架并不复杂。只要理顺数据切分、混合召回、重排以及大模型生成的调用流程，你就能完全掌控每一个环节的数据流向和成本。

第一步：文本切分与清洗

很多检索失败，根源不在大模型，而是在文本切分阶段就把信息切碎了。

如果你直接按固定字数暴力切片（比如每 500 字硬切一刀），常常会把表格的一行或者一段完整的逻辑切成两半。这样存进数据库后，模型检索到前半段缺少结论，检索到后半段缺少主语。

具体操作步骤：

1.先根据文档结构（Markdown 标题、换行符、HTML 标签）切分成语义完整的段落。

2.将单个切片（Chunk）的大小控制在 400 到 600 个 Token 之间。

3.给相邻切片设置 10% 到 15% 的重叠区间（Overlap），大约 50 到 80 个 Token。这一步能保证上下文在交界处不丢失语义。

4.在切片文本的头部拼上元数据，例如“文档标题 – 章节路径”。

避坑提示： 包含数字、配置项的代码块和表格，必须保持结构完整，切忌切开。如果文本里包含大量表格，转成 Markdown 表格或者纯 JSON 字符串后再存储，检索匹配度会更高。

第二步：Embedding 向量化与向量存储选型

切片完成后，需要调用 Embedding API 将文本转成稠密向量（Dense Vector），存入支持向量检索的数据库。

目前市面上的主流 Embedding 模型很多，选择时主要看三个指标：向量维度、最大输入长度和调用单价。维度越高，表达的语义细节通常越丰富，但占用的存储空间和计算开销也成倍增加。

以下是目前主流 Embedding 方案的实测对比：

在数据库选型上，如果你的数据量在 100 万条切片以内，不需要一开始就买专用的分布式向量数据库。在现有的 PostgreSQL 上安装 pgvector 插件是最稳妥的做法。这样做不仅运维简单，还能让业务数据与向量数据放在同一张表里做事务处理。

当切片数量超过 500 万条，或者并发查询要求高于每秒数百次时，再迁移到 Qdrant 或 Milvus 这类专用引擎。

第三步：为什么不能只靠向量？必须做“混合检索”

很多人自建知识库后，会遇到一个非常典型的 Bug：

用户搜索一个精确的工单号 `TICKET-88902`，或者特定的报错码 `ERR_AUTH_TIMEOUT`，纯向量检索经常找不到正确文档，反而召回了一堆包含“认证超时怎么办”的普通文档。

原因很简单：向量检索擅长模糊语义匹配，但不擅长精确字符匹配。 向量模型会将罕见编号当作低频词稀释掉。

为了解决这个问题，召回链路必须采用 混合检索（Hybrid Search）：

1.稠密检索（Dense Retrieval）：使用向量比对（余弦相似度），负责召回语义相近的内容。

2.稀疏检索（Sparse Retrieval / BM25）：使用传统的关键词分词匹配，负责捕获精确的产品型号、专有名词和错误代码。

混合召回的执行步骤：

•当用户发起查询时，后端并行发起两路请求：一路调用向量数据库执行最近邻搜索（ANN），另一路在全文索引执行 BM25 检索。

•两路各取出前 50 到 100 条候选结果。

•使用 RRF 算法（Reciprocal Rank Fusion，倒排排名融合） 将两份候选列表合并。

RRF 的计算规则非常简单直接：

$$RRF_Score(d) = sum_{m in M} frac{1}{k + r_m(d)}$$

其中常数 $k$ 通常设置为 60，$r_m(d)$ 是文档 $d$ 在检索方式 $m$ 中的排名位置。这种算法不依赖两种检索各自的分数绝对值，只根据排名进行权重折算，彻底避免了向量相似度（0 到 1 之间）与 BM25 分数（可能大于 20）无法直接相加的问题。

第四步：引入 Rerank 模型，把召回精度推到及格线以上

混合检索出来的候选文档虽然全，但噪音依然很大。排名前 100 的切片里，可能混入了大量只包含个别关键词但整体毫不相干的废话。大模型的上下文窗口就算装得下 100 个切片，输入过多无关信息也会引发注意力丢失，产生幻觉。

必须加入精排阶段（Rerank）。

Embedding 属于双塔模型（Bi-Encoder），查询词和文档是分开计算向量的，计算速度快，但两者缺乏深度的字词交叉交互。

Rerank 属于单塔交叉模型（Cross-Encoder），它把用户的查询词和候选切片拼在一起同时输入模型，计算两者之间的真正匹配度。它的计算速度比向量慢，但判断精度远高于向量相似度。

实测数据显示，在二阶段检索中加入优秀的 Rerank 模型后，知识库前 5 项结果的命中准确率能直接从 70% 优化到 95% 以上。

以下是三种常见 Rerank 服务的选型对比：

成本控制的经验公式：

•如果每次送入 Rerank 的候选文本总量（Candidate Chunks × Chunk Token 数量）大于 40,000 Tokens，选 Cohere API（按次计费）更划算。

•如果候选集总量小于 40,000 Tokens（例如 top-k=30，每个 chunk 500 Token，总计 15,000 Token），选 Voyage AI（按 Token 计费）更便宜。

设置严格的过滤截断分数：

拿到 Rerank 计算出的匹配分数后，不要机械地把 top-5 塞给大模型。建议设置一个绝对过滤阈值，例如 Score < 0.35 的候选切片直接丢弃。如果所有切片的分数都低于阈值，系统应当直接回复“在现有知识库中未找到相关事实”，而不是强行回答。

第五步：组装 Prompt 与大模型生成

在经过混合检索过滤和 Rerank 精排后，你手里应该只剩下 3 到 5 个高度相关的核心文本切片。

组装 Prompt 时，必须给大模型建立严格的边界。真实业务中常用的结构如下：

你是一个严谨的企业知识库助理。请严格基于以下给出的参考资料回答用户的问题。
如果你无法从参考资料中得出答案，请直接说明“现有资料中没有记载此内容”，严禁编造任何信息。

【参考资料】
---
[文档 1] 标题：服务器部署指南
切片内容：生产环境服务器集群必须开启双因子认证（2FA），端口默认调整为 2222。
---
[文档 2] 标题：网络安全红线规范
切片内容：任何人不得在公网暴露未经鉴权的 Redis 服务，发现后直接触发一级安全告警。
---

【用户问题】
生产环境服务器必须开启什么认证？端口是多少？

通过这种链路处理，送入大模型的数据量通常不会超过 2000 个 Token。这不仅让每次 API 调用的耗时大幅缩短，更将调用成本降低到了原有暴力全量拼接方案的十分之一。

全链路流程回顾与落地清单

梳理出这套逻辑后，你就能清晰地发现，自建知识库的每一个环节都可以监控并优化：

1.文档摄入：PDF/Docx 解析 -> 去除多余排版字符 -> 按 500 Token 配合 15% 重叠做语义分块。

2.双路写入：切片写入 PostgreSQL 的 `tsvector` 全文索引字段；同时调用 Embedding API 生成向量，写入 `pgvector` 向量字段。

3.混合召回：接收查询 -> 同时跑 BM25 检索与向量 ANN 检索 -> 各取 top-50 -> 用 RRF 公式融合为 100 条候选列表。

4.精确重排：将 100 条候选送入 Rerank API -> 获取相关性分数 -> 截断评分低于 0.35 的切片 -> 只取最终得分最高的前 5 条。

5.Prompt 拼装：结构化包裹前 5 条切片 -> 发送给生成模型 -> 输出准确且具备事实来源的答案。

把整个召回链路拆解为可控的代码块，你不必依赖任何封装过度的第三方框架，更不用给封装了基础 API 的中间商 SaaS 平台交溢价。底层的数据、召回的权重和核心的隐私，全部稳稳掌握在自己的代码里。