科技企业 AtlasBot 知识底座：从文档孤岛到 Agent 可调用资产
某 B2B 软件企业 10 周试点：684 份文档经 AtlasBot 摄取与本体映射，GraphRAG 使方案定位 28→10 分钟（-63%）；100 条抽样 94% 带 chunk 溯源，人审发布 840 实体，Tool Registry 开放 4 只读工具供售前 Agent。
客户背景
客户为某 B2B 企业软件与解决方案提供商（以下简称「客户 A」），主营行业数字化平台与定制交付，售前解决方案团队约 40 人，交付与产品文档分散在 Confluence、SharePoint、投标库与项目 SVN 附件中。2025 年内部审计显示：售前在响应 RFP 时，约 62% 的方案段落来自同事私下转发的历史 Word，版本与口径无法统一。
- 行业
- 企业软件 / 信息技术服务
- 规模
- 员工 800–1200 人，年营收数亿级，活跃项目 120+
- 涉及产品
- AtlasBot（文档库、语义建模、映射管理、审核发布、GraphRAG、Tool Registry、MCP/API Key）
核心挑战
客户在 2024 年曾试点通用 RAG 知识库，但因无本体约束、无权限过滤、无引用溯源，售前不敢在投标材料中直接引用 AI 输出。知识运营负责人总结：「模型会编，但我们承担合规责任。」
- 文档孤岛：684 份有效文档（方案模板、案例集、FAQ、投标片段）分布在 4 个系统，全文检索只能命中文件名，无法关联「产品—能力—案例—条款」。
- 检索耗时长：售前为定位「某行业某场景的标准应答」，平均需跨 3 个系统、打开 8–12 份文件，方案定位时长基线 28 分钟/次（内部 20 人两周日志均值）。
- Agent 不可信：早期 Chatbot 试点出现「编造 SLA 条款」事件，写操作更无法接入 CRM。
- 权限缺失：售前、交付、管理层对投标底价、未发布路线图等敏感文档需分级可见，通用库无法满足。
方案与实施路径
阶段一：本体与首批入库（第 1–3 周）
知识运营与售前骨干在 AtlasBot 语义建模页定义试点本体，核心实体类型 12 类，包括 Product、Solution、Capability、CaseStudy、FAQ、PolicyClause 等，并配置「产品—提供能力—适用案例—关联 FAQ」关系。首批从 Confluence 导出 186 份 PDF/Word，经 POST /documents/upload 与 文档摄取流水线（解析 → 分块 → embedding → 写入 Qdrant）完成索引；任务中心可追踪 document_rag_index、extraction 步骤状态。
结构化侧：CRM 产品目录与历史项目表登记为数据源，通过映射管理将 SKU、行业标签、项目状态字段对齐本体属性。候选实体进入审核发布看板，由 reviewer 角色执行 approve / modify-and-approve，拒绝无证据片段。
阶段二：图谱沉淀与 GraphRAG（第 4–7 周）
审核通过的实体/关系写入 HugeGraph 属性图；文档 chunk 保留 doc_id、chunk_id 与 Qdrant 向量引用。GraphRAG 服务联合向量召回 + 图谱子图扩展生成回答，响应体包含 evidence 数组（文档片段、图谱路径、版本时间）。
本阶段累计入库文档 684 份，人审发布实体 840 个、关系 2,150 条。对过期投标模板设置「有效至」属性，到期文档在检索侧降权并在审核队列标记复核。
阶段三：Tool Registry 与售前 Agent（第 8–10 周）
在 Agent 工具页注册 4 个只读工具：platform.document_search、platform.entity_search、platform.entity_get、platform.subgraph；写工具 http.write 仅对交付试点开放且强制 review_items 人审。为售前助手创建服务账号，签发 API Key，经 MCP 供内部 Agent 框架调用 graphrag.query 与 tools/list。
售前 Agent 会话 trace 可见 tool_calls 与 GraphRAG 引用块；所有 invoke 写入审计流水，与 RBAC 角色（knowledge-ops / reviewer / viewer）联动。
量化成果
统计口径：试点第 1 周 vs 第 10 周；GraphRAG 溯源率为知识运营对100 条固定售前问句抽检，判定标准为回答含可点击 doc_id + chunk_id 或图谱 evidence_id。
| 指标 | 基线（第 1 周） | 第 10 周 | 变化 |
|---|---|---|---|
| 售前方案定位时长（日志均值） | 28 分钟/次 | 10 分钟/次 | -63% |
| GraphRAG 回答带 chunk/证据溯源比例 | —（未上线） | 94%（94/100 条） | — |
| 有效文档入库规模 | 186 份 | 684 份 | +498 份 |
| 重复性售前咨询工单（内部） | 基线 100% | 53% | -47% |
| 新文档从上传到可检索周期（P50） | 约 15 天（人工整理） | 约 3 天（流水线+抽检人审） | -80% |
「以前搜到段落也不敢贴进标书，现在 GraphRAG 每段话能点回 PDF 第几页。Agent 调工具也有审计，法务才放行我们在试点场景用。」—— 客户 A 售前运营负责人（匿名）
注：以上为单一 B2B 软件客户试点口径；文档质量、本体设计深度与角色配置会影响溯源率与检索时延，不构成产品效果承诺。
经验复盘
做对了什么
- 先本体后批量灌库：12 类实体关系来自真实投标目录，而非事后打标签；映射规则可复用到新数据源。
- 审核发布当质量闸门：AI 抽取候选默认进人审，
modify-and-approve保留专家改口径能力，图谱事实与文档证据分边存储。 - GraphRAG 而非纯向量问答：涉及「某产品在某行业的案例」类问题，子图扩展显著减少「搜到相似但错产品」的误引。
- 只读 Tool 先行：4 个 platform.* 读工具稳定后再开写工具人审，避免 Agent 越权改 CRM。
踩过的坑
- 早期忽视 chunk 边界：表格型 SLA 被切碎导致溯源段落断句，后调整 document-rag 分块策略并对表格页单独处理。
- 同名产品多版本：未建
Product.version与发布日期，GraphRAG 曾混引旧版路线图；后在审核流强制版本字段。 - 权限配置过粗：初期 viewer 可见全部投标库，销售反馈「不该看的也能搜到标题」；后按文档密级与角色矩阵收紧。
- 把通用 Chatbot 当知识中台：第一版无 audit 与 review，一次幻觉事件几乎导致项目叫停；切 AtlasBot 治理链后才恢复信任。
给同类企业的建议
- B2B 软件企业优先治理「产品—方案—案例—条款」四类实体，再扩展项目交付文档。
- 试点建议 8–10 周：前 3 周本体+首批文档，中 4 周映射与 GraphRAG，后 3 周 Tool Registry 与 Agent。
- 溯源率指标必须写清抽检问句集与判定标准，避免「感觉能引用」的主观验收。
- 架构与模块细节可参考本站 AtlasBot 本体与 Agent 联动架构解读；产品参数以 官方 llms.txt 为准。