产品知识库实测与选型

本文最后更新于 2026-09-13

基础与背景

RAG 是什么

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让大模型先参考外部资料，再生成回答的方法。 可以把它理解为：回答问题时，不只依靠模型训练中学到的知识，还把与当前问题相关的资料找出来，放到模型面前供它参考。

为什么需要这样做？大模型不一定见过一家公司的内部制度、某款产品的最新说明书，也未必知道一份文档刚刚修改了哪些内容。它能把话说得通顺，并不代表它已经掌握了回答这个问题所需的事实。

举个简单的例子：用户问“这款软件怎么导出文件”，系统先从对应版本的使用手册中找到导出步骤，再把问题和这些步骤交给模型，由模型组织成容易理解的回答。这就是一次典型的 RAG 问答。这里的重点不是让模型“更会说”，而是让它在回答时有资料可查。

这个过程可以拆成三个动作：

  • 检索：根据问题寻找相关资料。
  • 增强：把找到的资料连同问题放进模型本次能阅读的上下文。
  • 生成：模型依据这些资料组织回答，必要时提供来源。

RAG 不等于重新训练模型，也不保证回答必然正确。资料本身可能有错，检索可能漏掉关键段落，模型也可能误解证据。因此，一个能演示的 RAG 问答，与一个可靠的知识问答系统之间，还隔着资料管理、检索质量和回答验证等工作。

这篇文章想讨论的正是这段距离：先从知识库和几种知识获取方式讲起，再结合一个产品问答项目，记录如何设计测试、比较开源平台，以及为什么保留某个方案继续验证。

知识库是什么

RAG 要查的资料从哪里来？通常来自一套事先整理的知识库。这里的“知识库”，可以先理解为一组经过整理、有来源和适用范围、能够查询和更新的知识内容，例如公司制度、产品手册、常见问题与答案。

它不天然等于一个向量数据库，也不一定需要大模型。按主题和版本整理好的文档目录、可以查询的常见问题表，已经可以是知识库的一种起点；面向人工阅读的知识网站和面向程序调用的知识接口，则是不同的使用方式。

两者的区别是：知识库负责保存和组织知识，RAG 是利用这些知识辅助模型回答的一种方式。 有知识库不一定要做 RAG，做 RAG 也不意味着只能用向量查资料。

需要分开的其实是三个问题：

要决定什么 可以有哪些做法
知识怎样组织 保留文档和问答；整理成字段明确的表；建立实体与关系图谱
问题怎样找到知识 全文提供给模型；精确查询；关键词搜索；向量相似度搜索；沿关系查询
谁来管理与使用 人工查阅；业务系统维护；检索服务调用；模型结合证据回答

这些做法不是互斥的。一个系统可以把型号、版本放在表中精确过滤，把操作说明保留为文档，再用搜索找到相关段落。也可以从文档里整理出部件关系，单独支持关联查询。

所以，“选知识库”要先决定知识的组织与使用方式，然后才轮到选平台。后文会提到的 FastGPT、MaxKB 等开源项目，是帮助完成资料上传、解析、检索和问答等流程的平台，不是“知识库”这个概念本身。

我们的项目需求

有了这些概念，再来看这次实践。项目面向的是带有 AI 语音功能的产品：希望用户不必翻说明书，也能直接询问产品的使用方法、功能限制和常见问题。系统需要依据当前产品的资料回答，而不是只凭大模型的通用知识猜测。

已有材料主要是产品问答表和规格文档，单个产品约一万到三万字，并不是海量数据。我们要解决的是：怎样让问答系统使用这批资料，换一种口语问法还能不能找到答案，资料更新后怎样生效，以及多个产品的内容怎样避免混用。

例如，用户问“这个模式怎么开”，需要的是对应型号的操作说明；问“我的这个版本也支持吗”，需要先确认版本；问到资料没有覆盖的功能，系统应该承认没有依据。以上只是场景示意，不是原始测试题。

资料也不能一直靠开发者手动改代码维护。后续还希望由业务系统上传和更新，让不同角色管理资料，能够核对来源、审核状态和版本。因此，项目同时关心“知识怎样被使用”和“知识怎样被管理”。

