Apple 个人知识图谱：连"谁是你妈"都是算出来的

2022 年起（macOS 13），每一台 Mac 都带着两个守护进程，它们活着的唯一目的就是建一张图：你是谁、你认识谁、这些人和你以及彼此是什么关系、你怎么和他们联系、你去哪、和谁、做什么、什么时候。

这张图在设备本地建，靠交叉比对机器上几乎所有东西：通讯录、日历、照片、信息、邮件、位置、屏幕使用时间，以及一长串行为信号。更重要的是，它被保存成一个可查询的存储，供大模型检索（据称如此）。

听起来像阴谋论，但它确实在发生，而且关于这套机制在你的 Mac 上怎么运作，公开文档少得可怜。最接近官方描述的只有 man page（man 8 knowledgeconstructiond），得到的全部内容就是：

NAME knowledgeconstructiond —— 一个分析设备内容、建立通用知识图谱的守护进程。

DESCRIPTION knowledgeconstructiond 分析本设备上的内容，帮助建立一张代表设备与用户的知识图谱。它与 intelligenceplatformd 协作，承担一部分重计算任务，生成这张知识图谱。

——macOS 26.6.2，build 25G83

先前的工作：公平地说，Apple 自己的研究员 2023 年确实发表过一篇讲解这张图构建技术的论文。但关于它如何整合进 macOS——哪些版本在跑、到底收集和推断了什么——几乎没有内容。至于下文要讨论的"亲属关系"推断，一个字都没有。

我们是在 2026 年 8 月对 macOS 26 的 Apple Intelligence 包做安全研究时碰到它的；而几个月前，Nic Lydon 也发现了同一个数据库，写了《I Built a Personal Knowledge Graph. Apple Had Already Built One on My Laptop》。更近的一次是取证工具找到了手机上：2026 年 9 月，Alexis Brignoni 教会 iLEAPP 读取 iOS 上的同一个存储，graph.db 与用来解码谓词代码的 ontology.db 位于 /private/var/mobile/Library/IntelligencePlatform，他写成了《Reading the iPhone Knowledge Graph, and Checking Its Work》。

我们想再往深处走一点。

这篇是对"知识图谱到底在干什么"的一次分析记录，目的是让你对这套机制的运作方式有更好的理解，也清楚这张图究竟握有关于你、你的家人和朋友的什么。全部内容采集于 macOS 26（写作时为 26.6.2）。

为此我们开源了一个本地看板 iKnow，你可以在自己的 Mac 上读取个人知识图谱的内容。

最后我们会稍微跑题，做我们最擅长的事：武器化与利用。我们做了一个思想实验（适用于任何这类个性化系统），说明这样一个知识库落到错的人手里会发生什么，以及一个"隐私单点故障"怎么能被拿来威胁你——用一些你之前没想过的方式（与一个被解除对齐限制的模型结合时）。

一、个人知识图谱里有什么

两个守护进程把工作成果放在 ~/Library/IntelligencePlatform，里面有 51 个 SQLite 数据库。它们是明文存储的，只是所在区域受 TCC 完全磁盘访问权限保护。

最有意思的应该是 graph.db。它是一个三元组存储，词表包含 181 类实体和 278 个谓词：每一行都是一个主语、一个谓词和一个宾语。主语是实体（一个人、一个应用、一个事件）；宾语要么是一个普通值（名字、账号、日期），要么是另一个实体——后者正是这张图"边"的来源。谓词是最有意思的部分：它说明系统认为两者之间是哪种关系。

拿一条边举例（合成数据）：一个"人"和库认为他是其雇主的"组织"。PS500 是 predicate.json 给"雇主"的 id，但它的取值范围不是组织，而是一个关系类型——所以一条边实际是共享同一个 relationshipId 的两行：一行说明关系种类，一行指向另一个实体。

同一时刻，这两行还各自带着置信度、来源、来源重复项与时间戳。下表那 46 个"关系类型"类别的存在，正是为了让每条边自己带上置信度、并在以后能被撤回。

两个守护进程做的大部分事情，就是把操作系统允许它读的一切灌进这些谓词和旁边的表。进图的有：通讯录；照片（人脸）；日历（标题与参与者）；家人共享（包括每个成员的年龄）；健康里医疗急救卡上的紧急联系人；Siri 建议在邮件和信息里找到的事件与联系人；应用通过 App Intents 捐献的人；以及已安装的应用。

