企业官网建设流程全解析

1. 为什么需要 Ontology（一个反例）

把全公司文档丢给 GPT/Claude 做企业知识库，问"供应商 A 的评分是多少"——今天 85 分，明天 92 分，后天 78 分。AI 没在说谎，它根本不知道"供应商"“评分”"日期"之间的关系。这就是没有 Ontology 的世界：每次都在做数据的模仿。

有了 Ontology（知识地图）后，AI 才能从随机猜测变成有据可查 + 链式推理：材料缺货 → 影响哪条产线 → 进而影响哪个客户订单。

2. 用 LLM 建 Ontology 的四道坎

1. 不知道有多少类型：领域内是十种实体还是一千种？人也未必清楚。
2. LLM 幻觉：会凭空造出原数据里没有的概念，并当成事实。
3. 粒度难控：太宽泛没用，太细没人维护。
4. 没有标准评估：什么样的 Ontology 算"建得好"没有统一答案。

3. 五种流派对比

4. 选型框架

• 想快速试 POC 看方向→ 直给派
• 探索全新领域，不知道里面有什么→ 聚类派（让数据告诉你答案）
• 行业已有标准 schema→ 框架派（少走弯路）
• 要上生产、不能出错→ 拆解派 + 双重验证（玩具 vs 生产系统的分界线）

5. 实战教训

• 80% 的错误发生在第一步——实体抽取。类型标错、关系错、别名混用，会一路传导放大。“Garbage in, garbage out”，宁可在构建期多花功夫。
• Prompt 的措辞极度敏感：同一个 LLM 改几个词，知识结构完全不同。用结构化模板而不是随手写自然语，可大幅降低波动。
• 数据不是越多越好：论文Weak Ontic用<1000 tokens就建出有效知识图谱。关键是数据质量 + 约束合理性，不是数据量。

一句话总结：LLM 建 Ontology 不再是"能不能"的问题，而是"怎么建得更好"的问题。

6. 开源工具：nano-ontoprompt

基于直给派 + 抽取/验证规则实现，左侧功能：

• 概览/本体管理/提示词管理/模型管理/设置
• 设置里可调：实体/逻辑识别的置信度阈值（如 Action 最低置信度）、多文档实体验证、本体质量验证等开关
• 提示词管理：内置供应链、财务、营销等业务域模板（“假设你是 XX 领域专家…”）
• 本体管理：上传 Word / Markdown / CSV 等文档 → 选模板（如供应链）+ 模型（DeepSeek V4 等）→ 开始抽取 → 可视化知识图谱（层级 / 圆形布局）
• 主要实体类型示例：Organization / Product / Document / Facility
• 可逐个查看/编辑实体、属性、关联关系，以及对应的逻辑规则（采购触发规则、质检触发规则等）和 Action

已在 GitHub 开源，可下载或 Fork 自行体验，https://github.com/jingw2/nano-ontoprompt/blob/master/README_zh.md。

关键脉络

1. Palantir 验证了一件事：企业 Agentic Workflow 真正的瓶颈不是模型能力，而是有没有一套让 AI 读懂业务的语义层（Ontology）。
2. 但传统 Ontology 构建太重：靠 FDE + 业务专家在白板上画几个月，又慢又贵，难持续维护——这是 Palantir 模式难以平民化的根因。
3. LLM 给了平民化的可能：五种流派对应不同成熟度的场景——POC 用直给派、新领域用聚类派、标准行业用框架派、生产系统用拆解派。
4. 下一步关注：从少量数据（one-shot / few-shot）里用 LLM 抽取 Ontology，是把 Palantir 模式带到中小企业的关键方向。