RAG 是值得验证的一条路线，但还不能据此决定必须使用向量数据库或开源平台。对这样一批小规模资料，首先应该问：直接放进提示词是否够用？查表或关键词能不能解决？什么情况下才值得引入向量与知识图谱？下面先把这些选择说明白，再进入实测。

方案选择

提示词能不能解决

可以尝试，而且应该先分清“多写一些提示词”具体指什么。

多写行为要求

例如告诉模型：“你是产品助手，回答要简洁，不知道就说不知道。”这能表达角色和回答要求，却没有告诉它这款产品新增了什么功能、哪些型号不支持某种操作。

行为指令和产品事实不是同一件事。如果模型没有获得相应资料，只把要求写得更详细，并不能补上那些缺失的产品事实。 即使给了资料，也仍要验证模型是否忠实使用，不能把一句“禁止编造”当成正确性保证。

把资料一起放进去

如果“加提示词”指把适用的说明书和 FAQ 一起放进上下文，那就是一条完整、合理的候选路线：先按产品和权限确定资料范围，再把全文交给模型，尽量不做片段检索。

对于只有一两万到三万字、更新不频繁、产品范围明确的资料，这条路线值得作为基线。它的好处是少了一层检索系统，也没有“检索没有捞到那个关键段落”的问题。

但它仍有自己的验收项：资料加上历史对话能否放进所选模型的上下文，输入成本与首句延迟是否可接受，模型能否正确处理长文里的细节、否定和冲突，以及每次是否只提供了允许使用的版本。上下文缓存可能改变成本与延迟，也要按实际模型和服务配置测量，不能一概认为全文方案一定慢。

本轮尚未完成全文上下文方案与后文平台方案的同口径对照，所以不能声称实验已经证明 RAG 比长提示词更好。 本文记录的是其中检索与平台路线的推进过程，这个对照仍是后续需要补上的证据。

一定要用向量吗

不一定。如果不把全文都交给模型，就需要根据问题选出资料，但“选出资料”并不只有向量搜索一种办法。

能精确查询的先精确查询

型号、版本、功能开关、故障码映射等信息，如果已经能整理成明确字段，就可以先用结构化表或规则查询。例如“型号 A 的版本 B 是否支持功能 C”，核心是字段条件是否满足，而不是找一段语义上很像的话。

这类事实也不一定需要模型自由生成答案。查到可信记录后，可以直接按模板回答，或者让模型只负责语言组织。若缺了必要条件，应先澄清，而不是用相似度猜一个型号。

关键词与向量各补什么

对于操作说明和口语问答，问题开始变得不那么规整。同一件事，文档可能写“恢复出厂设置”，用户却说“怎么让它变回刚买来的样子”。

关键词检索根据词和实体匹配内容。它对明确的代码、型号和术语很有用；配合同义词、规范化和规则，也能处理一部分不同说法，并不只是机械地匹配原句。

向量检索会用 Embedding 模型把问题和文本变成数值表示，再寻找语义相近的内容。它值得尝试的原因，是口语表达可能与原文用词不同；但“语义相近”不等于事实相同，“支持”和“不支持”、相似型号及相邻代码仍可能混淆。

于是才有混合检索：让关键词与向量各自召回，再合并候选。它是一个待验证的组合，不是一定胜出的答案。如果关键词已经达到要求，就没有必要只为架构完整而添加向量。微软检索架构指南也将关键词、向量、混合与过滤作为需要结合具体任务实验的选择。

另外，使用向量不等于必须部署 Milvus。对小规模资料，可以离线计算并缓存文档向量，在线只计算问题向量，再用 NumPy 做精确相似度计算。项目早期就测试了本地关键词、向量、混合和按条件重排等路线，先建立轻量基线，再考虑平台。

为什么不先做图谱

知识图谱是另一种组织知识的方式：把产品、部件、功能、故障等对象表示为节点，把“包含”“依赖”“适用于”等联系表示为关系。它擅长让系统沿着明确的联系查找知识，而不只是找到一段相似的文本。