在它们旁边的独立表里，还躺着：你在照片里和谁一起出现；通信日志（谁、什么时候、哪个应用、什么方向；没有内容），它也会从你的其他设备拉数据；位置与移动；以及一长串设备信号（锁屏、Wi-Fi、蓝牙、充电、环境光，还有一个叫 ContextualUnderstanding.PhysicalSocial 的流，其记录格式按姓名、电话和邮箱列出人物，每人带起止时间——读起来像是"谁在你身边"的日志，尽管我们从没见过它被填上）。

二、推断出了什么

下图是全部 181 个实体类别（id 与标签是 Apple 的，分组是我们的）：

这张表把出厂本体声明的每一个类别都列了出来，按组排列而不是按文件顺序：先是核心类型，然后是人、属性、地点与事件，接着是活动区块，最后是 46 个关系类型——它们根本不是"东西"，每一个都是一条边的具象化，好让这条边能带上自己的侧面信息，其中就包括置信度。intValue 从 1 到 185，缺了四个数字——18、54、169、181——而磁盘上没有任何东西说明它们原来是什么。

181 个里有 57 个描述的是一种活动：睡觉、锻炼、正念、就寝、通勤、就餐……它们大多还有一个配套的"类型"类别，所以将近三分之一的词表花在"你在做什么"上，而不是"你是谁、在哪"。话说回来，并不清楚每个类别都真的被用到；有些可能只是声明了、从未填充的占位符。表里标"已实现"的，是我们能定位到一个可能负责该类别机制的；这些应当当作推断工作，而不是事实基准。

下面是全部 278 个谓词（同样的免责声明适用）：

这是出厂本体声明的每一个谓词。第一列是 graph.db 里存储的 id；最后一列说明值是怎么来的：从某个来源拷贝、从另一条记录关联、由一条规则派生、Apple 作为世界知识预置，或由一个模型产出（用粗体的是模型）。有 7 个我们没能确认，表里写明"未确认"而不是猜。id 与标签是 Apple 的，白话解释是我们的。

三、怎么推断出来的

手法跨度很大。词表的大部分靠直接拷贝填充（通讯录里的名字、日历里的参与者），以及在这些拷贝上跑规则；有意思的行来自模型：一对 XGBoost 分类器根据 144 个（大多是行为的）特征判断谁算家人；两个向量模型是系统用来判断"两条记录是不是同一个人"的十个信号之一；照片里 12 个分析器根据谁和你一起出现在照片里、在哪些旅行和节日里，给伴侣、父母、子女、同事、朋友打分；而 Apple 的端侧大模型会读你的信息，给一张脸配上名字和关系（前提是 Apple Intelligence 是开启的）。

无论用哪种方法，每一行落地时都附带一个置信度：0 到 1 之间的数。

亲属分数另存一处。两个 CoreML 模型随本体一起出厂：EntityTagging_Family.mlmodelc 与 EntityTagging_FamilyAndFriends.mlmodelc——二元 XGBoost 分类器，吃 144 个特征，输出一个类别和它上面的概率。它们的分数不进三元组存储，而是进自己的一张表（entityTagging.db，每人一行、17 个关系列，从"家人"到"母亲"到"同事"，每天重算），也就是下文 iKnow 记分卡读的那张。这 17 列里只有两列背后有出厂模型；剩下 15 列靠什么填、以及这些概率怎么变成图里的置信度，我们没能追出来。

特征名就在每个模型的 metadata.json 里，明文。 这是我在任何地方见过的、对这套系统最清晰的说明。全部 144 个：

这是 EntityTagging_Family.mlmodelc 读入的全部输入，按它 metadata.json 声明的顺序。EntityTagging_FamilyAndFriends 以同样顺序读同样这 144 个，每一个都是数字。分组沿用了 schema 自己的三段：20 个关于"这个人是谁"，40 个关于"你在什么时候、以什么方式和他通信"，84 个关于"你们一起出现在哪些照片里"。这 20 个里有两个（photosPersonAge、photosAgeDifferenceCategory）也是从照片读的。名字是 Apple 的，分组标签是我们的。

