1. AI-Native落地卡了壳：决定先啃知识库这块硬骨头
团队内部喊"AI-Native"喊了大半年，口号从"全面拥抱大模型"到"所有业务线都要有AI能力"，但真正推下去的时候才发现，最卡脖子的不是模型选型，也不是API调用，而是——知识根本喂不进去。
我理解里的AI-Native，不是把几个大模型API接到业务流程里就完事，而是让AI真的变成业务的一部分：它得懂我们的产品、我们的客户、我们的历史案例、我们的踩坑记录。模型本身什么都不知道，它知道的全部来自我们愿意喂给它的东西。这时候，AI知识库的能力建设就成了AI-Native落地最底层的那块地基。
最开始我们踩过的坑特别典型：让业务同事把资料直接丢给ChatGPT类的对话窗口，问一句答一句，回答质量忽高忽低；后来让技术同事把文档全塞进Prompt里，窗口大一点就崩，小了就漏；再后来开始有人提"要不我们搞个RAG知识库"，但这个说法在团队里流传了很久，真正动手做的人寥寥无几——大家普遍觉得"这不就是装个开源软件把文档传上去吗"，结果真做起来才发现，从文档清洗到分块策略，从向量化到检索排序，每一环都有坑等着你。
这篇文章想分享的就是海博团队在过去几个月里，从零搭建AI知识库能力、并把这套能力真正接进业务流程的完整过程。不是那种"三分钟上手Dify"的速成教程，而是把我们选型时的纠结、搭建时的踩坑、检索调优时的挫败、以及最后上线时的运营方法，全部摊开来讲。适合正在做企业级知识库建设、纠结开源方案怎么选、或者RAG检索效果一直不理想的朋友参考。
先说结论：一个能用的企业级AI知识库，不是"装个工具传个文档"就能搞定的，它本质上是一条从资料管理到检索增强再到人机协作的完整流水线。这条流水线跑通了，AI-Native才算真正有了落地的抓手。
2. 知识库选型实录：为什么开源方案反而成了我们的最优解
2.1 选型前的需求盘点：我们到底需要一个什么样的知识库
很多团队一上来就列工具对比表，我觉得这是本末倒置。选型之前应该先回答一个问题：你的知识库给谁用、用什么内容、解决什么问题。
海博团队当时梳理出来的需求大概有四层：
第一，内容类型复杂。我们手上有产品说明书、售前方案、项目复盘文档、客户会议纪要、售后工单、甚至微信群里的技术讨论精华。格式涵盖PDF、Word、Markdown、Excel、HTML，总量不大但极度分散，散落在个人电脑、网盘、Wiki和聊天记录里。
第二，使用场景明确。前端销售要快速找到产品卖点和竞品对比；技术支持要能根据故障描述定位历史解决方案；研发要能检索到架构决策记录和踩坑笔记。三类人的问题形态完全不同——销售问的是"我们产品支持不支持XX功能"，技术支持问的是"客户报错XXX该怎么处理"，研发问的是"之前为什么选了XX方案"。
第三，答案质量要求高。知识库不是搜索引擎，给一堆链接让用户自己点开看，那不叫AI知识库。我们要的是"直接给出基于企业内部资料的确定答案"，并且能引用来源文档。这就要求底座能力不只是检索，还得有答案生成和溯源。
第四，权限隔离不能少。有些资料属于保密级，只能内部访问；有些方案文档只能特定部门看。知识库如果没法做权限控制，业务部门根本不敢往里放核心资料。
带着这四点去看市场上现有的方案，基本就筛掉了一大半。
2.2 商业SaaS、大模型原生工具、开源平台的三角对比
市面上做知识库的工具大致分成三类：商业SaaS知识库（比如各种"AI知识库"订阅产品）、大模型厂商自带的扩展能力（比如某些模型平台的Knowledge功能）、以及开源知识库平台（Dify、MaxKB、RAGFlow这类）。
商业SaaS我们试用了一圈，优点是省心，传文档就行，但问题也很明显：数据安全不可控，销售签单时拿"我们不能把核心资料传到第三方平台"说事，CTO直接一票否决；并且定制能力有限，如果后续要接自己的审批流、要改检索策略，SaaS通常只给配置项不给改代码。
大模型自带的知识库功能我们也试了，本质上就是一个受管的RAG服务，上传文档、自动切片、对话查询，demo效果不错，但一旦涉及复杂一点的查询就显得力不从心——比如"找出所有和XX客户合作过程中踩过的坑"，这种语义上需要跨文档聚合的问题，它的相关性排序明显不够用。
最后我们把重心放在开源平台上。这里说一下当时筛选的几个项目：
| 平台 | 语言 | 核心特点 | 我们考察时的顾虑 |
|---|---|---|---|
| Dify | Python | 工作流编排强，知识库只是其中一环，能接Agent、能画流水线 | 太重，嵌套功能多，上手曲线陡 |
| MaxKB | Python | 专注知识库问答，界面简洁，中文支持好，部署轻量 | 检索策略相对固定，二次开发空间有限 |
| RAGFlow | Python | 文档解析能力强，能处理复杂版式，有配套的检索策略 | 对服务器内存要求高，小资源跑不动 |
| 自研（向量库+向量化接口） | 不限定 | 完全可控，灵活度最高 | 开发工作量大，周期长 |
纠结了很久，最终我们选了Dify作为主框架，但只用了它的知识库流水线和API发布能力，外围的权限和同步逻辑自研。原因后面细说。
2.3 海博最终选型的理由：综合评估与取舍思路
为什么没选MaxKB？它确实简单，半天就能跑起来，但知识库问答只是它全部功能的一块，后续如果我们想在这个知识库上叠加更多AI能力（比如接入业务流程的Agent编排），它就有点不够用。RAGFlow的文档解析确实很强，复杂PDF表格都能处理，但它对部署环境的要求让我们有点犹豫——当时团队手里的服务器只有4核8G内存，跑RAGFlow的体验大概率不理想，而且它更侧重"非结构化数据的抽取"，和我们的知识管理诉求不完全对口。
自研的顾虑则很现实：团队那么多人等着用，内部交付节奏不允许我们用一两个月去从零搭一条RAG流水线。而且RAG看起来简单——"向量化+检索+Prompt拼接"，但做过的朋友都知道，要维护文档解析器、分块逻辑、向量库、查询改写、重排模型，随便一个环节出细节问题都要花大量时间排查。
所以Dify成了"平衡点"：它自带完整的知识库流水线界面，能直接上传文档、选择分块方式、配置检索策略，还有现成的API输出，可以直接通过OpenAI兼容接口风格接入我们自己的应用。更重要的是它的流水线编排能力给我们留了后路——以后知识库要接Agent、要做多轮对话策略干预，在这个框架上能直接改，不需要推翻重来。
提示：如果你的团队服务器资源有限（比如8G以下内存），Dify部署时可以关掉不用的插件模块，并用SQLite替换PostgreSQL来降低初始资源占用，后面跑稳定了再迁过去。
3. RAG流水线搭建中的关键节点：从文档入库到向量检索
3.1 文档接入：比想象中麻烦的"数据清洗"
知识库搭建的第一步是文档接入。听起来就是"把文件上传上去"，但实际做的时候你会发现，最麻烦的不是上传，而是上传之前的状态。
我们当时把散落在各处的文档收集上来之后，做了一次集中清洗，主要处理四类问题：
- 格式灾难：一堆Word文档里面嵌套表格、文本框、页眉页脚，PDF还有扫描件和加密版。直接喂给解析器，出来的文本经常乱成一团。
- 版本混乱：同一个产品手册有v1.2、v2.0、v2.1三个版本，内容相互矛盾。知识库如果全收进去，AI回答时随机抽一个版本，抽到旧的，回答就和现实对不上。
- 冗余信息：PPT转出来的PDF里全是演讲者备注和无意义的跳转页；Word文档里夹着领导批注。这些都会污染向量索引。
- 命名不规范：几十个文件叫"新建文档.docx""未命名111.pdf"，不点开根本不知道里面是什么，入库之后也没有办法做知识结构管理。
我们当时用Python写了一个批量清洗脚本，核心逻辑是：解析文档 -> 提取正文 -> 去水印/批注/页眉页脚 -> 按规则重命名 -> 输出标准化Markdown或JSONL。这一步花的精力比预想的多，但非常重要——脏数据进库，检索效果一定差，而且后面很难定位是数据问题还是策略问题。
如果你不想写脚本，临时方案是先把所有文档统一转成Markdown（很多在线工具或本地工具都支持批量转换），再手动做一轮目录级的人工校对。但长期运营下来，还是建议在接入层做一个标准化的清洗管道。
3.2 分块策略：chunk size怎么选，为什么不能跟风
清洗完成的文档要做分块（chunk），这是决定检索精度的核心环节之一。
分块策略有两个极端：块太大（比如整篇塞进去），向量表示模糊，检索精度下降，而且喂给大模型的上下文会浪费大量token；块太小（比如按句子切），语义不完整，经常出现"答非所问"。
Dify里默认给了一些分块模板，比如按Token数切、按分隔符切、按Markdown标题切。最开始我们直接用默认的token切法（每块约500 tokens、重叠50 tokens），效果很一般。后来逐步调参，最终找到适合我们的模式：
- 按Markdown标题层级切为主：文档本身有章节结构的，按标题切块比按token数切更符合语义边界。
- 块的大小控制在300~600 tokens：太短语义不全，太长容易让检索出"部分命中但整体不相关"的块。
- 切片重叠设为50~100 tokens：防止一条完整信息正好被切成两半，两边都检索不到全貌。
- 对表格和代码块单独处理：默认解析器对表格的提取经常是逐行拆开，导致语义断裂。我们的做法是把表格整体转成JSON字符串或者按行合并成一段文本再入库，代码块则单独标注语言类型存入，方便大模型识别。
调完分块参数后，检索的Recall有明显提升，但"大量命中的块重复涵盖同一段内容"成了新的问题。这就是为什么还需要做去重——我们在入库环节对高相似度块做了一遍向量相似度去重，保证同一份知识在库里只保存一个版本。
注意：不要迷信网上的通用分块参数。chunk size要结合你的文档类型、业务场景和模型上下文窗口一起来定。文档本身是长段落多还是短段落多？查询问题更倾向于命中段落级信息还是句子级信息？这些都要实测验证，没有"一刀切"的配置。
3.3 向量化与向量库选型：中文场景的embedding选择
分块完成之后，无论是Dify还是自研方案，都需要做向量化。这个环节最大的坑是——用错Embedding模型，中文检索效果会很差。
我们一开始图省事，用了某个通用多语言模型直接跑，结果客户提问"产品支持并发吗"、库里明明是"最大在线用户数"，检索出来相关度极低。原因是通用模型的向量空间对中文业务语义的区分度不够，而且我们领域有很多缩写和行业黑话，通用模型根本没学过。
折腾下来，我们锁定了两条路：
- 使用中文优化过的开源Embedding模型（比如BGE系列、M3E系列），本地部署，数据不出内网。它的中文语义理解能力比通用多语言模型好一截，而且开源免费。
- 如果考虑效果再提升一档，可以微调Embedding模型——用我们业务里的问答对和文档片段做少量领域适配训练，但这需要比较强的技术积累，我们当时没有急于做，而是先把主线跑通。
向量数据库这边，我们对比了Chroma、Milvus、Qdrant。本地搭建零基础教程里最火的是"ollama + langchain + chroma"，这套组合确实轻量，适合个人玩。但企业级的场景——多用户并发查询、权限过滤、增量更新——Chroma就显得有些单薄。最终我们选了Qdrant，原因是：部署不算重，Docker单机能跑，支持Payload过滤（可以在检索时直接按权限字段过滤），性能足够支撑我们的量级。
Dify内集成了多家向量库的接入方式，我们在Dify里配置的是Qdrant，相当于用Dify的界面做文档管理，用Qdrant做向量存储和相似度检索。
3.4 检索策略初调：混合检索、TopK和Score阈值
库建好了，向量化也跑了，按理说可以开始聊了。但真正用起来，第一个明显的槽点是召回结果不稳定。
原因在于纯向量检索（也就是语义检索）有几类原生弱项：精确的型号、编号、报错码，向量检索经常匹配不上——因为语义相似度和字面精确匹配是两回事。客户问"报错码ERR-3021怎么解决"，模型可能觉得"ERR-3021"这个token不重要，反而去匹配了"报错"两个字相关的其他内容。
这个问题的解法是混合检索：向量检索 + 全文检索（关键词匹配）。整个逻辑是：先同时跑两条检索路径，向量语义召回一批，全文关键词精确召回一批，两路结果做融合排序，最后取TopN给大模型。
Dify里这一步配置起来还算顺手，能选"向量检索"或"混合检索"，还能设置Rerank模式。我们把全线文档改成混合检索之后，报错码类问题的命中率直线上升。
TopK的设置也值得说。默认的TopK=4对于简单问答够用，但我们的知识库里同一个问题往往分布在多份文档里，TopK太小会丢信息。我们最后把TopK调到8~10，再配合一个Rerank重排模型，先召回更多候选，再用重排模型精排，去掉不相关候选项。这套"粗召回+精重排"的组合拳，是RAG知识库效果提升的关键分水岭。
4. 检索匹配度上不去的真相：一次完整的调优排障链路
4.1 症状描述：客户问的问题，知识库总是答非所问
工具全部上线、第一批文档入库后，我们找几个业务同事试用，反馈非常一致："答非所问。"
举个例子。销售问："我们产品在离线环境下能用吗？"知识库的答案是介绍产品的在线协同功能。再问："支持国产化环境部署吗？"知识库翻出来的是某次POC测试的环境搭建记录，答案完全没有正面回应。这一批问题让团队相当沮丧——看起来该做的都做了，为什么效果还是不行？
我决定不急着调参数，先把问题复现一遍，走完整链路看数据。这一步很关键：排障不是猜，是要拿证据链说话的。
4.2 定位过程：从数据、分块、检索、生成四层逐层剥
我把整个RAG链路画成了一条流水线：文档数据 -> 分块 -> 向量化 -> 召回 -> 重排 -> 拼接上下文 -> 大模型生成。哪一层出问题，表现都可能是一样的"答非所问"。所以我们逐层排查。
第一步查数据层。我把销售和客户聊的那些专业问题拿去全文检索，发现部分关键信息（比如"离线""国产化"）确实在文档里存在，但措辞和用户提问完全是两套词汇——文档写的是"本地化部署""信创环境"，用户问的是"离线""国产化"。这说明纯纯的词汇鸿沟问题，向量检索理论上应该能跨表述找语义，但它没做到。
第二步查分块层。我把召回结果打印出来看，发现很多命中的块是那种"章节标题+半截表格"的碎片。为什么？因为我们按Markdown标题切后，某些长表格被中间切开，每个块只包含表格的几行，语义严重不足。向量化出来的向量也就抓不住核心意图。
第三步查向量检索。我提取出用户的Query向量，和命中的块向量做了相似度对比，发现相似度得分普遍只有0.55~0.65，而理想情况下应该在0.75以上。这是Embedding模型和领域词汇之间"隔阂"的直接体现。
第四步查生成层。检索回来的信息其实有部分相关，但Prompt拼出来之后，大模型被一堆低相关度上下文干扰，优先采信了那些它认为"像答案"但其实不准确的内容，最终输出跑偏。
4.3 对症下药：五个关键调整逐一落地与效果回测
定位清楚之后，我们做了一个调整清单，逐一落地，每次只改一个变量并做回归测试：
调整一：升级Embedding模型，加入领域适配。这是效果提升最明显的一步。我们从通用多语言模型换成了中文效果更好的Embedding模型，并把我们业务的高频词（产品名、功能名、行业术语）整理成词典，在向量化之前对文本做了一次轻量级的术语归一——把"本地化部署"同时标注意义等价词"离线环境"，把"信创"标注成"国产化"。这样既保留了原始表述，又给向量化补充了等义词信息。
调整二：重做分块逻辑。对含有表格和代码的文档走单独分块：表格整体转成JSON存入块内，代码块单独成块并标注类型。同时把块加大了20%，避免长段落被切得太碎。
调整三：开启混合检索并调融合权重。把全文检索的结果和向量检索的结果做加权融合，全文命中时权重给高一些，特别对报错码、型号、编号这类精确信息。
调整四：接入Rerank重排模型。召回TopK从4调到10，再用重排模型精排，取前5条进Prompt。这一步显著减少了无关块对生成的干扰。
调整五：Prompt里加"如果不确定就拒绝回答"的约束。这个看起来简单，但对体验的影响非常大。之前模型经常硬着头皮编答案，加了这个约束之后，遇到知识库里没有的内容，模型会明确说"资料库中未找到相关信息"，用户也不用花时间甄别回答是真是假。
每一轮调整之后，我们都用同一批20个典型问题跑回归测试，对照答案命中质量打分。从最初整体62分左右，调到最后一轮基本稳定在88分上下。其中"离线环境"和"国产化"这两个当初必错的问题，最终都能准确命中对应文档，并给出步骤式答复。
4.4 关于"提高匹配度"这件事，我悟出的几条通用规律
这段是给正在调RAG的朋友的。匹配度上不去，90%的情况不是"换个更大模型"能解决的，而是下面某几项没做到位：
- 数据质量永远是第一位的。不干净的数据、不过是版本混乱的数据，再好的检索策略都会把噪声检索出来。
- 词表和术语归一化是中文场景里性价比最高的优化。很多RAG项目忽略这一点，认为向量模型应该自动理解同义表述，但实际效果远没有想象中好。
- 混合检索不是"可选项"，是"必须项"。特别是企业知识库里大量存在型号、编号、报错码这类精确值，纯向量检索必败。
- 重排在RAG里的价值被很多人低估。粗召回靠向量和全文，精排靠重排模型，两级结构能把端到端效果拉高一大截。
- 调参一定要做对照实验。不要同时改两个变量，不然出了问题你根本说不清是哪个调整带来的提升。
5. 企业级知识库真正的分水岭：权限、版本与运营机制
5.1 权限模型怎么设计：不能被"一刀切"毁掉
我们一开始把整个知识库设成全员可读、管理员可写。结果发现三个部门反馈完全不一样：销售觉得资料不够全、技术支持觉得回答太浅、研发直接说"这库里的方案早就过期了，你们别推给我用"。
问题出在哪？没有把权限和内容组织对应起来。企业知识库如果只有一层全量访问，那内容创作者就没法安心上传核心经验。我们重新设计了三层权限模型：
- 公开区：产品介绍、公开白皮书、通用FAQ。全员可见，AI回答可以直接引用。
- 部门协作区：销售话术库、技术案例库、项目复盘库。只对相关业务线开放，AI检索时按部门过滤。
- 密级资料区：商务报价、战略文档。仅项目成员可访问，知识库检索时不索引、不召回、不进入对话上下文。
这个分层带来的直接好处是：销售问的问题不会从研发的项目复盘里抓来一堆名词堆砌的答案；研发也不用担心自己写的架构决策记录被前端拿去乱用。权限不是限制，反而是让更多内容敢入库的前提。
在Dify里的实施方式，我们是利用它的数据集（Dataset）权限和外部API的元数据过滤组合实现的：每个数据集对应一个知识域，外部调用API时带上部门和角色标签，Qdrant的Payload Filter在向量检索阶段直接过滤掉无权访问的文档块。
5.2 版本管理：知识库里的"内容过期"怎么治
知识库上线一个月后，我们遇到了一个尴尬场景——之前的AI回答引用了已下架产品的文档。因为旧版本产品手册仍然躺在库里。
企业知识库最容易被忽视、但后期最致命的问题就是知识过期。RAG系统只会忠实检索你库里有的内容，它不会自己判断"这个文档今年已经失效了"。如果库里的信息过期，AI就会一本正经地输出过时答案——这比不输出答案更危险，因为用户很难察觉。
我们的解法是两条腿走路：
- 文档生命周期管理：入库的时候就给每份文档打上有效期、owner、知识域标签。定期跑任务，把过期文档下架或标记为"历史版本"。AI检索时优先命中有效版本，只有当有效版本缺失时才允许查"历史版本"并明确告知用户这是历史资料。
- 来源溯源和版本展示：每次回答下面强制附上答案引用的文档名、版本号和更新时间。用户看到"引用自产品手册-v2.1，2025-06更新"，就知道信息是有据可查的，也能在版本过期时第一时间去资料库反馈。
这套机制上线后，我们的核心资料更新率明显提高了。没有版本管理之前，owner根本不知道自己的文档什么时候过期、有没有被AI引用；有了生命周期和引用记录，资料owner会主动来更新内容——因为AI回答里明确标注了文档名，内容过期一眼就能看见，没人愿意自己的名字挂在一份过时的文档下面。
5.3 运营机制：知识库不是"搭完就算"，要有人持续维护
很多团队做知识库的失败点不在技术，在运营。我见过太多例子：搭建的时候热火朝天，上线之后没人管，三个月之后库里的文档还是三个月前的那批，AI的质量也随之崩掉。
海博团队的实践是设立了一个兼职的"知识库运营小组"，由每个业务线抽一个人组成。职责讲清楚：
- 每周新增入库：本周业务里出现了哪些新知识？新的POC结果、新的答疑记录、新的客户反馈，都沉淀进去。
- 每月过期清理：跑一遍文档生命周期任务，把过期文档下架或者更新。
- 每季度复盘问答质量：把用户真实提问中回答得分低的挑出来，做一轮根因分析，是缺文档？还是检索策略问题？然后推动整改。
- 语料来源标准化：把聊天记录、会议纪要里高价值的内容定期整理成结构化FAQ或案例文档再入库，减少噪声。
这套运营机制跑起来之后，知识库才真正从一个"项目"变成了一个"能力"。我们内部现在的说法是：AI-Native落地，三分靠搭，七分靠养。
6. 三个月后的复盘：AI知识库到底改变了什么
6.1 三个业务场景的真实使用效果
知识库上线三个月，我统计了一下各业务线的使用情况。最直接的变化有三处。
销售团队：培训周期缩短近半。新销售入职培训从原来的四周压到了两周半。以前新人熟悉产品靠翻文档和问老同事，现在直接在飞书机器人或企业微信里问知识库，产品功能、竞品对比、常见异议处理，AI结合知识库都能给出带出处的答案。虽然不能完全替代老带新，但日常60%以上的"随手问"问题被知识库接住了，老同事终于能腾出时间处理真正复杂的问题。
技术支持：工单处理效率提升，首次解决率上涨。售后工单里大量的问题是重复的，客服和售后工程师查知识库就能拿到标准处理流程。尤其是报错码和故障场景这类精确匹配问题，混合检索+重排之后的命中率很高。原来"我记得之前遇到过类似问题但是找不到在哪了"的情况，被搜索解决了。
研发团队：架构决策记录终于"活"了。研发侧最开始对知识库最不积极，觉得文档写的就是已经过时的东西。但我们强制要求每个技术决策在评审后48小时内把决策记录（包括背景、选项、取舍理由）入知识库。三个月后，新来的研发问"为什么这里用A方案不用B方案"，知识库能翻出去年四月的决策记录，把当时的评估逻辑完整讲清楚。同期新项目中的重复踩坑数量减少，因为踩过的坑变成了一条可检索的记录。
6.2 没做好的部分：坦白说仍然存在的短板
不吹牛地说，三个月的复盘也暴露了不少还没解决好的问题。
多轮对话一致性。知识库问答在单轮场景下效果还行，但一旦用户连续追问"那如果客户同时要求XXX呢""这个限制条件下还能不能用"，对话上下文和知识库检索的融合容易出偏差。Dify里有一些对话历史处理策略，但我们的配置还不到位，目前在逐步调。
复杂跨文档聚合。如果是"把所有在XX客户项目里用过的非标方案整理一下，按类别列表输出"这种需要跨N篇文档做聚合推断的问题，当前效果只能说勉强及格。原因在于分块粒度、召回数量和生成模型的推理能力都有瓶颈。
非文本类知识。视频、音频、图片格式的知识，我们目前还没有完整接入。有同事提出"会议录像"其实蕴含大量高价值经验，但这个方向的多模态向量化和检索我们还没有精力展开。
知识归属和激励机制。虽然运营小组每周跟进，但让每个一线同事持续、主动地沉淀自己的经验，目前还做不到。大家默认的认知还是"把资料整理好放到知识库是额外工作"，我们还没有在绩效层面找到合适的牵引。
6.3 下一阶段打算：从知识库到AI Agent的路径
最后聊一下海博团队下一步的方向。现在知识库的定位还更多是"问&答问答机"，但我们已经在规划往AI Agent方向走——把知识库从"被动回答问题"变成"主动驱动业务动作"。
具体来说有两个方向：
一是把知识库接入业务Agent的规划。比如售后工单进来时，Agent先去知识库检索类似故障的处理方案，然后自动起草回复内容，再人工审核后发出。这不是简单的"QA问答"，而是将知识库嵌入一条业务流程，让AI真正参与执行链。
二是把知识库沉淀的产品化经验反过来喂给能力建设。我们把文档清洗、分块、权限、重排的策略沉淀成了一套内部"知识库能力模板"，后续新业务接进来，不需要重零开始搭，直接在模板上接入数据源、配置权限和检索策略就行。
AI-Native这个口号，喊出来很容易，但真正落地时你会发现每一层都是具体到枯燥的工作：清洗一份乱糟糟的Word文档、为一个分块参数来回跑测试、为一个权限过滤字段和平台方反复核对接口。但恰恰是这些看似枯燥的工作，决定了AI给你的回答是让人觉得"这AI真懂我们"，还是"这AI就是个花架子"。
海博团队的这套知识库能力，说到底不是什么黑科技，它就是一条把"知识"从碎片变成资产、把"AI"从Demo变成生产力的流水线。希望这篇文章里记录的选型逻辑、调试链路、踩坑过程，能帮同样走在AI-Native落地路上的团队少走几步弯路。