例如，下面是一个假设的关系查询：

型号 A 使用部件 B；部件 B 适用维护流程 C。若部件 B 的维护要求变化，哪些型号及说明需要一起检查？

如果大量问题都是这种“从一个对象追到另一个对象”的关联查询，关系建模就很有价值。关系简单、数据结构稳定时，关系型数据库的关联查询也可能够用；需要图结构，不等于一定要立刻部署专用图数据库。

还有一个容易混淆的点：知识图谱不等于 GraphRAG，GraphRAG 也不是向量 RAG 的反义词。 图谱可以用于确定性查询，不经过大模型；GraphRAG 则是利用图等结构为生成式回答提供证据的路线。以微软的实现为例，它从文本提取实体关系、形成社区及摘要，用来支持实体周边查询或跨资料的整体性问题。这是具体实现，不是所有知识图谱的必备流程。GraphRAG 官方说明

本次先推进文档与问答检索，是因为当前材料以说明、FAQ 和规格文本为主，主要问题先落在“找到适用说明并回答”上，还没有建立一套以跨部件依赖、多跳关系或全库综合分析为核心的验收题。

如果现在把这些内容都转成图，还需要定义实体和关系类型，处理同名对象、型号版本、否定和适用条件，保留来源，并验证抽取及更新是否正确。自动抽取可以减少人工录入，但抽取出来的关系仍需要验收。若企业已经维护了可靠的产品和部件关系表，这部分增量成本就会不同，应该重新评估，而不是推倒重建。

因此，这次的取舍是：暂时没有足够的需求证据支持把建图作为首要投入，而不是证明图谱效果不如向量。 本轮没有图谱或 GraphRAG 的同口径实测，不能给它们排在后面。将来关系查询成为主要需求，可以把它作为独立支路，与精确查询、文本检索组合使用。

从路线走到平台

前面几种方法可以独立使用，也可以组合成 RAG 的证据获取环节。关键词、数据库查询和图检索都可以参与其中，并没有“先部署向量库，才能做知识问答”的固定顺序。

本项目接下来重点验证的是“产品范围约束 + 文档/FAQ 检索 + 基于证据回答”这条路线。在语音产品中的位置如下：

选定待验证路线后，再看它怎样进入产品 这是一条候选问答链路，不表示所有知识查询都必须经过向量或大模型
  1. 声音入口用户开口询问用法、限制或异常现象
  2. 语音识别 · ASR声音变文字得到需要处理的产品问题
  3. 业务范围确认适用产品型号、版本与权限先决定查哪里
  4. 知识获取查询适用资料可以精确查询，也可以搜索相关文本
  5. 大语言模型 · LLM基于证据回答缺条件先追问，无依据不编造
  6. 语音合成 · TTS文字变声音把回答交还给用户

本次没有测完整语音首响。实验从文字问题开始，测知识处理、检索与部分回答生成，不包含麦克风、ASR 和 TTS 耗时。

既然能自己写轻量检索，为什么还要看 FastGPT、MaxKB 等平台？因为检索算法之外还有上传、解析、分块预览、接口、任务状态和日常维护。一个知识库平台可以提供其中一部分通用能力，让我们评估哪些工作适合复用，哪些产品规则仍需自己负责。

平台不一定更合适。资料固定、只有开发者维护时，自建小服务可能更直接；多人持续维护、业务系统需要接口时，平台的管理能力才可能抵消部署与适配成本。因此后文同时看效果、速度、可集成性和运行问题，而不是只看聊天页面好不好用。

后文还会用到两个术语：知识块（Chunk） 是文档拆出的检索单元；重排（Rerank） 是对已召回候选再次判断相关性。块怎么切、是否值得加重排，都属于实验变量，不是 RAG 的固定配方。

实验快照截至 2026 年 9 月 4 日；文档链接于写作时核对。文中仅保留匿名化场景和汇总指标。后文主要比较检索与平台路线，未完成全文上下文、结构化查询、图谱等所有路线的统一对照；平台内的不同阶段也使用了不同题集与配置，结果分开说明。