身份组是那个干净的故事：同姓、同一个家庭住址、一个 iCloud 家人标记——而它是小的一半。模型的主体是另外两组：你给谁发消息、谁出现在你的照片里，以星期几和一天中的时段为条件，然后以两者同时为条件。photosPersonPosteriorProbabilityGivenSaturdayNight 是一个出厂分类器里的出厂特征名，而这个分类器的工作就是判断某人是不是你的家人。

删掉某个东西，不等于到处都删掉。

活着的图会遗忘。删掉一个联系人，没有任何东西重新推导他；下一次运行整表替换。

但库在活表旁边还留了第二张表 expired_stable_graph。被撤回的行搬过去，保留它的置信度与来源。它在那儿留多久，我们从能看到的部分还不清楚。看起来大约 48 小时后消失（库维护一个剪枝水位，近期的一份表快照最早也只到那里）；但在我自己的 Mac 上，我还能读到非常旧的记录。

而且一个结论可以活得比它的证据更久。 在我这台 Mac 上，记分卡仍然给两个前一天已被图丢弃的人打了分，而这两个人只来自一次日历邀请。好吧，如果你不想让伴侣发现你删过某些联系人、以及他们的"亲密度"，最好也把 expired_stable_graph 里的行删掉（可惜只能手动）。不过我相信你没什么好藏的（开个玩笑）。

四、看看你自己的数据

这些敏感吗？我们留给你判断，"敏感"对不同人意味着不同的事（不过我觉得这里可选的挺多）。但关键在于：它没有一样是孤立存在的。它被造出来就是为了被关联、被交叉比对；节点放在那里就是为了被连起来。

下图里的每个节点都是库里的一行，连线是库自己给出的关系：一条实线可能是"共同参加的一次日历事件"、"一条雇佣陈述"、"由存储的群组命名"，虚线则是"一条没人手动录入、由亲密度分数算出来的关系"。

点一个节点，图下面就是这个人在库里存着的记录（是行本身，不是摘要）。那 61 个淡色的节点是最出人意料的部分：库知道、但还没安置好的人——他们之所以在里面，只因为给你写过一次消息，或者出现在别人的邀请名单上。

更重要的一点是：这不只是关于你（这台 Mac 的使用者）。你周围的人也在里面：你的家人、你的朋友、"任何"通过你的设备和你聊过的人。没有人被问过，而库把他们连到你，也通过他们共享的事件和群组，把他们彼此连起来。一段关系是比它推导所依据的那些行高一级的情报。 比如，交叉比对过我自己的库，我（好吧，是一个替我干活的模型）可以轻松推出下面这些：

• 家里有个孩子，以及大致年龄。 家庭成员类型和一个家庭圈给出了这个家庭；记分卡的孩子、儿子/女儿列给出了孩子在这个家里的位置。旁边还坐着一个年龄，从家人共享拷贝而来；库里有些出生日期会带着系统自己的"推算"标记，虽然我们不清楚系统所谓推算具体指什么。
• 孩子上的是哪家托儿所，以及能打进去的两个号码。 从联系人卡片拷贝。注意缺的东西：日历里没有"送孩子上学"的事件，所以库握着机构和电话，却没有孩子被送去的那个钟点。这仍然够你用一个他手机本来就信任的号码打过去。
• 这家人这几天几点到几点会在哪。 一个日历事件、一个地点、两个存储的时间槽，以及一个写着家庭名字的标题（所以即使参与人行是空的，名单也在那串字里）。
• 家里谁会到场。 记分卡点出被判定为家人的人，一个"家庭"实体把他们绑在一起，一个家人共享圈说明他们中哪些在同一个家庭组里。
• 以及，在同一个文件里，这台机器上装了什么——细到密码管理器。

很容易看出，如果这个隐私的单点故障落到错的人手里，它可以怎样被武器化。我们在第二篇里把这个（假设的）场景演了一遍。好消息是，这些知识本来应该留在你的机器上，由完全磁盘访问权限保护；尽管它可以被其他服务消费（但我们并不完全清楚哪些、以何种方式能访问）。

现实是，这个库里的信息量确实非同寻常：每次我们深挖守护进程推断什么、怎么推断，都会打开几条新的调查线。任何你不想让人知道的事——关于你或你的家人——很可能就在里面某处，而我们认为你有权知道它在不在。你实际得到的是：没有文档、没有办法检视这个库、也没有通用的办法去纠正一个错误的推断。

