一家药企想建AI知识库，报价10万到300万。老板花几十万找团队，首月demo约70分，三个月后毫无提升，技术方归咎模型上限。症结在团队缺乏大模型经验，只靠换开源、换智能体硬撑，量化不了效果也沉淀不出方法论，最终推倒重来。

之前一家公司是长期为药企提供市场报告的，他们手里有大量私有数据，很自然的老板想要找人做一个 AI 知识库，只不过收到的报价就很夸张：便宜的 10 万不到，贵的 300 万都打不住。

这突然就给他们老板整不会了，于是试探性地选了个大几十万的团队做实践，一个月就看见demo了，还感觉挺不错，至少有70分的水准。

但三个月后依旧不能超过第一个月的效果，还是 70 分，并且技术团队表示无论怎么努力都无法再进一步，最后结果只能推倒重来。

后面这个老板辗转找到我，原来他们找的技术团队没有大型 AI 项目的经验，之前是用 AI Coding 很快地做了个知识库。

至于如何那个团队是如何“无论怎么努力都无法再进一步了呢”，最终了解下来其实是传统老三样：

一个开源技术不行就换一个，单智能体不行就换多智能体，全部试过以后就说模型当前的上限就是这样，没有优化空间了，等新的技术开源了或者新的模型发布了再来一遍吧

但是为了优化效果，那个老板已经超出了很多预算了，于是也耐着性子忍不住要问他们：怎么量化上限、有没有过程方法论？

这个团队程序员就说量化不了、沉淀不了，都是别人的东西跑一下就好了，你如果用 AI Coding 就知道了…

那个老板虽然觉得哪里不对，但因为不懂也说不出个所以然，只能听之任之，然后再催着（求着）他们再试试其他办法。

于是那个团队硬着头皮又做了一波优化，改过提示词、调过Chunk、Embedding、TopK和Rerank，偶尔一个问题变好了，换一批问题又开始出错。

总之最后不了了之了……

而这个老板会选择他们，好像是因为包装宣传做得好，之前给他展示了一些 Demo，比如一键生成 1000 份文章、10 分钟做完一个网站、7×24小时智能体系统……

这些案例看上去都很爆炸，给该老板震撼到了，至于具体内容，他没细看，这种团队能做得好就奇了……

我相信这个 Case 已经可以足够展示当前 AI 知识库项目与 AI Demo 之间的差异性以及迷惑性了。

这里其实是不能怪这个老板、也不能去更多的苛求用人单位的。

因为AI技术这个东西确实挺令人迷惑的，AI项目就是写个提示词，这不有手就行？毕竟：AI 技术非常简单，简单到就是模型 API 的调用，几乎是个互联网人就行。

但 AI 知识库项目又极其复杂，他要求关键人具有复合型能力，包括业务 KnowHow、模型能力边界认知、强大的工程能力。

而就是因为AI技术好像很简单，一个人一个月就能出 demo，会让人觉得 AI 项目成本很低；但当他们实际遇到模型幻觉、对话生硬、答非所问等问题时，又总是束手无策。

所以，为什么呢？

范式变了

答案其实很简单：当前技术架构范式变了，很多人还在用软件开发项目的思维去做 AI 知识库，他们甚至连当前到底有几种 AI 知识库技术范式都搞不懂，更何论去选择合理的技术框架呢？

就上述老板的诉求，其实是一个典型的 AI 知识库项目，这类项目真正困难的部分，是知识工程，但他又跟一般的 RAG 项目不同。

药企市场研究这种专业场景，普通人本来就很难判断答案质量。只要文章结构完整，数据看上去合理，里面再出现几个专业名词，很容易产生一种它真的懂了的感觉。

但回答像一份市场报告，不代表它真的完成了市场研究。如果把他们业务里的一类典型任务抽象出来，问题可能是这样的：

请结合过去五年的行业报告和底层数据

分析某类药物在不同区域、渠道和适应症上的市场变化

判断今年增长主要来自患者数量、价格变化还是竞争格局变化

并标明每项结论的数据来源和统计口径

这个问题交给Demo以后，它也能生成一份像模像样的分析。

但专业人员一看，很快就会发现问题：有的表格被读错了，有的数字来自不同统计口径，同一种药物在不同报告里使用了不同名称，两份资料结论冲突时系统选了时间更早的一份，甚至把同时发生写成了前者导致后者，这些错误无法再通过润色语言解决。

大家可能不太明白我在说什么，这里我举个例子：

你问 A 和 B 的关系是什么？

典型的 RAG 系统，其实并不真的理解“关系”这个词的含义。它所能“知道”的，仅仅是在大量文本数据里，“A”和“B”这两个词经常同时出现。

于是，它的工作方式是这样的：去知识库里“翻找”所有同时包含“A”和“B”的段落，然后从中挑出一段跟你的问题最“像”的内容，再把这些文字拼接到一起，包装成一段回答，返回给你。

结果就是，你收到了一段“看着很像是答案”的文字。

但严格来说，这段文字是“东拼西凑”出来的，而不是系统真正“读懂”了你的问题之后，自己思考出来的结论。