测试设计

把链路拆开测

离线入库和在线问答是两种不同的工作。上传一份文档花了十秒，不等于每问一个问题都要多等十秒；页面能打开，也不等于后台向量服务已经可用。

一份资料，两条时间线 上面决定知识能不能用，下面决定每次问答怎样用；审核与发布是目标边界，不代表本轮已完成生产闭环
离线资料进入系统
  1. 上传与解析Excel、Word、PDF 转成结构化内容
  2. 分块与索引保留来源，检查非零块与内容覆盖
  3. 审核与发布隔离冲突内容，确认产品和版本范围
在线问题进入系统
  1. 校验范围服务端确定允许访问的数据集
  2. 混合召回关键词与向量共同寻找证据
  3. 组织上下文检查覆盖与冲突，按需考虑重排
  4. 生成首句先得到适合播报的一句话
  5. 保存证据记录来源、结果和分阶段耗时

慢在哪里就在哪一层排查：解析失败、检索错排、证据越权和模型生成慢，不应该都归为“RAG 效果不好”。

材料与环境

测试材料以一份约三万字、300 行的真实产品问答表和一份产品规格文档为基础。早期清洗发现的冲突或疑似错误内容单独隔离，内部规格也不能因为可检索就直接用于消费者回答。后续隔离实验重新组织了资料快照，不把不同阶段的条目数混为一套生产库。

平台运行在同一台本地 Mac 的容器环境中，但各自模型和入库方式并非完全相同。重点比较的版本是 FastGPT v4.15.8 与 MaxKB v2.10.5-lts；其他项目承担早期筛选或专项参照，不都进入最终测试。

怎样判断“效果好”

只问“最后答对了吗”会漏掉很多问题。测试分别观察：

  • Hit@1 / Hit@5：第一条或前五条结果里，是否至少出现一条标注的正确证据。
  • 完整证据 Top5：如果一道题需要多个片段，前五条有没有把必要证据全部找齐。
  • 澄清与拒答：缺少型号、条件或没有依据时，是否停止猜测。
  • 受限证据泄漏：本不该进入本次问答的内容，有没有被检索出来。
  • 检索 P50 / P95：分别看常见等待和尾部延迟，不能只看平均值。
  • 可播报首句时间：不是首个 Token，而是从文字请求到能组成首句的等待；仍不包含 TTS 与实际扬声器播放。

测试脚本保留查询编号、数据与参数版本、召回证据、逐次耗时及回答结果。先在开发集上调整策略，再冻结题集做验证；需要换资料或改配置时重新形成一轮记录，不挑最好的一次拼成结论。

候选如何收敛

我没有把所有项目都部署一遍，再按一个总分排序。更实际的做法是先判断它们能不能解决当前问题，再决定是否值得扩大测试。

路线或项目 本次走到哪一步 当前留下的判断
自建轻量检索 本地关键词、向量与混合基线 资料少、维护流程简单时仍有价值；管理面与发布流程需要自己补
MaxKB 13 题统一问答、并发、重启和短时持续测试 中文知识运营体验有吸引力，小集排序好；正式管理 API 的版本边界需要解决
FastGPT 小集问答、冻结 100 题检索、隔离与解析专项 继续做产品集成验证的第一候选，但尚有明确缺口
RAGFlow v0.27.1 独立配置下的本地 PoC 留作复杂文档解析参照；本轮配置较重，不拿其延迟与不同模型的结果作公平排名
Open WebUI v0.11.3 资料/API/检索/隔离/重启冒烟 在本次 Chroma 混合配置下没有满足在线检索筛选目标，未进入 100 题
AnythingLLM v1.16.1 早期轻量平台基线 本轮原生分块与检索对精确代码和口语混合问题的适配不足，未扩大测试
QAnything v2 仅部署前预检 当前测试环境未满足资源门槛，没有部署，也没有性能成绩

这里的“未入围”只针对这次设备产品知识场景，不代表项目整体不值得用。员工 AI 门户、跨系统企业搜索、复杂 PDF 阅读，与设备的低延迟产品问答，本来就不是同一种目标。

