企业知识库搭建 Playbook

Graphify 核心场景。目标是为客户代码库、文档库和业务知识构建可查询、可演进、可运维的 AI 知识图谱。

场景定义

适用于企业知识管理、代码理解、GraphRAG、内部问答、客户支持知识库和复杂系统 onboarding。

关键前提假设

客户有可访问的代码、文档、PDF、图片、视频或业务系统记录。
存在明确查询场景，例如新人上手、客服问答、代码影响分析、合规检索。
客户愿意指定知识 owner 和内部冠军。
数据权限和脱敏边界可被定义。
项目目标不是“整理知识”，而是支持某个业务决策、操作或工作流。

参考架构

Source Corpus
  -> Graphify 首次构图
  -> graphify-out 三件套
  -> 查询 / 分析 / 可视化
  -> 可选 Neo4j 持久化
  -> 可选 Dify/RAG 入口
  -> Runbook + 内部冠军

标准流程

环境准备
安装 Graphify，确认客户代码库或文档库可在本地或受控环境访问。
首次构图
对目标目录执行 /graphify .，生成 graph.html、GRAPH_REPORT.md、graph.json。
结构分析
使用 graphify query、graphify path、graphify explain 验证关键业务链路。
知识边界清理
标记敏感数据、低质量文档、重复知识、过期资料。
使用场景嵌入
接入新人 onboarding、代码审查、客服知识问答或项目交接流程。
运维交接
使用 05-graphify-operations-runbook 和内部冠军训练完成移交。

Ontology 不是普通知识图谱

参考 01-palantir-case-study：Palantir 报告强调，Ontology 的价值不只是描述实体关系，而是让 AI 理解业务世界如何运作，并在权限约束下驱动行动。

企业 KG/KM 项目要区分三层：

层	目标	常见产物
文档层	让人能读	Markdown、FAQ、SOP
图谱层	让系统能找关系	Graphify graph、Neo4j、entity-relation
操作层	让 Agent 能安全行动	business objects、actions、permissions、audit

如果项目只做到文档层或图谱层，就不能宣称已经具备企业级 AI 操作能力。

操作层门禁

已定义核心业务对象。
已定义对象之间的关键关系。
已定义允许的动作和禁止动作。
已定义每个动作的权限和审批规则。
已定义审计、回滚和人工兜底。

交付物清单

交互式图谱 graph.html。
图谱报告 GRAPH_REPORT.md。
可查询图数据 graph.json。
核心查询示例。
知识源清单。
Graphify 运维 runbook。
内部冠军培训记录。

常见风险与避坑

风险	处理方式
把知识库当文件夹整理项目	先定义查询场景和成功指标
敏感数据进入图谱	首构建前做数据分级和脱敏
图谱一次构建后没人维护	安装 hook 或安排固定重建节奏
用户不知道怎么问	提供 10-20 个高价值查询模板
只做可视化不嵌入流程	与 onboarding、CR、客服或交付流程绑定
把 Ontology 做成静态知识图谱	增加 actions、permissions、audit，进入操作层设计
从已有数据出发找场景	先定义要改善的业务决策，再反推数据和图谱

评估指标

新人理解系统时间。
代码/文档查询成功率。
重复提问减少量。
Code Review 影响分析耗时。
高价值查询模板使用次数。

核心工具

Graphify：多模态知识图谱构建。
Neo4j：可选，持久化图数据库。
Dify/RAG：可选，对话式入口。
Obsidian：团队方法论和人工维护知识。
AIP/Ontology 参考：用 Palantir 案例理解“图谱到行动”的差距。

相关链接