所以我们给你两样工具。第一是 iKnow，一个本地看板，浏览你自己的图，什么都不离开你的 Mac（下一节带你看一遍）。第二是给想深挖的人：iKnow 仓库里带一份写给你自己的智能体的手册，告诉它数据库在哪、怎么读，让它去找你想找的东西。（请指向自托管的模型，不要用云端的。）

五、iKnow

iKnow 是一个用 Python 标准库实现的网页看板；没有 npm，没有 CDN。

它被设计成直接跑在你的 Mac 上、也就是数据库所在的地方。运行时它绑定 127.0.0.1，在文件系统中定位这些数据库（需要相应权限），以只读方式打开，边查边收集信息，最后呈现成一个看板。不写任何东西，不记任何日志；数据从存储出发、经回环网络、进浏览器标签页；如果你愿意，可以在完全断网的机器上跑。

我们在 macOS 26.6.2 与 26.7.1 上测过，在 27.0.1 上只做了部分测试。

iKnow 有十几个页面。

从这里开始

你的 Mac 知道什么。 落地页：围绕你的人际图。下面依次是照片里的脸、你的家人、你的账号句柄、你的通信对象，以及你接下来会在哪。

它的图和本文开头那张是同一个家庭，只是由工具自己的渲染器画的：

这里没有任何东西是记录里没有的摘要：每个节点都是一行，点开就显示那一行（本文开头那张图也一样）。

图是总览，而总览容易让人耸耸肩。图后面的页面则不会。

社交图。 库通过共享的会议、群聊和一个亲密度分数，把谁连到谁。每个圈可以展开到它的成员，以及它背后的证据。

它推断出了什么

亲属记分卡。 守护进程推断出的家庭绑定。

落地页上的卡片只保留了它点名的人：

对分数来说这话成立；但作为分数输入的东西，有些确实是你录入的（联系人卡片上的关系、紧急联系人、家人共享）。母亲、父亲、女儿都是 0.960——这是这些列能到的最高值；哥哥、儿子、姐姐是 0.500。

下面那部分是我觉得最难辩驳的。九项独立检查（伴侣列、综合分数、家庭群组实体、家人共享令牌、iCloud 家人标记、十二个月最频繁联系人、照片人脸聚类、通讯录记录、可达的账号句柄），卡片数的是有多少项落到同一个人身上。母亲 8/9；父亲 7，还有伴侣 Priya Sandoval 也是 7——而她不在上面那张名单里：iKnow 列的是"会归并进另一列"的关系（母亲与父亲归并进"父母"），而"伴侣"不归并进任何列。即便如此，连线还是找到了伴侣。

卡片只是一张表的摘要，iKnow 也把整张表画了出来：

这两张截图里的分数是编的，而且比真实情况宽松。在我们拆解的那台 Mac 上，只有"母亲"到了最高档；其他被它打了分的人，只是在每一个家庭标签上同时得到一票小分，父亲和哥哥一模一样。这套样例保留的是这张表的"粒度"：它只会写少数几个值（0.125、0.25、0.5、0.96），大多数人停在某个默认值上。

人脸索引。 照片里每个人都有一个人脸聚类。

它的共现图没有用到任何一条通讯录、消息或日历记录，只由你的照片构成：

每个节点戴着它聚类的主脸，从照片库读出，并被 iKnow 自己的"共享屏幕"开关模糊掉。模糊之下没有人：样例没有照片库，每一张脸都是为它画出来的合成肖像。

这正是这一页自己要说的：图指向了这些人脸聚类，却几乎叫不出其中任何一个的名字（在样例里是 29 个中的 3 个）。它不需要。谁站在谁旁边、多频繁、哪些群体从不碰面——一个字的名字都不用，全都在那里；而任何了解这个家庭的人，一秒钟就能把名字贴回去。

猜的还是给的。 你录入的东西和 Mac 自己算出来的东西，住在同一张表里。把它们分开的只有一个置信度。

它记录了什么

一年的联系。 你和谁说过话、什么时候说的，以及一个字的消息内容都没有（它也不需要任何内容就能知道你在睡觉）。

落地页上这张卡片最容易引起反应，而它里面一点推断都没有：

这里面没有内容是内容。全是元数据，而它足够了。