测试结果

小题集看到了什么

第一轮统一问答用了 13 道题：11 道可回答、1 道应澄清、1 道应拒答。两边使用同源资料、混合检索、Top5，关闭问题改写与独立重排；回答阶段由同一脚本调用 deepseek-chat，温度为 0、流式输出，证据上限为 1500 字符。

但它不是“只比较检索引擎”的实验：MaxKB 使用 text2vec-base-chinese，FastGPT 使用 bge-small-zh-v1.5；两者都用 pgvector。MaxKB 的表格规范化为两列 QA 后形成 300 段，FastGPT 原始表格入库形成 94 段，Word 各形成 6 段。

比较的是同源资料在两套实际平台配置里的效果，Embedding 和切块差异都属于结果的一部分。

指标 MaxKB FastGPT
可回答题 Hit@1 90.9%（10/11） 54.5%（6/11）
可回答题 Hit@5 100%（11/11） 100%（11/11）
最终回答规则判定通过 13/13 13/13
检索 P50 / P95 115 / 175 ms 64 / 114 ms
文字请求至可播报首句 P50 / P95 892 / 1285 ms 993 / 1391 ms
文字请求至完整回答 P50 / P95 1015 / 1816 ms 1110 / 1543 ms

这组结果比“谁更快”有意思：MaxKB 的第一条证据更容易命中，FastGPT 的检索更快，但它的可播报首句并没有因此更快。检索只是总等待的一部分，候选内容、上下文长度和模型生成都会继续影响结果。

两边的 13 道题最终都通过关键词、拒答和澄清规则判定，也不能写成“回答准确率已经达到 100%”。这是小规模自动规则评测，不是大规模人工金标；其中澄清和拒答各只有一道。模型从 Top5 里选对了内容，也可能遮住第一名错排的问题。

百题暴露的差别

方向筛选后，FastGPT 继续进入独立冻结的 100 题检索测试：60 道应回答、30 道应澄清、10 道应拒答。其中 10 道应回答题需要多条证据。问题覆盖口语改写、近似表述、否定条件、模拟识别错误及越界请求等情况。

这轮是在客户端并行调用关键词与向量检索，再按 1:1 权重做 RRF 融合。RRF 可以简单理解为“根据两路结果的名次合并排序”，不是直接相加两种不可比的原始分数。不要把这条选定策略等同于平台所有默认配置。

每题重复三次，总计 300 次检索；本轮没有调用回答模型。

检查项 结果
应回答题 Hit@1 56/60，93.33%
应回答题 Hit@5 60/60，100%
完整证据 Top5 59/60，98.33%
多证据题完整 Top5 9/10，90%
检索 P50 / P95 30.61 / 63.86 ms
应拒答题召回受限证据 4/10

最值得注意的是最后几行同时成立：前五条都能命中，不等于每题证据完整，更不等于访问边界安全。 受限资料如果已经进了候选上下文，就不能只指望模型在最后替系统保守秘密。

重排值得加吗

随后尝试了一个条件策略：关键词与向量的第一名不一致时，才调用本地 bge-reranker-base 重排 Top3。100 道题中有 34 道触发。

应回答题 Hit@1 从 56/60 提升至 58/60，但 P95 从 63.86 ms 增加到 882.07 ms，完整证据和受限证据泄漏没有改善。重排器准备耗时还未计入这个在线数字。

对这台机器和当前语音检索预算来说，这个收益不足以支持把该重排器放进默认在线路径。所以阶段选择是保留混合召回，先修资料、分块和排序问题。它不意味着所有重排模型都慢，也不意味着其他硬件、模型或异步场景不值得用重排。

这轮与前面的 13 题在题集、融合方式和运行节奏上都不同，不能直接把 54.5% 与 93.33% 相减，写成一次优化带来的提升。

权限先于相似度

产品 A 和产品 B 可能都有“快速模式”，同一型号也可能有不同版本的说明。如果先搜索全部资料，再让模型判断哪些内容能说，权限就变成了一个概率问题。

