交流群
资料库建设与检索
所有 Skill、MCP、工作流仅供个人学习测试，功能、计费、权限以 workbuddy.cn 官方为准。
本栏目沉淀「资料库建设与检索应用」方向 6 篇可照做的实战方案：从企业知识库整体架构、文档切片与向量化、三种 RAG 检索模式对比，到召回调优、权限隔离与长期维护巡检。文中凡涉及 WorkBuddy 官方产品配置、路径、参数、计费处一律用占位符并标注「待核验（以 workbuddy.cn 官方为准）」；RAG、向量库、切片、检索调优属通用工程方法，可直接复用。
配套资产包括《版本兼容对照表》《资产验收测试标准》《最小可用配套资产包》《FAQ / 全站固定文案》，均在整理中、后续在本站发布。资产上线前请按《资产验收测试标准》验收。
一、WorkBuddy 知识库整体架构设计（企业版落地）
1.1 正文：原理与落地步骤
企业知识库的本质是一条「数据进得来 → 切得对 → 查得到 → 交得准 → 管得住」的链路。按四层架构设计，能让你在 WorkBuddy 企业版落地时，先确定边界、再填产品能力，而不是一上来就建库上传文件。整体分层如下图所示。
四层职责：
L1 数据源层：制度/SOP、产品手册、工单复盘、接口文档等。先盘点有哪些源、归属哪个部门、密级如何，再决定是否接入。
L2 切片与向量化层：清洗 → 分块 → Embedding → 写向量库 → 打元数据标签（部门、密级、有效期）。元数据是后续权限过滤与过期清理的抓手。
L3 检索与重排层：关键词 + 语义两路召回 → 融合 → Rerank 重排 → 阈值截断，只把最相关的片段交给大模型。
L4 应用与权限层：WorkBuddy Agent 调用问答，按人/部门做权限过滤，全程留日志可审计。
企业版落地分步骤：
先做「知识库规划」：列出要建几个库、每个库服务哪类业务问答、谁有权访问。不要一个大库装所有东西。
选数据源与密级分级：公开 / 内部 / 机密三级，机密数据默认不进自动检索库。
确定元数据字段：至少含
source（来源文档）、dept（部门）、security_level（密级）、valid_until（有效期）。在 WorkBuddy 中创建知识库实例（具体入口与命名待核验），把通用能力放在独立库，敏感业务单独建库。
跑通最小闭环：3～5 篇文档 → 切片 → 问 5 个典型问题 → 看召回是否命中，再批量导入。
接入权限与审计：确认 Agent 调用时会按当前用户身份过滤片段，而不是把全库塞给模型。
最小权限原则贯穿全程：知识库账号、向量库连接串、API Key 一律用环境变量或密钥管理服务注入，禁止明文写进文档、Prompt 或配置文件。
1.2 示例
一个最小闭环的输入/输出示例（路径与参数为占位符）：
text
# 输入：一篇制度文档
source: <你的知识库路径>/制度/报销规范_2026.pdf
dept: 财务
security_level: internal
valid_until: 2026-12-31
# 处理：切片 + 向量化（参数占位）
chunk_size: 500 tokens # 待核验，以官方切片能力为准
overlap: 50 tokens
# 提问（用户）
Q: 出差住宿报销标准是多少？
# 期望召回输出（带元数据）
- chunk: "一线城市住宿标准上限 500 元/晚……" score: 0.86 dept:财务
- chunk: "二线城市住宿标准上限 400 元/晚……" score: 0.71 dept:财务
# 仅返回 security_level <= 用户可见密级 的片段1.3 截图脚本（待补）
以下截图均需在真实客户端按清单补拍，当前不提供真实截图：
| 序号 | 页面/位置 | 要展示的动作或元素 | 标注说明 |
|---|---|---|---|
| S1-1 | 知识库列表页 | 展示已建的多个独立知识库（制度库/产品库/工单库） | 待补：需在真实客户端按此清单截图 |
| S1-2 | 新建知识库弹窗 | 名称、描述、权限范围字段 | 待补：需在真实客户端按此清单截图 |
| S1-3 | 元数据/标签配置处 | dept、security_level、valid_until 字段 | 待补：需在真实客户端按此清单截图 |
1.4 配套模板：知识库规划表
适配版本：待核验（以 workbuddy.cn 官方为准）
| 知识库名称 | 服务业务问答 | 主要数据源 | 可见范围 | 密级上限 | 更新频率 |
|---|---|---|---|---|---|
| <制度库> | 报销/考勤/IT 规范 | HR/行政文档 | 全员 | internal | 月度 |
| <产品库> | 产品功能/参数问答 | 产品手册/FAQ | 售前+客服 | internal | 双周 |
| <工单库> | 故障排查参考 | 历史工单/复盘 | 运维组 | confidential | 周度 |
把企业知识搬进 WorkBuddy 别上来就建一个大库——先按业务和密级分库，权限才控得住。想看我是怎么分层搭知识库的，关注我，下篇讲切片参数怎么定。
二、文档分类策略、切片规则、向量化参数选择
2.1 正文：原理与操作步骤
检索质量的天花板，一半在切片。切片切错，后面再怎么调重排都救不回来。核心原则：一个 chunk 只讲一件事，且在语义边界处断开。
分类策略先行：先按文档类型决定切片方式，而不是全库一刀切：
制度/SOP 类：按章节、条款切，保留条款编号，便于精确引用。
FAQ 类：一问一答为一个 chunk，不要把多组问答混进同一块。
长文档/手册类：按标题层级切，优先在小标题处断开。
表格/参数类：整表保留或转成结构化文本，避免把表格行从中间切断。
代码/错误码类：整块保留，关键词检索为主，不要过度切碎。
切片规则通用做法：
先做结构化解析：保留标题层级、列表、表格，不要当纯文本无脑按字数切。
选 chunk 大小：通用知识问答建议 300～800 tokens 起步；过小丢上下文，过大引入噪声。具体可用切片能力待核验。
设置重叠 overlap：相邻 chunk 保留 10%～20% 重叠，避免句子正好被切断。
每个 chunk 附带上下文前缀：如「来源：报销规范_2026 第3条」，提升可追溯性与召回。
向量化参数选择：
Embedding 模型要与业务语言匹配：中文为主就选中文化效果好的通用 Embedding（具体可用模型待核验）。
维度不是越高越好：按向量库实例
<向量库实例>支持的维度建索引，维度与模型输出必须一致，否则写入报错。索引类型按规模选：十万级以内 HNSW 类近似索引通常足够；大规模再评估。具体待核验。
建库时固定模型与维度，后续不要中途换 Embedding 模型——换模型必须全量重建索引。
2.2 示例
text
# 文档 A：FAQ（一问一答为块）
chunk: "Q: 出差住宿标准？ A: 一线 500/晚，二线 400/晚。"
# 优点：召回即命中完整问答
# 文档 B：长手册（按小标题切 + 重叠）
chunk_size: 500 tokens
overlap: 80 tokens
chunk_1: "...第3章 报销流程 [1/2] ..."
chunk_2: "...第3章 报销流程 [2/2] ..." # 与 chunk_1 重叠80 tokens
# 文档 C：错误码（整块保留，不切碎）
chunk: "ERR_502: 网关超时，排查顺序：①上游 ②限流 ③重试队列"
# 以关键词检索为主2.3 截图脚本（待补）
| 序号 | 页面/位置 | 要展示的动作或元素 | 标注说明 |
|---|---|---|---|
| S2-1 | 文档上传/切片设置处 | chunk 大小、重叠参数字段 | 待补：需在真实客户端按此清单截图 |
| S2-2 | 切片预览 | 展示若干 chunk 的实际切分边界 | 待补：需在真实客户端按此清单截图 |
| S2-3 | 向量化/Embedding 配置处 | 模型、维度、索引类型字段 | 待补：需在真实客户端按此清单截图 |
2.4 配套模板：切片参数对照表
适配版本：待核验（以 workbuddy.cn 官方为准）
| 文档类型 | 切分边界 | chunk 参考 | 重叠参考 | 备注 |
|---|---|---|---|---|
| 制度/SOP | 按条款/章节 | 400～600 tok | 10% | 保留条款编号 |
| FAQ | 一问一答 | 整块 | 0 | 不混合多组问答 |
| 长手册 | 小标题处 | 500～800 tok | 10～20% | 带文档名前缀 |
| 表格/参数 | 整表 | 整表保留 | 0 | 勿从行中间切断 |
| 错误码/代码 | 整块 | 整块保留 | 0 | 关键词检索为主 |
RAG 答非所问，八成不是模型笨，是切片切崩了。我把 5 类文档该怎么切整理成了对照表，照着填就行——关注我，少走切片的弯路。
三、RAG 检索模式：关键词检索 / 语义检索 / 混合检索对比
3.1 正文：三种模式原理与选型
检索模式决定了「用户怎么问，系统能不能听懂」。三种模式的核心差异如下矩阵所示，建议对照选型。
三种模式原理（通用）：
关键词检索：基于词项匹配（如 BM25），用户说的词和文档里的词对上就召回。对专有名词、编号、错误码极准，但用户换个说法就漏。
语义检索：把问题和文档都转成向量，算相似度。用户口语化、同义改写也能召回，但容易把「意思像、事实错」的片段排上来。
混合检索：两路各召回一批，再融合（如加权或 RRF 倒数排名融合），兼顾精确词与语义。对真实、表达多样的用户提问最稳。
选型步骤：
先统计你们用户最典型的 20 个真实提问，看是「查编号/术语」多还是「口语化问答」多。
术语/错误码占比高 → 关键词打底；口语问答占比高 → 语义打底。
大多数企业库两者都有 → 直接上混合检索，起步最稳。
WorkBuddy 是否原生提供三种模式、融合算法与可调权重待核验（以官方为准）；若产品仅提供其中部分能力，用其支持的最接近方案。
3.2 示例
text
Q: "连不上网关报了个 5 开头的错"
# 关键词检索：漏召回（用户没说"ERR_502"这个词）
# 语义检索：可能召回"网关"相关但不是 502 的片段
# 混合检索：
# 语义路召回"网关超时"相关片段
# 关键词路命中含"5"开头错误码的片段
# 融合后 Top1 = ERR_502 排查片段3.3 截图脚本（待补）
| 序号 | 页面/位置 | 要展示的动作或元素 | 标注说明 |
|---|---|---|---|
| S3-1 | 检索模式设置处 | 关键词/语义/混合选项 | 待补：需在真实客户端按此清单截图 |
| S3-2 | 同一问题的召回结果对比 | 展示两种模式召回片段差异 | 待补：需在真实客户端按此清单截图 |
3.4 配套模板：检索模式选型表
适配版本：待核验（以 workbuddy.cn 官方为准）
| 你的语料特征 | 推荐模式 | 理由 | 备注 |
|---|---|---|---|
| 错误码、编号、术语密集 | 关键词为主 | 字面精确命中最可靠 | 代码/接口文档 |
| FAQ、口语化问答为主 | 语义为主 | 容忍同义改写 | 客服场景 |
| 混合类型，真实提问表达多样 | 混合检索 | 兼顾精确与语义 | 企业库默认起步 |
用户问"连不上网报了个错"，纯关键词检索根本听不懂——企业知识库默认上混合检索才稳。想看三种模式同题对比，关注我，下一篇讲怎么调召回。
四、检索召回调优：重排、过滤、阈值控制方案
4.1 正文：调优三件套
召回 100 条不等于能用。调优目标是：把真正相关的排到前面，把不相关的在进入大模型前挡掉。三件套：重排、过滤、阈值。
召回（Recall）要宽：先多召回（如 Top 20～50），宁可多召回再筛，不要一开始就卡太死。
重排（Rerank）要准：用重排模型对召回结果二次打分排序，把最相关的顶到前面。重排比单纯靠向量相似度排序准得多。
过滤（Filter）要硬：按元数据先过滤——只看本部门、当前用户密级可见、未过期的 chunk，从源头排除越权与过时内容。
阈值（Threshold）要敢卡：相似度低于阈值的片段直接丢弃，宁可回答「知识库未收录」，也不要硬凑一段不相关内容误导用户。
调优步骤：
建一套 20～50 条的「评测问答集」：每条含问题、标准答案来源文档。调参前后都跑一遍。
先调 Top-K：从 20 开始，看 Top-5 命中率（标准答案文档是否在前 5 位）。
接 Rerank，对比加前后 Top-5 命中率提升。具体是否提供 Rerank 待核验。
设相似度阈值：观察低分段召回片段，把明显不相关的分界线设为阈值。
加元数据过滤：部门/密级/有效期，确认越权片段不会进入上下文。
记录每次参数与命中率变化，形成可回溯的调参表。
4.2 示例
text
# 召回阶段
recall_top_k: 30 # 先宽召回
# 过滤阶段
filter: dept == 用户部门 AND security_level <= 用户密级 AND valid_until >= today
# 重排阶段
rerank: enabled # 二次打分，取 Top 5
# 阈值阶段
score_threshold: 0.55 # 低于此分丢弃
# 结果
context_chunks: Top 3（均 >= 0.55）送入大模型
# 若全部 < 阈值 → 回答"知识库未收录该问题"4.3 截图脚本（待补）
| 序号 | 页面/位置 | 要展示的动作或元素 | 标注说明 |
|---|---|---|---|
| S4-1 | 召回参数设置处 | Top-K、相似度阈值字段 | 待补：需在真实客户端按此清单截图 |
| S4-2 | 重排/过滤开关处 | Rerank 开关、元数据过滤条件 | 待补：需在真实客户端按此清单截图 |
| S4-3 | 单次问答的召回分数列表 | 展示各 chunk 分数与是否过阈值 | 待补：需在真实客户端按此清单截图 |
4.4 配套模板：检索阈值参考表与调参记录
适配版本：待核验（以 workbuddy.cn 官方为准）
| 参数 | 起步参考值 | 调整方向 | 判断依据 |
|---|---|---|---|
| recall Top-K | 20～30 | 漏召回→加大；噪声多→减小 | 评测集 Top-5 命中率 |
| 送入上下文数 | 3～5 | 信息不足→增加；噪声多→减少 | 答案是否引用到正确片段 |
| 相似度阈值 | 0.5～0.6（相对口径） | 硬凑答案→调高；拒答过多→调低 | 低分段召回样本观察 |
| 是否启用 Rerank | 建议开启 | 对比开启前后命中率 | Top-5 命中提升 |
注：阈值绝对值因 Embedding 模型与相似度度量不同而不可直接套用，务必用自己的评测集标定；上述仅为起步方向参考。
RAG 答案越扯越远？不是模型胡编，是没设相似度阈值——低于分的片段宁可拒答也别喂给模型。我把调参记录成了表，关注我照着练。
五、知识库权限隔离、多业务独立知识库方案
5.1 正文：权限与隔离设计
企业知识库最容易踩的坑：所有人共用一个库，导致越权检索或互相污染。正确做法是「物理分库 + 元数据过滤」双层隔离。
物理分库：按业务线/部门建独立知识库，从存储上隔离，互不影响检索与更新。
逻辑过滤：每个 chunk 打 dept / security_level 元数据，检索时按当前用户身份过滤，双重保险。
最小权限：知识库访问账号、向量库连接串、API Key 按库分配，用环境变量或密钥管理服务注入，禁止明文存储；离职/转岗及时回收。
审计：记录「谁、在什么时间、检索了哪个库」，便于事后追溯。
落地步骤：
列出业务线与密级矩阵：哪些业务能被哪些角色看到。
按矩阵建独立库，敏感业务（如财务、客户数据）单独建库、单独授权。
给每库配置访问账号，遵循最小权限：只授该业务需要的库。
在检索链路上确认：Agent 用当前用户身份检索，而非用一个全量管理员 key 拉全库。
定期（如季度）复核权限清单，回收过期授权。
敏感数据规避：入库前过滤掉身份证号、银行卡号、合同金额等敏感字段；这类内容本就不应进入自动检索库。WorkBuddy 具体权限模型与授权入口待核验。
5.2 示例
text
# 库 1：制度库（全员可见）
visibility: all_staff
key: <KB_PUBLIC_KEY> # 环境变量注入，禁止明文
# 库 2：客户资料库（仅销售组）
visibility: sales_dept
key: <KB_CRM_KEY> # 仅销售服务账号持有
filter: dept == "sales"
# 库 3：财务库（仅财务组，含敏感数据须脱敏后入库）
visibility: finance_dept
note: 合同金额/银行卡号已脱敏，不入库
# 检索时：按当前用户身份选库 + 过滤，而非一把 key 拉全库5.3 截图脚本（待补）
| 序号 | 页面/位置 | 要展示的动作或元素 | 标注说明 |
|---|---|---|---|
| S5-1 | 知识库权限设置处 | 可见范围/成员授权 | 待补：需在真实客户端按此清单截图 |
| S5-2 | 多库列表与各自授权 | 制度库/客户库/财务库不同可见范围 | 待补：需在真实客户端按此清单截图 |
| S5-3 | 检索日志/审计处 | 谁在何时查了哪个库 | 待补：需在真实客户端按此清单截图 |
5.4 配套模板：权限矩阵模板
适配版本：待核验（以 workbuddy.cn 官方为准）
| 知识库 \ 角色 | 全员 | 销售组 | 财务组 | 运维组 | 数据脱敏要求 |
|---|---|---|---|---|---|
| <制度库> | 可读 | 可读 | 可读 | 可读 | 无需 |
| <客户资料库> | 不可见 | 可读 | 不可见 | 不可见 | 联系方式脱敏 |
| <财务库> | 不可见 | 不可见 | 可读 | 不可见 | 金额/账号脱敏 |
| <工单库> | 不可见 | 不可见 | 不可见 | 可读 | 无需 |
企业知识库千万别一个大库装所有部门——按业务分库、按人过滤，越权检索才挡得住。权限矩阵我做成表了，关注我直接抄。
六、知识库维护方案：增量更新、过期清理、质量巡检
6.1 正文：长期维护三件事
知识库不是建完就完事。不维护的库会逐渐「过期、污染、召回质量下降」。三件事要常态化：
增量更新：文档变更后只重新切片/向量化变更部分，不要每次全量重建。用文档版本或更新时间戳做增量判断。
过期清理：靠 valid_until 元数据，到期文档自动降权或下线；已废止的制度不删记录但标记为「已废止」，避免 Agent 引用过期规则。
质量巡检：定期跑评测问答集，看命中率是否随时间下降；抽检召回片段是否准确、是否越权、是否含敏感信息。
维护节奏建议（通用）：
文档变更触发增量更新：源文档更新 → 重新切片对应 chunk → 更新向量，保留来源映射。
每月跑一次过期清理：扫描 valid_until 到期文档，下线或归档。
每季度跑一次质量巡检：用评测问答集复测 Top-5 命中率，对比基线。
每季度做一次权限复核与敏感数据抽检。
所有维护动作留记录：谁更新、清理了哪些、巡检结果如何。
注意：换 Embedding 模型或大改切片规则时必须全量重建索引，并重新跑评测，不能只做增量。是否支持自动增量重建待核验。
6.2 示例
text
# 增量更新：源文档 v2 替换 v1
doc_id: reimbursement_2026
change: 仅"住宿标准"条款更新
action: 仅重新切片该条款 chunk，更新向量，不重建全库
# 过期清理
valid_until: 2026-06-30 已过
action: 标记 status=deprecated，检索时降权/排除
# 巡检记录
date: 2026-Q4
eval_set: 30 条问答
top5_hit: 0.82（基线 0.85）
conclusion: 略降，抽检发现 2 篇过期文档未下线 → 已清理6.3 截图脚本（待补）
| 序号 | 页面/位置 | 要展示的动作或元素 | 标注说明 |
|---|---|---|---|
| S6-1 | 文档更新/重新索引处 | 单文档增量更新入口 | 待补：需在真实客户端按此清单截图 |
| S6-2 | 过期/归档文档列表 | valid_until 到期文档状态 | 待补：需在真实客户端按此清单截图 |
| S6-3 | 巡检/评测记录处 | 命中率复测结果 | 待补：需在真实客户端按此清单截图 |
6.4 配套模板：知识库质量巡检清单
适配版本：待核验（以 workbuddy.cn 官方为准）
| 序号 | 巡检项 | 检查方法 | 频率 | 不通过处理 |
|---|---|---|---|---|
| 1 | 过期文档是否下线 | 扫描 valid_until 到期 | 每月 | 归档/降权 |
| 2 | Top-5 命中率是否达标 | 跑评测问答集 | 每季度 | 排查切片/参数 |
| 3 | 是否有越权召回 | 用低权限账号抽检 | 每季度 | 修复过滤条件 |
| 4 | 是否含敏感字段 | 抽检召回片段 | 每季度 | 脱敏/移出 |
| 5 | 权限授权是否过期 | 核对权限矩阵 | 每季度 | 回收授权 |
| 6 | 密钥是否仍明文存储 | 检查配置/文档 | 每季度 | 迁入密钥管理 |
知识库建完只是开始——不做过期清理和巡检，半年后 Agent 就开始拿作废制度回答人。巡检清单我列好了，关注我按季度打勾就行。
本栏目 6 篇正文完结。所有依赖 WorkBuddy 官方产品细节处均以占位符标注并提示「待核验（以 workbuddy.cn 官方为准）」；RAG/切片/检索调优为通用工程方法，可直接在你的环境中复用。
（注：部分内容由豆包工作 AI 生成）