最后一行值得读两遍：它能读作"睡眠"的那些小时。

iKnow 把这条线也画了出来，同一份日志折叠到一周：

这就是这个库的普遍形状：里面几乎没有什么是"必须被采集"的，因为几乎一切都只是某件被采集的事的后果。

日历。 唯一知道你会去哪的那一层：几点、哪个房间、谁参加、拨入号码是多少。

你撤回过的。 撤回一条事实并不会删除它。行搬进一张过期表，保留置信度与来源。

机器部分

存储。 文件本身：它建模了什么，以及两行真实数据展开后能牵出的一切。

设备指纹。 Mac 上装的每个应用都明文写在里面，旁边还有一个 token——它是那个应用标识的无盐 SHA-256，所以这一页在你的浏览器里把它重算一遍，你可以亲眼看着它对上。

还有谁在读它。 图是第一份拷贝，不是唯一一份。这一页画出订阅它的那些视图、它们发布到的数据库、重复同样事实的那些表、从与 Mac 配对的硬件进来的流，以及已经搭好但还没跑起来的机器。

关于 macOS 27 的说明。 macOS 27 于 2026 年 9 月 14 日发布。升级到 27.0.1 之后，图撤回了大部分从通讯录、日历、Siri 建议、家人共享和应用目录建起来的行，并在随后一天里重建。iKnow 的一些页面在 macOS 27 上可能还不能完整工作。

六、继续深挖

这是「棋局」系列的第二篇。第一篇是本文，第二篇是《把个性化武器化：从知识图谱到敲诈》。

引用格式（BibTeX）：

@misc{8rank:apple-intelligence-personal-knowledge-graph,
  author = {Dario Pasquini and Micha{\l} Bazyli},
  title  = {{Anatomy of Apple's Personal Knowledge Graph}},
  year   = {2026},
  month  = oct,
  howpublished = {\url{https://8rank.ai/game/apple-intelligence-personal-knowledge-graph}},
}

我们的整理

原文是一篇取证式拆解，读的时候容易陷进 181 个类别里。抽出来其实是四件事：

三条可以自己动手验证的判据：

1. 先问"能不能查询"。~/Library/IntelligencePlatform 下 51 个明文 SQLite，受 TCC 完全磁盘访问保护——也就是说，任何拿到这个权限的进程都能读，而且读的时候不需要解密。
2. 再看"谁能读到"。原文里"还有谁在读它"那一页列了订阅方、发布到的库、重复同样事实的表，以及从配对硬件进来的流。要判断风险，这一页比 181 个类别有用。
3. 最后看"错了能不能改"。原文明确说：没有文档、没有检视手段、没有通用的纠错办法。这条比任何单个字段都重要——一个你改不了的推断，会一直参与后面的推断。

边界：这是一篇安全研究，不是对 Apple 的完整审计。作者自己说采集环境是 macOS 26.6.2，27.0.1 只做了部分测试；三张表里标"未找到机制"的有 75 个类别、93 个谓词，"可能已实现（未验证）"的另有 16 + 24 个——也就是说，词表声明的东西有相当一部分我们并不知道是否真的在用。iKnow 的截图数据是合成的（作者在正文里两次说明），分数比真实情况宽松。这篇文章的价值在于"结构被确认存在"，不在于"每个字段都被填满"。

相关阅读

• 你的 Agent 并不自主：你就是它的循环——harness 的"围墙不是指令"，与本文"权限才是墙"是同一件事
• 让 AI 读懂博途工程：上下文从哪来——工业现场侧的同一类问题：图的边界比模型能力更决定结果
• 你的博客读者已经不是人：llms.txt 和 .md 才是它的入口——机器读者时代的入口问题

来源

8rank.ai，Dario Pasquini 与 Michał Bazyli，《Anatomy of Apple's Personal Knowledge Graph》，2026-10-28：https://8rank.ai/game/apple-intelligence-personal-knowledge-graph。正文 6 张截图与原文一致（原文以内嵌数据形式承载，已转存站内）；三张本体表按原文逐行翻译，id 与标签保留 Apple 原文。

本文由 汇智网 · Software 2.0 编译整理，转载请注明出处。

这是「AI 基建 / 评测 / 安全」专题的一部分。完整地图见：AI 基建 / 评测 / 安全完全指南