后续专项把产品可发布测试资料、受限资料和另一产品的受控样本拆成不同 Dataset，并在检索前精确检查产品、型号、版本、可见性和角色。生产设计中这些条件必须由服务端可信身份和授权规则确认，不能直接相信客户端自报的角色或 Dataset ID。

先决定能查哪里，再决定什么最相关 以下是路由原则示意，不展示内部系统结构
不通过停止检索
  1. 核验身份与范围产品、型号、版本或权限不匹配
  2. 网关拒绝不发送知识库检索请求
  3. 返回可解释结果必要时引导澄清，不猜测权限
通过限定范围
  1. 匹配白名单确定本次允许查询的数据集
  2. 范围内检索不让相似度扩大访问边界
  3. 证据交给模型再判断是否足够回答当前问题

Prompt 约束可以补充回答行为，但不能代替检索前的访问控制。

专项中，跨产品串库为 0/10，受限证据泄漏为 0/10，错型号、错版本或无权限的 5/5 请求在检索前被拒绝。

这些数字只说明这组测试通过了。它是在共享平台与数据库上的应用层逻辑隔离，不是物理数据库隔离，也不是完整安全审计。样本库的“可发布测试”标记更不等于业务已批准生产发布。

还有一个不能略掉的结果：拆分后，产品 A 的 10 道口语专项题 Hit@1 为 70%、Hit@5 为 100%。安全边界变清楚了，排序仍有问题；需要把隔离方案带回完整 100 题复测，不能直接沿用拆分前的 93.33%。

上传成功的假象

解析专项里最有提醒意义的不是哪种格式最快，而是一份没有文本层的扫描 PDF：页面显示 ready，实际知识块数却是 0。

如果只以任务状态验收，就会认为资料已经可用。用户开始提问后，才发现系统根本没有读到里面的文字。

本轮 FastGPT 使用原生解析，目标块大小为 512 字符、索引大小为 256 字符，未接 OCR；关闭重排与问题改写。检查结果如下：

资料格式 生成块数 标记覆盖 观察
300 行原始 XLSX 94 100% 多行可能合在同一块，需要检查问答边界
同源规范 Markdown 109 100% 更容易显式保留每条问答的边界
DOCX 6 100% 本轮普通正文和表格样本可用
文本表格 PDF 1 100% 12 行测试标记完整，但不足以证明复杂长文档能力
无文本层扫描 PDF 0 0% 显示完成不代表成功入库

“覆盖 100%”指本轮预设的行或内容标记被保留，不等于所有语义、表格关系和版式都无损。实际块长度也可能因解析结构和标题拼接而超过配置的目标值。

另一个细节是：集合级 metadata 可以读回，不代表每个召回块都带有完整的业务字段。本轮返回块没有父块字段，因此也不能把“索引比内容块短”说成已经实现完整父子块检索。

我的结论是，入库验收至少要检查非零块、关键内容覆盖、来源信息和可检索性。普通文本优先用简单解析；扫描件再走 OCR 或专业解析器。FastGPT 官方提供了外接 MinerU 的配置路径，但这轮尚未接入并验证，不能把配置能力算作已解决的问题。

快之外还测什么

为了避免只得到“单人点几次很快”的印象，两个主要候选还跑了纯检索并发测试，每档 50 次请求，不调用回答模型：

并发数 MaxKB P95 FastGPT P95
1 106 ms 52 ms
5 186 ms 97 ms
10 489 ms 189 ms

这些批次均没有请求错误。FastGPT 在本机配置下有更好的并发检索表现，但并发 10 的 P95 同样超过了本项目希望争取的 100 ms 检索预算。这个预算是场景目标，不是行业统一标准。

容器重启后，两边原有资料和索引都能恢复。按 2 QPS 运行 120 秒，MaxKB 完成 238 次请求、FastGPT 完成 239 次，均为零错误。

