Stop Chasing the Perfect Ontology停止追逐完美的本体论
Start with a fixed, generic base and extend only when your data demands it.从一个固定的通用基础开始，只有当你的数据需要时才进行扩展。
For a while now I’ve been trying to build a proper memory layer on top of my research, writing, and content creation. Today it all lives in my Second Brain in Obsidian, where the primitives are files like notes, videos, and articles.一段时间以来，我一直在尝试在我的研究、写作和内容创作之上构建一个合适的记忆层。如今，这一切都存在于我在Obsidian中的第二大脑中，其中的基本元素是笔记、视频和文章等文件。
What I actually want is to shift those primitives from files to entities and relationships, such as people, locations, objects, topics, preferences, and facts. I want the memory to get closer to reality so I can watch how things evolve over time. I want a knowledge graph.我真正想要的是将这些基本元素从文件转变为实体和关系，例如人物、地点、物体、主题、偏好和事实。我希望记忆更接近现实，这样我就能观察事物如何随时间演变。我想要一个知识图谱。
Everyone agrees knowledge graphs and GraphRAG provide a more performant substrate for a unified agent memory layer than plain RAG. But kicking one off is far harder. The resistance always collapses to the same wall: how you model your data. Your ontology is the hardest part of the system.所有人都同意，知识图谱和GraphRAG为统一的智能体记忆层提供了比普通RAG更高效的底层支持。但启动一个知识图谱要困难得多。阻力总是归结于同一个障碍：你如何建模你的数据。你的本体论是整个系统中最难的部分。
If you can’t define your ontology properly for your domain, the graph won’t represent the reality you want. The right entities and relationships simply aren’t there. As a result, GraphRAG ends up performing worse than the simple RAG you were trying to beat.如果你无法为你的领域正确定义本体，图就无法表示你想要的现实。正确的实体和关系根本不存在。结果，GraphRAG 的表现甚至比你想超越的简单 RAG 还要差。
This translates straight to a memory layer. There’s no dodging it. Even if you stay file-only (a “virtual knowledge graph,” like an LLM knowledge base over your notes), you still hit the same data-modelling question: which primitives, and which entities, do you even extract?这直接转化为一个记忆层。这是无法回避的。即使你只使用文件（一个“虚拟知识图谱”，比如基于笔记的 LLM 知识库），你仍然会遇到同样的数据建模问题：你到底提取哪些原语和实体？
The instinctive reaction is to design the perfect, complete ontology upfront. That’s exactly the trap that freezes the project.本能的反应是预先设计一个完美、完整的本体。这正是让项目陷入僵局的陷阱。
The strategy is a not-overkill ontology. You need something flexible enough to kick off with almost no friction before you really know your domain, extending it with domain-specific detail as you explore your data.策略是采用一个不过度的本体。你需要一个足够灵活的东西，在真正了解你的领域之前几乎无摩擦地启动，并在探索数据时用领域特定的细节扩展它。
Concretely, you use a small, fixed, generic, but extendable noun data model, known as POLE+O. Plus two core primitives, Preferences and Facts, for everything that doesn’t fit into the nouns.具体来说，你使用一个小的、固定的、通用的但可扩展的名词数据模型，称为 POLE+O。再加上两个核心原语，偏好和事实，用于所有不适合名词的内容。
You ship something that works, then add subtypes as a lightweight data-exploration step shows you where the generic types clash with your real data.你先交付一个可用的东西，然后通过轻量级的数据探索步骤添加子类型，该步骤会显示通用类型与真实数据冲突的地方。
This approach lets you stand up a knowledge-graph memory layer for your own assistant without burning weeks on schema design. To build this, we first need to understand what an ontology actually is and why targeted models beat exhaustive ones.这种方法让你无需花费数周时间设计模式，就能为自己的助手建立一个知识图谱记忆层。要构建这个，我们首先需要理解本体到底是什么，以及为什么有针对性的模型优于详尽的模型。
Start Your Transition Into AI Engineering (Product)开始你的 AI 工程（产品）转型之旅
This article showed how to design the ontology your knowledge-graph memory needs. My Agentic AI Engineering course shows the harness around it. I just released a free preview to build and run a working agent in 5 minutes.本文展示了如何设计知识图谱记忆所需的本体。我的Agentic AI工程课程展示了围绕它的框架。我刚刚发布了一个免费预览，可以在5分钟内构建并运行一个可工作的智能体。
You build a multi-agent system with two MCP servers (Research Agent + Writing Workflow), a deep research algorithm, an evaluator-optimizer loop, observability, and LLM-as-judge evals. Patterns required to ship AI.你构建一个包含两个MCP服务器（研究智能体+写作工作流）、深度研究算法、评估器-优化器循环、可观测性和LLM作为评判评估的多智能体系统。这些是交付AI所需的模式。
Built for software, data engineers or scientists transitioning into AI engineering.专为转型进入AI工程的软件、数据工程师或科学家设计。
7 free lessons, 2 MCP agents ready for your GitHub portfolio. Part of our 35-lesson course. Rated 5/5 by 300+ students.7节免费课程，2个MCP智能体可用于你的GitHub作品集。属于我们35节课程的一部分。300多名学生评分5/5。
What Is an Ontology?什么是本体？
An ontology is the formal answer to 1 question. When you read the world, what do you write down as nodes, and what do you draw as edges? It specifies the kinds of things that exist in your domain, their properties, and how they relate to each other.本体是对一个问题的正式回答。当你阅读世界时，你写下什么作为节点，画什么作为边？它指定了你的领域中存在的事物的种类、它们的属性以及它们之间的关系。
The ontology’s job is to map a targeted slice of the real world into the digital world. A good ontology is highly targeted to the problem you actually want to solve. If you over-model, you drown in noise and never ship. Plus, it get’s extremely expensive to extract and maintain the knoweldge graph. If you under-target, the graph doesn’t reflect the reality you care about.本体的工作是将现实世界的目标切片映射到数字世界。一个好的本体高度针对你实际想要解决的问题。如果过度建模，你会淹没在噪音中，永远无法交付。而且，提取和维护知识图谱会变得极其昂贵。如果目标不足，图谱就无法反映你关心的现实。
Look at concrete, shipped ontologies for real-world proof. The create-context-graph domain catalog made by Neo4j publishes 22 ready-made domain ontologies. Every single one lands at exactly 10 to 12 entity types. They use a shared 5-noun base plus only 5 to 7 domain-specific nouns.看看具体的、已交付的本体以获得现实世界的证明。Neo4j发布的create-context-graph领域目录包含22个现成的领域本体。每一个都恰好有10到12种实体类型。它们使用一个共享的5个名词基础，加上只有5到7个领域特定的名词。
For example, the Personal Knowledge domain models the world as Note, Contact, Project, Topic, Bookmark, and JournalEntry. The Agent Memory uses Agent, Conversation, Memory, ToolCall, and Session. The lesson here is that real ontologies are small on purpose. They capture only the entities required to answer the questions the system is designed for.例如，个人知识领域将世界建模为笔记、联系人、项目、主题、书签和日记条目。智能体记忆使用智能体、对话、记忆、工具调用和会话。这里的教训是，真正的本体是有意小的。它们只捕获回答系统设计要解决的问题所需的实体。
So if targeted and small is the goal, why does everyone — me included — reach for big and perfect first? That’s the trap.那么，如果目标明确且规模小是目标，为什么每个人——包括我在内——首先追求大而完美？这就是陷阱。
The Overkill Trap: Why My Knowledge Graphs Never Shipped过度设计陷阱：为什么我的知识图谱从未上线
When I first encountered the ontology concept, I assumed I had to study my domain in depth. I thought I needed to model all of finance, for example, and design the ideal ontology before working with any real data. You can’t actually do that before you have a system running and data to look at. You just pile up assumptions that mostly turn out wrong.当我第一次接触本体概念时，我以为必须深入研究我的领域。例如，我认为需要建模整个金融领域，并在处理任何真实数据之前设计理想的本体。但实际上，在系统运行并拥有数据之前，你无法做到这一点。你只会堆积大量最终被证明错误的假设。
I got frozen. Every knowledge-graph solution I started stayed on my laptop and never got used, because I was waiting on an ideal ontology I could never reach. Without understanding the ontology, I couldn’t even write a decent extraction step to populate it. I was deadlocked, bringing 0 value.我陷入了僵局。我启动的每个知识图谱解决方案都停留在笔记本电脑上，从未被使用，因为我一直在等待一个永远无法达到的理想本体。不理解本体，我甚至无法编写一个像样的抽取步骤来填充它。我陷入了死锁，带来了零价值。
The breakthrough was realizing I need a couple of models that let me start generic and extend over time. As I get more data, analyze it, and actually understand my problem, the schema evolves. Let’s meet the base model that lets you start in 5 minutes instead of 5 weeks.突破在于意识到我需要几个模型，让我可以从通用开始，并随时间扩展。随着我获得更多数据、分析数据并真正理解问题，模式会演变。让我们认识一下基础模型，它让你在5分钟内开始，而不是5周。
The POLE+O Data ModelPOLE+O数据模型
POLE+O is a tiny, fixed, top-level vocabulary that can classify almost anything you pull out of text. It stands for Person, Object, Location, Event, and Organization [2]. It originated in law-enforcement and intelligence analysis. The Organization type was added for general-purpose entity extraction. The point of a fixed base is queryability. There are always exactly 5 base nouns to filter on, so the graph stays answerable no matter how it grows underneath.POLE+O是一个微小的、固定的顶层词汇表，可以对从文本中提取的几乎任何内容进行分类。它代表人物、对象、地点、事件和组织[2]。它起源于执法和情报分析。组织类型是为通用实体抽取而添加的。固定基础的意义在于可查询性。始终有恰好5个基础名词可供筛选，因此无论图在底层如何增长，它都能保持可回答性。
Person covers people, aliases, and personas. Object covers physical or digital things. Location covers places, addresses, and regions. Event covers meetings, transactions, and incidents. Organization covers companies, teams, and institutions. Two or three of these catch the overwhelming majority of what a personal assistant needs.人物涵盖人、别名和角色。对象涵盖物理或数字事物。地点涵盖场所、地址和区域。事件涵盖会议、交易和事故。组织涵盖公司、团队和机构。其中两到三个就能覆盖个人助手所需的绝大多数内容。
Here are POLE+O’s five base types and the default subtypes each one ships with:以下是POLE+O的五种基础类型以及每种类型默认包含的子类型：
Here’s the beauty of this approach. You extend the base nouns with your own subtypes, and that’s how you tailor a generic ontology to your specific domain. It works exactly like object-oriented programming. You start from base classes you adopt without thinking. Then you subclass into specifics as your use case clarifies.这就是这种方法的美妙之处。你可以用自己的子类型扩展基础名词，从而将通用本体定制到你的特定领域。它就像面向对象编程一样工作。你从无需思考即可采用的基础类开始。然后，随着用例的明确，你将其子类化为具体内容。
You can kick off with nothing extended and add concrete types only as you understand your data better. Neo4j’s agent-memory library uses precisely this approach. POLE+O is its default, swappable ontology.你可以从什么都不扩展开始，只在更了解数据时添加具体类型。Neo4j的agent-memory库正是采用这种方法。POLE+O是其默认且可替换的本体。
The data-exploration workflow runs in a simple loop. First, kick off with generic POLE+O. Second, run an exploration extraction over your real data. Forget production reliability. You only care about understanding what’s there. Third, inspect the graph for clashes where the generic model lies about your data. Fourth, add or rename subtypes to fix each clash. Finally, repeat the process. You won’t get it perfect, and that’s the point. You iterate like any other AI app instead of freezing.数据探索工作流在一个简单循环中运行。首先，从通用的POLE+O开始。其次，对真实数据进行探索性提取。暂时不考虑生产可靠性。你只关心了解那里有什么。第三，检查图中是否存在通用模型对数据误判的冲突。第四，添加或重命名子类型以修复每个冲突。最后，重复该过程。你不会做到完美，而这正是关键。你像其他AI应用一样迭代，而不是冻结。
Look at named examples from real extraction runs. Claude Code comes back tagged as a Person when it’s clearly an Object. The “AI Engineer” conference lands as an Event when you wanted an Organization. DeepSeek is tagged a Person, not an Object.看看真实提取运行中的命名示例。Claude Code被标记为Person，而它显然是Object。“AI Engineer”会议被标记为Event，而你本想要Organization。DeepSeek被标记为Person，而不是Object。
Portugal and New York both get a flat Location label even though one’s a country and one’s a city. An agentic harness shows up as a generic Object when, for knowledge work, you’d rather have a Topic type. Each clash is a signal to add 1 subtype, not to redesign the whole schema.葡萄牙和纽约都被标记为普通的Location，尽管一个是国家，一个是城市。一个代理工具被标记为通用Object，而在知识工作中，你更希望有Topic类型。每个冲突都是添加1个子类型的信号，而不是重新设计整个模式。
POLE+O nouns and their subtypes cover the things in your world. But to fill in the gaps there are two specials tricks we have to go over.POLE+O名词及其子类型覆盖了你世界中的事物。但为了填补空白，我们还需要介绍两个特殊技巧。
Preferences: The Things a Noun Likes偏好：名词喜欢的事物
Preferences are the second family of entities you attach to the graph. They are things a noun likes or dislikes. A Preference is a characteristic of an entity. It represents a stance. The canonical case is a person who likes, prefers, or dislikes something.偏好是附加到图上的第二类实体。它们是名词喜欢或不喜欢的事物。偏好是实体的一个特征。它代表一种立场。典型情况是喜欢、偏好或不喜欢某物的人。
Concretely, a Preference entity looks like this:具体来说，偏好实体看起来像这样：
category groups the preference, preference is the statement itself, and context optionally records when or where it applies. confidence runs from 0 to 1. The embedding makes it semantically searchable.category对偏好进行分组，preference是陈述本身，context可选地记录其适用时间或地点。confidence范围从0到1。嵌入使其可语义搜索。
Make it concrete. “Loves Italian food”, “prefers dark mode”, and “dislikes long meetings” are clear examples. Each is a stable stance the assistant should remember and adapt to.具体化。“喜欢意大利菜”、“偏好深色模式”和“不喜欢长会议”是清晰的例子。每个都是助手应记住并适应的稳定立场。
By default, a Preference hangs off the Person. That’s the most common and useful case. You can extend preferences to other objects, like an Organization’s policies, a car’s settings, or an Event’s dress code.默认情况下，偏好依附于个人。这是最常见且最有用的情形。你可以将偏好扩展到其他对象，比如组织的政策、汽车的设置或活动的着装要求。
Because I’m building a personal assistant, I start by attaching Preferences only to the Person. This keeps the graph clean, low-noise, and small. I’ll extend it later only when a concrete use case demands it.因为我正在构建一个个人助手，所以我只将偏好附加到个人上。这保持了图的简洁、低噪声和小规模。只有当具体用例需要时，我才会扩展它。
Preferences are the personalization layer. They act as the memory of the user’s stances. They are the “sweet sauce” that makes every future response feel tailored.偏好是个性化层。它们充当用户立场的记忆。它们是让每个未来响应都显得量身定制的“秘制酱料”。
There is one issue. Plenty of useful knowledge is just an atomic fact. Forcing all of that into the ontology is how graphs explode in complexity. The fix is a deliberately generic primitive.有一个问题。大量有用的知识只是原子事实。将所有内容强行塞入本体是图复杂度爆炸的原因。解决方案是一个故意设计的通用原语。
Facts: The Trick You Haven’t Thought Of事实：你没想到的技巧
The Facts entity is the fallback for everything that doesn’t cleanly fit a noun or a Preference. You drop the claim into a generic Fact. This is the move that keeps the ontology small and stops you from over-thinking the schema.事实实体是所有无法干净地归入名词或偏好的内容的备选方案。你将声明放入一个通用事实中。这一举措保持了本体的简洁，并阻止你过度思考模式。
A Fact is the closest thing to a classic-RAG chunk. An LLM produces each Fact during extraction. Each Fact holds a single, atomic concept which works like a charm via semantic search.事实是最接近经典RAG块的东西。LLM在提取过程中生成每个事实。每个事实包含一个原子概念，通过语义搜索效果极佳。
The beauty is that with facts you avoid the usual chunking errors, such as splits mid-thought, mixed concepts, and arbitrary boundaries. In reality, a Fact is a triplet. A subject, predicate, and object like “Eiffel Tower / is / 330m tall” gets embedded and stored as 1 granular unit.美妙之处在于，使用事实可以避免常见的分块错误，例如思维中断、概念混合和任意边界。实际上，事实是一个三元组。主语、谓语和宾语，如“埃菲尔铁塔 / 是 / 330米高”，被嵌入并存储为一个粒度单元。
Here is the shape of a Fact entity:以下是事实实体的形状：
The triplet — subject, predicate, object — is the whole fact. valid_from and valid_until give it optional bi-temporal validity. The embedding, computed over the concatenated triplet, is what makes the fact retrievable by semantic search.三元组——主语、谓语、宾语——构成了整个事实。valid_from和valid_until提供了可选的双时态有效性。嵌入基于连接的三元组计算，使事实可通过语义搜索检索。
It’s confusing that we have a triplet stored as a node. But this is what it makes it flexible. We don’t worry about modeling these one-off triplets directly into the ontology, but the LLM extracts them as-is from the text.令人困惑的是，我们将三元组存储为节点。但这正是它灵活的原因。我们不必担心将这些一次性三元组直接建模到本体中，而是由LLM从文本中按原样提取。
Facts are usually wired to nothing. They have no relationships to other entities. They are retrieved only via semantic search and text search. A Fact stays in the graph but is independent of it. This works because a graph store runs vector search and graph traversal in the same query engine [4]. Which means facts are retrieved only via semantic/text search.事实通常不连接任何东西。它们与其他实体没有关系。仅通过语义搜索和文本搜索检索。事实存在于图中，但独立于图。这之所以有效，是因为图存储在同一查询引擎中运行向量搜索和图遍历[4]。这意味着事实仅通过语义/文本搜索检索。
Facts let you ship a memory layer before you have the perfect ontology. Anything you can’t yet model degrades gracefully into a searchable atomic node instead of blocking the build. Early on, you lean on Facts. As the graph matures, claims migrate toward typed entities and edges. It costs nothing to schema and nothing to maintain when entities merge or get deleted.事实让你在拥有完美本体之前就能部署记忆层。任何你尚无法建模的内容都会优雅地降级为可搜索的原子节点，而不是阻碍构建。早期，你依赖事实。随着图的成熟，声明会迁移到类型化实体和边。当实体合并或删除时，无需模式成本，也无需维护成本。
What’s Next下一步是什么
The takeaway is the posture. An ontology is a living artifact you bootstrap from a fixed generic base and grow through a data-exploration loop, exactly like any other AI application.关键在于姿态。本体论是一个活的工件，你从一个固定的通用基础启动它，并通过数据探索循环来增长，就像任何其他AI应用一样。
If you want to see the whole strategy implemented, the fastest path is to play with Neo4j’s agent-memory SDK or its MCP server. It uses POLE+O as a swappable default, subtypes as cheap extensions, and Preferences and Facts as first-class primitives. Studying it is what made all of this finally click for me.如果你想看到整个策略的实现，最快的途径是尝试Neo4j的agent-memory SDK或它的MCP服务器。它使用POLE+O作为可替换的默认值，子类型作为廉价的扩展，并将偏好和事实作为一等公民的原语。研究它让我终于理解了这一切。
I’m actively migrating my own Obsidian Second Brain toward the POLE+O, Preferences, and Facts primitives. This turns thousands of files into a graph I can actually traverse, visualize, and watch evolve over time.我正在积极地将自己的Obsidian第二大脑迁移到POLE+O、偏好和事实原语上。这将数千个文件变成一个我可以实际遍历、可视化并观察其随时间演变的图。
But here is what I’m wondering:但我想知道的是：
If you worked with Knowledge Graphs, what was your process in discovering your own ontology?如果你使用过知识图谱，你在发现自己的本体论时经历了怎样的过程？
Click the button below and tell me. I read every response.点击下面的按钮告诉我。我会阅读每一条回复。
Enjoyed the article? The most sincere compliment is to restack this for your readers.喜欢这篇文章？最真诚的赞美就是为你的读者重新整理这篇文章。
Whenever you’re ready, here is how I can help you当你准备好了，以下是我能帮助你的方式
If you want to go from zero to shipping production-grade AI agents, check out my Agentic AI Engineering course, built with Towards AI.如果你想从零开始到交付生产级AI代理，请查看我与Towards AI共同构建的Agentic AI Engineering课程。
35 lessons. Three end-to-end portfolio projects. A certificate. And a Discord community with direct access to industry experts and me.35节课。三个端到端作品集项目。一张证书。以及一个可以直接接触行业专家和我的Discord社区。
Built for software, data engineers or scientists transitioning into AI engineering.
Rated 5/5 by 300+ students. The first 7 lessons are free:300多名学生评分5/5。前7节课免费：
Not ready to commit? Start with our free Agentic AI Engineering Guide, a 6-day email course on the mistakes that silently break AI agents in production.还没准备好投入？从我们的免费Agentic AI Engineering指南开始，这是一个为期6天的电子邮件课程，内容涉及在生产中悄然破坏AI代理的错误。
References参考文献
Create Context Graph. (n.d.). Domain Catalog. create-context-graph. https://create-context-graph.dev/docs/reference/domain-catalogCreate Context Graph. (n.d.). Domain Catalog. create-context-graph. https://create-context-graph.dev/docs/reference/domain-catalog
Neo4j Labs. (n.d.). POLE+O Data Model. Neo4j Agent Memory. https://neo4j.com/labs/agent-memory/explanation/poleo-model/Neo4j Labs. (n.d.). POLE+O Data Model. Neo4j Agent Memory. https://neo4j.com/labs/agent-memory/explanation/poleo-model/
Neo4j Labs. (n.d.). Neo4j Agent Memory. GitHub. https://github.com/neo4j-labs/agent-memoryNeo4j Labs. (n.d.). Neo4j Agent Memory. GitHub. https://github.com/neo4j-labs/agent-memory
Neo4j Labs. (n.d.). Why Neo4j? Graph-Native Memory Architecture. Neo4j Agent Memory. https://neo4j.com/labs/agent-memory/explanation/graph-architecture/Neo4j Labs. (n.d.). Why Neo4j? Graph-Native Memory Architecture. Neo4j Agent Memory. https://neo4j.com/labs/agent-memory/explanation/graph-architecture/
Images图片
If not otherwise stated, all images are created by the author.除非另有说明，所有图片均由作者创作。
Really fascinating article. Im also working my way into understanding how to create a real world, practical ontology. In my case I struggle with a normalized data mindset but this is a whole different game, we have to be able to tolerate ambiguity first and then let patterns emerge. Kind of like the stages of data pipeline architecture.
Ontologies are useless but ontologizing is essential