所以，那个团队是没有 KnowHow 的团队，做出来的东西效果差还在其次，真正麻烦的是没人知道它究竟差在哪里：

Demo 证明的是模型会说话，生产系统需要证明每一个结论从哪里来

接下来，我们就用这个真实案例，去悉数列举 AI 知识库的一些常见技术范式：

一、AI真的读懂了吗？

对于这个需求，很多团队最初的处理都很经典：把PDF转成文本，再按固定长度切成Chunk，生成向量以后放进数据库。

用户提问时召回最相似的几个片段，交给大模型生成答案，这就是最基础、最经典的 RAG。

RAG 这东西，用它处理结构清晰的产品FAQ问题不大，但真实的市场报告远没有这么干净。

一份报告有价值的信息，可能存在于标题层级、页眉页脚、图表、脚注和附录里。一个数字离开章节标题以后，系统不会知道它描述的是哪个市场、哪个年份和哪一种统计口径。

例如，报告中原本写的是：

第三章 终端市场分析

3.2 院内渠道

3.2.1 华东地区样本医院销售额

2025年同比增长12.4%

如果解析以后只剩下“2025年同比增长12.4%”，这句话当然可以被向量化，也可以被召回，但它最关键的语境已经丢了。

大型表格会更加麻烦，年份、药品、销售额、渠道和增速原本依靠行列关系表达，一旦被抽成一串没有结构的文本，模型就只能靠猜测恢复。

这也是很多企业知识库逐渐在抛弃向量库的原因：无脑讨论Embedding、向量库和Rerank，对于资料被正确还原没什么帮助…

垃圾解析后面接再好的模型，会形成一条稳定的垃圾生产线：

垃圾解析 → 垃圾切块 → 垃圾索引 → 垃圾召回 → 模型一本正经地基于垃圾胡说八道

所以，如果想继续使用 RAG 这套范式，就必须在每个Chunk上叠加更多摘要信息，比如我们就会保留报告、章节、段落、表格等多种粒度；不再只做向量检索，还会加入关键词检索、元数据过滤、查询改写、Rerank、上下文扩展和引用回溯。

这也是NotebookLM一类产品体验更好的重要原因。用户看不到Chunk、TopK和向量库，不代表这些工程不存在。更可能的情况是，系统把文档理解、多粒度索引、检索排序、上下文组织和来源引用一起收进了产品内部。

总之，完整的RAG系统解决的是能不能把回答所需的证据完整、准确地找回来的问题。

只不过，就算上述团队做到这一步，也大概率不能满足客户实际需求。

二、报告的信息量够吗？

这个项目刚开始时，老板认为公司最重要的资产就是积累多年的报告，这个理解自然是对的。

但大家要清楚：报告只是最终产物。他们过去在生成这个报告的时候还有很多“燃料”呢，这些燃料包括底层数据、统计口径、对象关系、分析方法和专家判断……

例如，销售额、市场份额、患者数量、地区、渠道和医院等级，大量信息存在Excel、数据库或者内部数据平台里。

用户问

过去三年某种药物在华东地区院内渠道的销售额是多少

系统需要精确查询和计算，向量检索找到一段包含相似数字的文字，并不能回答这个问题。

于是，情况变复杂了，如果真的有完成需求，所需的知识库数据要多出很多，需要接入结构化数据，甚至需要跟企业内部 SaaS 系统打通，比如我们当时梳理出来的一套完整 SOP：

自然语言问题

→ 识别药品、时间、地区和渠道

→ 确认统计指标

→ 生成SQL或API参数

→ 执行权限校验

→ 查询底层数据

→ 验证结果

→ 生成解释

其实当时在陪跑的时候，这里开始已经有点复杂并且超出那个老板的预期了，原因很简单：他开始以为是自己玩，结果还是免不了要介入人家的系统，而各个企业的接入成本就高了去了…

因为他面临的问题很多，他不止服务一个大客户啊，如果公司体系多了，问题就更复杂了，比如：同一种药物可能同时拥有通用名、商品名、研发代号和多个规格；一家药企也可能存在集团、子公司、品牌方和经销主体。

如果没有稳定的业务对象，系统甚至不知道两份数据说的是不是同一个东西…

这时继续调整向量相似度已经没有意义，系统需要完成实体识别和身份统一，并把事实组织成关系：

药企A——生产——药物B

药物B——属于——某类靶向药

药物B——适用于——适应症C

药物B——通过——院内渠道销售

药物B——在华东地区——同比增长12.4%

知识图谱就在这一刻出现了。它是在业务问题已经无法通过一段文本或者一张表直接回答以后，被真实需求逼出来的。

并且还得留出公告的接口，让各个企业能把名词跟你独有的图谱系统映射上去，毕竟你又不是行业标准！

RAG负责寻找相关资料，结构化查询负责获得精确数据，知识图谱负责把分散的业务事实连接起来。

三、图谱之后呢？

知识图谱可以告诉系统，不同对象之间存在什么关系。例如，两份报告对“某药市场规模”的统计可能都没有错，但一份采用样本医院销售额外推，另一份采用终端零售数据；一个数字按照药品通用名统计，另一个按照品牌统计。