不过，两分钟不能证明长稳能力。备份恢复、外部模型中断、限流退避、队列积压、重复上传、磁盘增长和版本升级，还需要更长时间的验证。容器数量也不能直接换算成维护难度：一个容器可能内置模型占用大量资源，多个容器则意味着更多独立依赖需要监控。

选型与后续

为什么留下 FastGPT

如果只看 13 题的第一名命中，MaxKB 更好；如果只看一次纯向量查询，还可能找到更快的实现。把 FastGPT 留作第一候选，来自一组工程约束的共同作用。

要接业务系统，而不只是聊天页面

目标是让业务系统管理资料、跟踪入库状态，再给设备提供受控检索能力。FastGPT 有面向数据集、资料与检索的正式接口，本轮也验证了对应调用路径。它减少了对后台页面内部接口的依赖。实际接入应从 官方 OpenAPI 入口 核对当前接口和版本，不照搬旧示例。

MaxKB 的上传、分块预览和中文运营体验值得保留，但截至本轮核对，官方说明社区版未开放知识库管理 API；本次自动化 PoC 使用过后台内部接口，不能把它当成稳定的生产契约。若采用商业版或自行维护适配层，需要把这部分成本重新纳入比较。MaxKB 官方版本边界说明

性能有继续验证的空间

FastGPT 在所测配置下的检索和并发结果，让它值得进入下一轮验证；但首句时间并未全面领先，隔离后的排序也还需要改进。选它不是给所有指标颁第一名，而是判断剩下的问题是否能在可接受成本内继续解决。

不把未来锁死在一个组件上

本轮实际用的是 pgvector，不是 Milvus。FastGPT 的官方部署文档列出了不同向量存储选项，这提供了后续演进的入口，但不能反过来宣称本轮验证了 Milvus 性能。FastGPT 部署架构

可替换也不是换个地址就结束。更换 Embedding 或存储后，需要重建对应索引、检查数量与映射、复测召回和权限，并准备回滚。我们真正需要的是有清晰的改造边界，而不是今天就把所有备选组件部署起来。

所以更准确的说法是：选择 FastGPT 继续验证管理与检索能力，把产品身份、授权、审核发布和验收标准留在自己的业务边界里。 这不是把一个开源聊天页面直接当成公司的完整知识系统。

距离上线还有多远

这次测试回答了“下一步优先投入哪里”，还没有回答“现在是否可以承接真实用户”。接下来最有价值的工作已经比较明确：

  • 补齐路线对照：用相同资料范围、问题和回答模型比较全文上下文与检索方案；字段明确的问题单独验证精确查询。若出现稳定的关系查询需求，再设计图谱专项，不能只在已经选择的路线内部优化。
  • 复测完整链路：在隔离后的资料上重新跑冻结题集，再补回答忠实度、引用、澄清和拒答的人工检查。
  • 修复排序问题：优先看实体、口语和否定条件的错排，比较标准化 Markdown 与分块策略；用开发集调参，用独立集验证。
  • 补上扫描件支路：接 OCR/MinerU 后重跑同一压力集，验证零块失败可见、重试可控、重复上传幂等。
  • 完成运行验收：先做一小时预发布长稳，再扩大到二十四小时；加入模型服务中断、解析重启、索引重建和备份恢复演练。
  • 走完业务发布：确认资料的产品、型号、版本、审核状态与访问角色。测试通过的资料不能自动变成已批准对外回答的资料。

需要一起记住的边界是：本次是本机小规模评测，不代表公网多租户、高并发生产容量；13 题的规则正确率不能套到只测检索的 100 题上；各平台没有统一 Embedding 与分块，不能据此给纯检索算法排名；未部署的候选没有成绩，支持的扩展也不等于已经实测。

回到最初的问题，几万字资料并不天然需要复杂架构。真正把事情变复杂的，是资料会变化、产品有边界、用户会换一种说法，而系统仍然必须知道自己什么时候有资格回答。

这次选型最大的收获，不是找到一个“最好用的知识库”，而是建立了一套判断方法：资料是否真的进来了，证据是否找全了，内容是否允许使用，等待是否可接受，以及出了问题能不能定位和回滚。 平台可以换，这些验收问题不会消失。