简介《Coze知识库使用手册》聚焦 Coze 知识库在企业级大模型应用中的落地方法适合已具备一定 AI 基础、希望借助本地知识库提升问答准确性的技术人员或企业用户。手册系统讲解知识库核心能力说明文本与表格两种类型的适用场景覆盖本地文档、在线网页、飞书文档、Excel 等多种导入方式并对分段规则、检索召回策略、索引设置做了展开说明帮助降低大模型幻觉、补充专业领域知识。同时结合客服、虚拟形象、垂直行业查询等典型场景清晰对比知识库与记忆功能的差异给出创建、配置、调试优化的完整使用流程。资源为单个 PDF 文档大小 4.16MB结构完整便于查阅目前已有 531 人学习使用。1. 先用 30 秒说清楚Coze 知识库到底解决什么问题你搭了一个 Coze 智能体人设写得很细可一问到具体产品参数、内部流程、活动规则它就开始一本正经地编答案。这不是模型不行是它没有“可查的资料”。Coze 知识库就是干这个的你把文档、表格、网页链接喂进去系统切片、向量化、建索引问答时先召回相关内容再让模型生成相当于给智能体配了一个可检索的专用资料库。常见做法是往里面放产品手册、FAQ、内部制度、公众号文章这些静态内容让智能体的回答从“自由发挥”变成“有据可依”。这个手册适合两类人一类是刚接触 Coze 的新手照着步骤把第一个知识库建起来摸清分段、召回、引用这些概念到底在调什么另一类是已经在用但效果不稳定的老手很多“答非所问”不是模型问题而是切片和召回参数没配对。下面从建库开始讲一直到工作流接入和排错每一步都给参数、给边界、给踩坑记录。2. 建库到跑通第一次问答从空库到可用只差四个动作很多人一上来就纠结“知识库”“工作流”“插件”之间的关系其实没必要。先建一个最简知识库跑通一次“提问-召回-回答”的闭环后面所有复杂设计都建立在这个基础上。2.1 三种知识库类型先搞清楚你的资料是“文”还是“表”进入 Coze 控制台创建知识库时会让你选类型。一般摄影产品是三种文本类型、表格类型、自定义类型。这一步选错后面全白做。文本类型处理的是非结构化内容——产品说明书、公众号文章、Markdown 笔记、PDF、Word、网页链接。系统把文字切成片段向量化存储问答时用语义匹配。这是最常用的类型你可以把“RAG 知识库”理解成这个知识库的代表范式里RAG 和 KG知识图谱经常被拿来对比但 Coze 里的文本库就是典型的 RAGKG 那种实体关系建图思路在这类场景里用得少如果你要回答“谁和谁之间什么关系”这类多跳问题才需要另想方案。表格类型处理的是结构化数据——产品报价、订单状态、物料清单这类二维表。它有专门的行列格式要求传上去之后按行做索引适合“这个 SKU 多少钱”“这个客户是什么等级”这类精确查询。下面用表格做个对比方便你选型类型适合内容检索逻辑典型场景文本PDF、Word、Markdown、URL分段向量化语义匹配制度问答、产品答疑、资料查阅表格CSV、Excel 类二维数据行列精确匹配参数查询、报价查询、状态查询自定义外部数据库或 API 数据调用接口实时取数订单状态、实时库存、会员信息自定义类型一般用来对接外部业务系统属于“动态数据走接口、静态文档走文本”的设计思路新手先不碰。2.2 建库最小动作上传文件到跑通第一次检索选文本类型名称写个能认出来的比如“客服知识库-202501”然后进入数据源配置。添加数据源时有几个入口本地文件、在线数据、Notion、飞书云文档。本地文件支持 PDF、Word、Markdown、TXT 这些常见格式在线数据就是填一个网页 URL系统帮你抓页面内容飞书和 Notion 走授权导入。我一般习惯先用本地文件验证格式可控排错简单。上传文件后系统会做切片处理。第一次建库的人直接选“自动分段”就行它会按文档结构自动划分段落。分段完成后进入索引状态这个阶段是异步的文件多的时候要等一会儿。# 这一步没有命令行操作完全在控制台可视化完成 # 核心动作就三个 # 1. 选择数据源并上传 / 填入 URL # 2. 等待切片与索引完成 # 3. 知识库状态变为“可用”索引完成后回到“项目”里新建一个机器人在“人设与回复逻辑”里加一句“回答优先依据知识库内容”然后在“知识库”区域点击添加关联刚才创建的库。这一步是把知识库挂到智能体上的关键操作漏了这一步你在对话框里怎么问它都不会去查库。2.3 首次验证在对话里看召回而不是看生成很多人测试知识库只盯着最终回答看这是最大的误区。回答是“召回 生成”两步的结果模型可能把召回内容改写得很流畅但关键信息早丢了。正确做法是看右边的“知识召回”或“引用”面板里面列了这次问答实际用到了哪些片段。第一次验证可以带点“陷阱”去问比如文档里明确写了“仅限内部使用”你问“这个文档能对外发吗”看召回片段里有没有包含这半句再比如文档里有两个相近型号的参数你问其中一个型号的功耗看召回的是不是准确的那一段。建议在对话里用一条命令式提示词固定验证节奏请只依据知识库内容回答我的问题。 在回答末尾列出你参考的知识库片段来源。 如果知识库没有相关内容直接说“知识库中未找到”。这样做有两个好处一是让模型不要用自己的常识补全二是你能直观看到每个回答到底引了哪些片段判断是不是从正确位置召回的。如果引用面板里出现了不相关内容别急着改提示词先去看分段和召回参数下一章重点讲这两个环节的调法。3. 切片与召回参数决定问答质量的两个关键开关知识库从“能用”到“好用”差距几乎全在分段和召回这两个环节。这两个参数调好回答准确率会有明显提升调不好就是“明明文档里有它就是答不对”的翻车现场。3.1 切片分段先让上下文完整再谈命中率自动分段可以跑通流程但追求效果时必须理解分段的逻辑。分段长度和重叠是两个直接作用于命中质量的值。最大分段长度控制每个片段含多少 token。设得太小一个完整意思被拆成两截语义残缺设得太大片段里掺入大量无关信息向量化后的特征被稀释匹配精度反而下降。中文章节我一般先按 500 左右起步再根据文档结构做微调。分段重叠解决的是“恰好落在切口上”的问题。两个片段各 400 token内容在第 380–420 之间垮掉了重叠机制可以让相邻片段共享一段文字切口附近的信息不至于彻底丢失。重叠设成最大分段长度的 10%–20% 是比较稳的区间。分隔符优先级上我常用的配置是“换行优先、段落次之、句子保底”。也就是说系统先按空行\n\n切如果一个段落太长再在句子边界处断开。这个层级关系直接决定切出来的片段是结构完整的一整段还是被腰斩的一句话。分段配置参考 最大分段长度 500按需在 300–800 之间调 分段重叠 50约 10% 分段标识符 换行 / 段落 / 句子按优先级递进这里要特别强调一个反直觉的点文档里的小标题不要刻意删掉。“第 3 章 故障排查”这种标题虽然短但它是一个高区分度的语义锚点向量化后对片段主题有很强的标识作用。把标题和正文切成同一段比单纯切正文效果更好因为模型能通过标题快速定位“这段在讲什么”。3.2 召回参数数量、阈值和知识库引用场景召回数量控制每次问答最多取多少片段。默认值一般在一个保守区间但对复杂文档往往不够。设得太少模型可参考的信息不足设得太多无关内容混入回答开始跑偏。我一般建议从“刚好能覆盖一个完整知识点”开始试普通制度类文档设 5–8 条参数手册类设 8–12 条再根据引用面板里的实际质量收敛。相似度阈值是过滤片段的门槛。调高了召回结果会更精确但容易漏调低了召回变多但混杂噪声。最直观的判断方式是验证阶段把阈值放低先让系统多召回看哪些片段是有用的再逐步调高把无关内容挡在外面。“引用场景”这个配置容易被忽略它影响召回后内容如何拼进提示词。一个常见误区是选“仅引用片段”后模型失去了组织语言的自由度选“全自动”又可能让模型过度发挥。如果你只需要“参考知识库内容回答”保持默认即可但如果你做的是“提取参数并计算”这类任务建议显式配置引用格式让模型先列出依据再给出结论。{ 知识库引用配置: { 召回数量: 8, 相似度阈值: 0.5, 引用场景: 引用相关文本并回答, 引用模板: 基于以下资料回答\\n{{knowledge}} } }代码说明这个 JSON 结构是知识库在智能体侧引用配置的通用映射。召回数量和相似度阈值是最直接影响结果的两个值引用模板里的 knowledge 变量代表召回片段列表把它放在提示词的前置位置模型生成时会优先参考。3.3 向量检索、全文检索、混合检索三种方式怎么选Coze 知识库的召回路径不是单一一种。向量检索擅长语义匹配——用户说“这玩意儿电池耐用吗”能匹配到文档里“续航时间 8 小时”这段哪怕字面不重叠全文检索是字面匹配——用户搜“BIOS 设置”就只找包含“BIOS 设置”的片段。混合检索把两者结合再通过重排模型排序效果最稳但耗时和 token 开销也更高。不同场景的选型参考检索方式优势短板适用场景向量检索能识别同义表达专有名词、缩写易失配口语化提问、售后问答全文检索精准命中专业术语无法处理同义改写产品型号、错误码、命令查询混合检索 重排两者兼得延迟略高、token 消耗更大文档量大、问题类型杂的生产环境一个实际判断标准如果你的问答场景里频繁出现“用什么词问都能对上”向量检索足够如果经常要精确查型号、报错代码务必考虑全文检索或混合检索。生产环境我一般直接配混合检索省得在两种模式间反复横跳。RAG 知识库能不能存图片这类问题也在这里一并回答文本知识库上传的文档里如果只有图片没有文字系统提取不到任何内容图片必须转成文字说明或 OCR 文本后再喂进去。4. 把知识库接进工作流从对话引用升级到智能路由知识库挂在智能体上只能做“统一召回”。当文档量大、业务线多、问题类型杂时就需要工作流来承担路由和分发。这也是 Coze 工作流搭建里最常见的用法不是为知识库建一个复杂流程而是给它加一层调度逻辑。4.1 知识库节点进工作流Query 变量与召回配置在项目里新建工作流左侧节点列表里找到知识库节点。节点需要一个输入变量一般命名为 query这就是用户问题到达节点时的入口。配置节点时同样要设定召回数量和阈值覆盖智能体侧的默认值——这意味着你可以按节点维度精细化控制而不是全库统一一套参数。{ node: knowledge_retrieval, input: { query: {{user_query}}, retrieval_count: 6, threshold: 0.45, knowledge_base: kb_product_faq } }参数说明query 接上游传入的用户问题retrieval_count 设为 6对产品 FAQ 这类问题一般够用threshold 降到 0.45 是故意为之让召回面大一点把判断交给下游模型而不是在前面就把可能有用的内容过滤掉。knowledge_base 指定具体知识库 ID保证路由明确。工作流的价值在于“先判断再召回”前面接一个意图识别节点或大模型节点判断用户问的是价格问题、故障问题还是售后政策然后按分支去不同的知识库节点。这比把所有文档塞进一个大知识库里让系统“大海捞针”要可靠得多。4.2 多知识库路由按问题类型分区召回一个大而全的知识库有两个硬伤一是不同类型的文档互相干扰产品参数和促销政策揉在一起相似度计算被噪声拉偏二是更新麻烦运营改了一次价格你不得不把整库重建。多知识库加路由就是解决这两个问题的。做法是按业务域切库建一个“产品参数库”、一个“售后政策库”、一个“活动规则库”维护时各改各的互不牵连。路由节点则根据用户问题的关键词或语义分类决定走哪个库。意图分类规则写在工作流前置的大模型节点提示词中 - 包含“价格、优惠、活动、折扣”等词 - activity_kb - 包含“保修、退换、维修、售后”等词 - aftersales_kb - 包含型号、参数、规格词汇或默认分支 - product_kb工作流跑通后把它关联到智能体上在智能体的“工作流”区域选择该流程并启用。这里有个容易踩的坑智能体既关联了知识库又关联了工作流系统可能会同时触发两套机制回答时两边的上下文互相干扰。解决方法是明确人设指令——“优先调用工作流不要直接查询知识库”让交互链路收口到工作流上。4.3 自动更新让知识库跟上业务变化知识库最大的隐性成本是“内容过期”。文档更新后没有同步重新索引智能体给的答案还是三个月前的版本这种情境特别容易让用户失去信任。文本库的数据源如果是 URL 类型控制台通常提供定期更新能力。配置一个更新频率系统会周期性重新抓取页面内容并刷新索引。本地文件上传的库则建议每次换文件后点“重新索引”不要只覆盖上传——旧片段可能还留在索引里造成重复召回。# 自动更新的常见配置思路以控制台可视化操作为主 # 1. 数据源选“在线数据”填入网页 URL # 2. 更新周期选“每天”或“每周” # 3. 打开“更新后自动索引”确保抓取完立刻同步 # 4. 观察最近一次“更新状态”失败时手动触发一次重试对本地文件我的习惯是文件名带版本号比如“客服FAQ_v3.7z”更新后立刻做一次抽检问答确认新内容已经生效。如果库特别大索引不是实时的刚更新完立刻问可能还会命中旧片段等几分钟再验证。5. 知识库避坑指南五个最常见的“不是模型问题”的翻车现场知识库做久了会发现大多数智力低下的表现都不是模型笨而是数据链路某个环节出了问题。下面五条是高频场景按“现象-原因-解决”的思路写清楚。5.1 图文混排文档里的图片和表格“消失”了现象上传一份带产品示意图和技术参数表的 PDF一问关于图中标注的内容智能体答不上来参数表的数字也经常说错。原因文本知识库的提取链路只处理文字层。图片不会自动 OCR表格如果被存成图片格式也提取不到结构化文本即使表格是真文本切片后行列关系也可能被打乱模型只看到碎片化数字。解决图片内容先转成文字说明放到正文里或用 OCR 工具生成文本再上传表格优先另存为 CSV 用表格知识库承载别混在文本库里。如果必须用一份 PDF确保文件里表格是真文字且每个单元格内容完整“知识库图片怎么处理”这个问题就按这个思路解决。5.2 在线数据抓回来是空的或乱码现象URL 添加成功但问答时说“知识库中未找到”或者召回的内容是页面导航、广告文案正文一句没抓到。原因这类页面大多是前端动态渲染的初始请求返回的 HTML 里没有实质内容有的站点限制了爬取频次或需要登录态。抓回来的可能只是页面框架。解决优先选取静态 HTML 页面做数据源动态渲染页面手动导出为 Markdown 或 PDF 再上传定期检查“更新状态”一次抓取失败不会影响老索引但连续失败说明该 URL 不可靠。我遇到频率比较高的链接来源是公众号文章这种情况下我会把文章复制到本地存成 Markdown 再传比依赖 URL 抓取稳定得多。5.3 相似度阈值调高后“什么都答不了”调低后又乱答现象阈值设到 0.7 以上很多问题直接召回不到内容降到 0.3召回了一堆不相关内容回答里经常串信息。原因阈值不是“精确度开关”它和文档切片质量、检索方式强相关。文本向量化的特征分布在不同语料上差异很大系统给定的参考阈值只能作为起点不能作为结论。解决先用低阈值跑通观察引用面板里“正确内容”和“噪声内容”的相似度分界再把阈值设到两者之间。如果这个分界不明显说明切片长度或分隔符配得不合理先回头调分段再动阈值。5.4 更新知识库后答案还是旧的现象上传了新版本文档并显示索引成功但提问后引用的还是旧片段。原因索引完成不代表旧索引被清理。部分更新模式下旧片段仍留在向量索引中新片段只是追加进去召回时新老混杂本地文件覆盖上传时有时删除标记还没同步。解决优先选择“删除并重建”方式更新而不是覆盖更新后用一个“只有新文档才有的内容”做验证比如新版本新增的条款明确提问它确认需要能命中新片段。如果新旧内容同时在引用面板里出现用版本号在文档标题中做区分再设置知识库的召回过滤条件。5.5 多个相似文档之间“串味”现象知识库里有两份相似文档比如不同批次的活动规则回答时经常把 A 活动的规则套到 B 活动上。原因语义相似度过高向量检索无法有效区分模型又倾向于融合上下文作答。解决在文档开头显式写清“本规则仅适用于 X 活动Y 活动规则见另一文档”配置引用场景时让模型“先判断问题属于哪个活动再只引用对应片段”必要时用工作流前置分类节点做硬路由。这类问题的根源是“数据边界不清”靠调阈值解决不了要从源头立边界。6. 用质检集把知识库“养”起来一套可持续的验证方法知识库上线只是开始真正考验功夫的是后续迭代。这里分享我一直在用的一套方法给知识库建一个质检集用固定的问题集做回归每次改完参数都跑一遍用结果说话而不是凭感觉。建质检集的原则是“宁少勿滥每题必须能定位到唯一知识点”。起步 15–20 题足够覆盖高频问题、易混淆问题和边界情况比如“知识库没写的内容”。问题预期知识点实际召回片段结论X 型号的质保期是多久质保条款第 2.1 节命中质保条款通过Y 套餐包含哪些服务服务清单命中服务清单但混入 Z 套餐内容待调阈值这个活动能叠加新客券吗活动规则说明未召回知识库中无该内容需要补文档模型产出的回答会变但召回质量是稳定的。所以我把质检重点放在“召回是否命中正确片段”而不是“回答是否满意”——回答可以被提示词优化但召回命中错了提示词再怎么调也拉不回来。落地上我有一个土办法把质检集固化成一份 Markdown每次改完参数后花十分钟跑一遍记录失败项再做针对性调整。不要同时调多个参数一次只动一个否则你永远不知道是哪个改动让效果变好了。这套方法坚持一段时间后知识库会给你一种“越用越懂你”的感觉其实只是你越来越懂它的脾气。希望帮到你。本文还有配套的精品资源点击获取