AI 知识库底层数据库选错,后期全是坑:7 条技术路线的难度、成本与选型真相

企业做内部 AI 知识库，资料往往已经存放在业务数据库或文档系统里。为了让模型回答制度、手册和工单问题，团队会切分文档、生成向量，再建立检索索引。到了选型环节，问题就来了：沿用现有数据库增加检索能力，还是单独引入向量数据库？这不只是一次查询能否跑得更快，还关系到谁负责权限、文档更新多久生效，以及新增一套系统后谁来维护。

假设一家企业把制度文档做成内部问答。原文和权限保存在 PostgreSQL，演示版另建了向量库。问答看起来能跑，但制度撤权后，旧片段可能还留在索引里；采购报价只算了数据库，没算同步、模型和运维。此时先给产品排性能名次，解决不了真正的风险。已有可靠数据库、负载可控时，先验证原系统能否满足检索要求；确有独立扩缩容、过滤或托管需求时，再评估专用服务。

这篇文章要回答的是：PostgreSQL + pgvector、Elasticsearch、Qdrant、Milvus、Weaviate、Pinecone 和 Chroma 各适合什么条件，落地难在哪里，成本应该怎么算。我们用同一个企业知识库场景比较七条主检索路线，再给出可实际执行的测试方法。Redis 语义缓存和 Neo4j 图谱会作为配套组件讨论，不与主检索库硬排高低；云平台原生检索等其他方案也值得根据现有技术栈纳入候选。

先定场景：七个产品必须解同一道题

设想企业有 100 万条制度片段，embedding 为 768 维；100 个租户共用服务，部门权限与文档版本会变更。日常问题既有“报销规则是什么”这样的语义表达，也有“制度第 7.2 条”这样的精确编号。要求每次只引用当前用户有权看的生效版本，失败可恢复，查询高峰时尾延迟可控。这里的数量是统一比较的样例输入，不是“100 万条以上就必须换库”的阈值。

一条入库记录至少要能定位 tenant_id / doc_id / version / chunk_id，并带权限、状态、原文位置、embedding 模型版本。一次问答的最短可靠链路是：

服务端验身份与权限版本  → 只在授权且生效的范围内做关键词/向量召回  → 必要时融合、重排  → 再核引用和版本，把有来源的片段交给模型  → 留下候选 ID、版本、耗时与费用的审计记录

原文及权限的权威记录要有明确的事实主源。如果另建独立检索库，其中的数据是可重建的召回副本；如果在事实主源上直接建立检索索引，则没有跨系统副本，但仍须处理索引更新。大模型负责生成答案，不能充当权限系统。把独立检索库中的副本误当事实主源，撤权与删除就可能漏同步；提示词再长也无法替代服务端授权。系统是否真的守住这条边界，必须用无权限用户、旧版本文档和删除文档做反例测试。

真正让路线分开的，是三道技术关

第一道是精确词与语义的组合。Embedding 能把“差旅能坐高铁吗”和“出差交通标准”拉近，却不保证“7.2 条”与“7.3 条”被严格区分。Elasticsearch 的 RRF分别取得标准检索与 kNN 的候选再融合；Weaviate 的 hybrid 查询也组合 BM25F 与向量结果，权重受 alpha 和客户端行为影响。若大量问题是代码、编号、SKU、条款，关键词通道应先作为基线，而不是一上来只比较向量 Recall。

第二道是过滤与近似搜索的相互作用。pgvector 的索引行为说明提到，近似索引查询的过滤可能在扫描后发生：即使写了 LIMIT 10，也可能拿不到十条授权结果；支持 iterative scan 的部署可以继续扫描，但仍有上限。Qdrant 的payload 索引会影响过滤感知的 HNSW 图，建索引顺序也重要。Milvus 则有先做标量过滤和迭代判断候选两条路径。三者机制不同，不能因为都写了 tenant_id 条件，就推断高选择性 ACL 下的延迟与召回一样。

第三道是数据副本与责任边界。把文档复制到独立索引后，新增、修订、撤权、删除、模型升级都变成同步事件。若主源已在 PostgreSQL，pgvector 的价值是少一个跨系统副本；若已有成熟搜索平台，Elasticsearch 可能复用全文与运维能力；若向量负载须独立扩缩容，专用服务才更有意义。省下一个组件，未必省下 CPU；引入一个托管组件，也没有外包业务数据正确性。

七条主检索路线怎么放在同一张桌上

“上手难度”指熟悉 SQL 和常见云服务的团队，从样例数据做到可查询；“生产难度”再算上权限、备份、故障、监控与升级。低、中、高是相对判断：团队原本就有 PostgreSQL 或 Elasticsearch 经验，结论自然会不同。

“难度低”不等于“长期最便宜”。已有 PG/ES 团队的边际成本，与没有数据库值班能力的小团队不同；Pinecone 的托管优势，和必须本地部署的约束可能直接冲突；Milvus 的扩展能力，只有在数据与负载确实需要时才有价值。Chroma 也不是只能做玩具，但本地 demo 不能自动证明生产治理已经齐备。这些都是附条件的选型判断，不是跨产品跑分结论。

成本：先算容量下界，再看账单单位