它们可以同时正确，却不能直接比较。系统还需要知道：

市场规模有哪些合法统计口径；

商品名、通用名、成分和剂型是什么层级关系；

哪些指标可以汇总，哪些指标不能相加；

哪些结论能够继承，哪些关系不能反向推导；

数据冲突时，时间、来源和统计范围如何决定优先级。

这层公共定义，就是本体。本体负责定义企业业务世界里有哪些类型、属性、关系和约束；知识图谱按照这套结构保存具体事实；规则引擎再根据事实和约束执行判断。

可以用一句话记住三者的关系：

知识图谱记录这个世界发生了什么，本体规定这个世界应该如何理解，规则引擎决定这一次应该怎么办

在大模型出现以前，本体和知识图谱一直很难普及。需要专家定义对象和关系，实体识别与关系抽取依赖大量规则和标注，业务稍有变化就可能需要重新维护。

大模型改变了这套成本结构，现在做一套图谱的成本可能只有之前的 1/10——1/20。

但这里千万不要产生新的误解：AI降低的是知识抽取成本，但实现成本依旧很高。比如以下几个问题，我当时也纠结了很久：

1. 市场规模应该采用哪个口径；
2. 两个部门的指标定义冲突时听谁的；
3. 某个例外应该成为长期规则还是临时处理；

这些问题最终仍然需要真正理解业务的人决定。

所以，本体设计表面上是技术建模，底层其实是企业的业务定义权，这种东西处理知识之外还会涉及“争权夺利”…

四、最终是什么样的？

到这里，系统已经可以正确识别对象和理解关系，听起来应该够用了；但别忘了，这个老板最初的目标是希望AI承担一部分研究员的工作，去生成一份报告，这里会涉及他们更完整的 SOP 了，这里是我脱敏阉割后的版本：

确认研究问题 → 确定时间、区域和统计范围 → 选择数据口径 → 查询底层数据 → 检索行业资料 → 排除异常值 → 比较多个来源 → 识别矛盾 → 形成判断 → 绑定证据 → 专家复核

如果希望蒸馏一名研究员，仅仅上传他过去写过的报告远远不够。历史报告属于Data，生产报告的方法属于SOP，两者合在一起才构成真正的业务KnowHow。

流程比较稳定，可以使用Workflow固定；步骤较多、但可以拆成一组独立能力，可以写成Skills；路径无法提前完全确定，再让Agent根据任务选择数据源、调用工具、发现信息缺口并决定下一步。

这也是真实工程里最常见的形态：

Agentic Workflow + 多种知识工具

Agent负责推进任务，RAG、SQL、API、知识图谱和规则引擎分别提供每一步所需的信息。

还需要做什么吗？

在我们做系统验证的时候，系统做对了 10 次，企业就可以把它交给客户吗？

答案可能还不行，因为生产级 AI 系统要求的不只是某一次答案正确，还要知道它为什么正确、什么时候可能错误、错的时候该怎么办。

一份真正可以交付的分析结果，还需要回答：

1. 使用了哪些原始报告和底层数据；
2. 采用了哪一种统计口径；
3. 哪些内容是事实，哪些属于模型推断；
4. 哪些环节必须由研究员复核。
5. …

这意味着项目需要建立完整的证据链、日志和评测体系。

评测也不能继续使用大家感觉有70分。需要准备真实业务问题和标准结果，把错误拆成文档解析错误、召回错误、数据口径错误、计算错误、引用错误、推理越界和流程执行错误……

只有知道错误发生在哪一层，团队才知道下一轮应该修改数据、检索、规则、模型还是SOP。

系统上线以后，还需要形成持续运转的反馈闭环：业务人员发现问题，系统记录失败样本，专家判断根因，知识负责人更新数据、关系或者规则，评测系统执行影响面回归，再把新版本投入生产。

这正是最初项目无法从70分继续提升的核心原因。他们拥有功能迭代，却没有知识迭代，没有把错误转化为数据和评测资产。

结语

走完整条链路以后，最初那个让老板困惑的问题终于可以回答了：不同价格的 AI 团队到底有何不同？

不到10万的团队，可能交付的是文件上传、基础RAG、聊天界面和一套演示效果不错的Prompt。

几十万的项目，可能进一步包含文档解析、混合检索、Rerank、引用溯源、测试集和少量业务系统接入。

几百万级项目讨论的可能已经是历史数据清洗、统一业务对象、多系统映射、知识图谱、本体、规则体系、权限审计、评测平台和长期知识治理。

当然，报价贵不代表一定做得好。问题的关键在于，这些团队虽然都把产品叫作AI知识库，承诺交付的却可能完全不是同一个东西。

企业采购时如果只比较价格和Demo，很容易把一个知识工程项目，买成一个带聊天框的文档搜索工具。

这也解释了为什么这类项目需要复合型的一号位。因为生产级AI项目极其复杂，关键人员需要同时理解业务KnowHow、模型能力边界、数据工程和软件工程。

至于，企业到底需要什么技术范式，可以先根据任务判断自己走到哪一层：