内部知识库检索
主要面向：系统集成商
很多组织的知识是「有，但找不到」：规范在共享盘里，手册是 PDF，经验在老员工脑子里。新人查一件事要翻半天，或者干脆去问人。
知识库检索型 Agent 解决的就是这个问题——不是产生新知识，而是让已有的知识可被检索。
落地时真正决定效果的三件事
第一是文档能不能进得来。 实际场景里的资料格式很杂：doc、docx、ppt、pdf、markdown、txt，有时还有 epub。能覆盖的格式越多，前期整理的人工成本越低。
第二是切块策略。 这是最被低估的一环。同样一批文档，切块方式不同，检索命中率差别很大。一份按章节组织的规范，和一份问答形式的 FAQ，合适的切法完全不同。能不能自己调切块策略，是判断一个方案能不能落到实处的关键指标。
第三是嵌入模型的选择。 中文场景下，不同嵌入模型的表现差异明显，尤其是在专业术语密集的领域。能不能换、怎么换，同样影响最终效果。
数据边界必须先讲清楚
这个场景经常伴随一句需求：「数据不能出去」。这句话要拆开看：
- 用本地部署的开源模型，数据全程留在内网——这才是真正的「不出内网」
- 用在线大模型，提问和检索到的知识片段必然要发送给模型厂商，数据一定会出网；能选择的是合规厂商、传输方式和脱敏处理，而不是「不出网」
这两条是互斥的物理事实。任何笼统承诺「数据不出内网」却不区分部署形态的说法，都值得追问一句用的是什么模型。
我们三种部署形态都支持：客户内网物理机、客户自有云或运营商云、我们托管的云。选哪种取决于数据敏感度和预算，方案页里写了具体怎么权衡。
对系统集成商的意义
如果你本来就在给甲方做集成项目，知识库检索是最容易加进去的一块 AI 能力：它不改变原有系统的业务流程，是叠加上去的独立模块，交付边界清晰，验收标准也好定。
相关内容（14）
扣子知识库搭建：上传只是第一步，能被检索到才算数
文档传进去了，问起来却答非所问。这篇讲知识库该怎么组织、按需调用意味着什么、以及上传前该做哪些处理。
Dify 本地部署前要想清楚的六件事
官方文档告诉你怎么装，但没告诉你装之前该定什么。硬件怎么估、数据边界在哪、版本怎么选、升级怎么办——这些定错了，装好也白装。
Dify 用 Docker 部署时镜像拉不下来：成因与四种解法
国内网络拉镜像卡住、超时、拉一半断——这不是 Dify 的问题，是镜像源的问题。这篇讲清成因、四种解法各自的代价，以及给客户部署时该怎么办。
Dify 知识库的 embedding 模型怎么选：中文场景下这一步比换主模型有用
检索不准时大家都想换更强的对话模型，但真正决定「能不能找到」的是 embedding 模型。这篇讲它的作用、中文场景的坑，以及换模型的代价。
Dify 和扣子怎么选：三个问题就能定
不用比功能清单。数据能不能出网、要不要交付给客户、团队有没有运维能力——这三个问题答完，答案基本就出来了。
用 FastGPT 的 API 接进自己的系统：四种接法和各自的代价
把知识库问答嵌进已有产品，接法不止一种。前端直连、后端代理、事件驱动、只借检索——四种方式的适用场景、风险和改造成本完全不同。
FastGPT 部署与交付：集成商视角的六个决定
FastGPT 的许可明确允许交付给企业，这让它在集成项目里很实用。但从装起来到能验收，中间还有六个决定要做。
FastGPT 部署要多少硬件：三个变量决定，别照抄配置表
网上的配置推荐大多没说前提。真正决定硬件规模的是三件事：跑不跑本地模型、多少人用、知识库多大。这篇讲怎么估、怎么验证、怎么给客户报。
知识库权限：不同人该看到不同答案，这件事必须在系统层解决
全公司共用一个知识库，销售能查到人事的工资表——这不是配置疏忽，是架构没设计。这篇讲三种隔离方式和各自的适用场景。
知识库优化的正确顺序：先改文档，最后才动参数
大部分人的优化顺序是反的——一上来就调参数、换模型，却从没看过系统实际读到了什么。这篇给出按收益排序的五步。
RAG 到底是怎么工作的：搞懂这个流程，八成的问题你自己就能定位
不讲论文，讲工程。检索增强生成的四个环节各自在干什么、各自会怎么失败、以及为什么「换个更强的模型」通常没用。
甲方说「要私有化部署」时，他到底要什么：三种含义与报价差异
这四个字在不同甲方嘴里至少有三种意思，成本能差好几倍。这篇给出问清楚的方法、三种方案的实际差异，以及方案里必须写明的那句话。
知识库项目七成工作量在文档，不在系统
扫描件、表格、过期文档、口口相传的经验——这些才是知识库项目真正的成本。这篇讲文档摸底该看什么、怎么估工作量、哪些坑要写进合同。
Dify 知识库检索不准怎么排查：从切块到重排的五个环节
上传了文档，问出来的答案却答非所问。这篇按检索链路逐环节拆，讲清每一步会在哪出问题、怎么验证，以及哪些问题调参数解决不了。