100 万条 × 768 维 × float32 的原始向量是 1,000,000 × 768 × 4 = 3,072,000,000 字节，约 3.07 GB 或 2.86 GiB。它没有计正文、元数据、HNSW/其他索引、写入日志、副本、备份与缓存；迁移 embedding 模型时，新旧版本并存还可能暂时增加占用。不能拿 2.86 GiB 直接去报“生产只需一台 4 GB 机器”。

月度完整成本可以拆成两本账：

数据库账 = 常驻/弹性计算 + 内存与索引 + 主数据/副本/备份         + 读写/出网/支持档位 + 运维与恢复演练AI 应用账 = 文档解析 + embedding 重建 + rerank + 生成 token         + 权限/同步开发 + 评测与人工校验

以下公开美元标价只能当计费单位示例，实际采购还受地域、税费、合同和折扣影响。不能把不同栏位排成“每月从低到高”：

一个可复算、但不代表生产报价的小算术：假设 Chroma Cloud 在某月只写入 10 逻辑 GiB，且这 10 GiB 整月驻留，则列示写入费 10 × $2.50 = $25，存储费 10 × $0.33 = $3.30，合计 $28.30；读取、过滤谓词、网络、解析、模型、其他费项尚未计入。Chroma 的逻辑写入与存储规则支持此演示。它只能帮助检查公式，不能拿来宣布 Chroma 比 Zilliz、Pinecone 或自建更便宜：另一家按 vCU、实例或最低消费计，连问题都不同。

评估时向每个候选索取同一份成本输入：向量条数与维度、原文/元数据大小、每月新增和重嵌入比例、平均与峰值查询、返回字段、副本与备份、地域、SLA 和失败重试。再记录“每 1000 次授权且引用正确的回答花了多少”，而不只看每次向量查询单价。若某方案便宜但旧版误引多、授权范围错或尾延迟不达标，它不是合格的便宜方案。

怎么测试，才能真正做出选择

分别跑通七个产品的查询 API，只能证明它们都能查询，不能证明谁更适合这家企业。决定选型的，是同一套数据和约束下的比较：

1. 固定输入。
    使用同一语料、切块、768 维模型、距离定义、租户/ACL、当前生效版本，并统一取前十条结果。划出编号题、自然语言改写题、跨租户高相似题、旧版/删除题、空结果题。人工标注每题可引用的授权片段 ID。
2. 先验正确，再看速度。
    比较关键词-only、向量-only、混合检索。对标注了至少一个有权相关片段的题目，逐题算 Recall@10＝前十命中的有权相关片段数÷该题标注的有权相关片段总数，再对这类题求平均；空结果题单独统计误返回率和拒答是否正确。在非空结果题中，另外统计至少一个正确片段进入前十的题目比例，并记录旧版误引率和权限违规数；不能把“命中至少一条”的比例混称为 Recall@10。任何未授权片段进入模型上下文都是硬失败，不用平均分抵消。
3. 用相同约束压尾部。
    在事先确定的并发、更新率、过滤选择性和可用性条件下，记录 P50/P95/P99、返回量、CPU/内存/磁盘、写入到可检索的时滞。没有明确 SLA 时先由业务决定上限，而不是照抄别人的“200 ms”。
4. 测试变更和恢复。
    修订一个文档、撤销一位员工权限、删除一个租户，再验证搜索结果和生成引用；在隔离环境做节点失效与备份恢复。记录从业务变更提交到所有检索路径不再返回失效或无权数据的时间，不把“API 返回成功”当传播完成。
5. 以完整月估价。
    用试运行产生的资源和单位消耗，外推工作日、峰值、备份、双版本回填与失败重试；价格同时请供应商确认适用区域与合同。报告每个方案的质量、尾延迟、恢复目标和总成本，而不是只列 QPS。

一次测试不能证明长期稳定，也没有哪一个 Recall@10 数字适用于所有公司。最终应能说清五件事：授权是否正确、能否找到可引用的新版本、时延是否达标、变更能否及时传播、总成本能否接受。

最后才做条件化选择

如果文档和权限主数据已经稳稳落在 PostgreSQL，先拿 pgvector 的精确检索与 ANN做基线，观察是否影响事务负载；不达标再分离检索。若编号、中文全文与语义都重要、且已有 ES 经验，试 Elasticsearch 的双路召回，同时核订阅能力。若难点是大量租户在小授权集合内找足够结果，重点比较 Qdrant 的 payload 索引和其他候选在相同 ACL 下的表现。向量规模、持续写入与资源分层已成为真问题时，再评估 Milvus；想统一模型接入与混合查询时看 Weaviate；团队不能运维检索集群且地域/合同允许时看 Pinecone；需求还停在切块和问题集验证阶段，先用 Chroma，别把 demo 直接改名为生产。

Redis 的语义缓存可以减少重复生成，但只在租户、版本与权限边界严格一致时复用答案；Neo4j 的 GraphRAG可以解释多跳关系，但先要付出可信关系构建与治理成本。二者是对主检索链的补强，不是因为也能处理向量就必须替代主库。

回到开头的制度问答：如果撤权后旧片段仍能进入模型，先修数据与授权链路，再讨论向量性能；如果这些门槛已过，再用同一负载与同一账本选择让团队长期承担得起的路线。数据库与 AI 的契合度，不是功能表里有没有“vector”，而是给模型的证据是否正确、及时、可授权、可恢复，且费用能被解释。