湖仓上的 AI:上下文以形状而非查询的方式存在——Zach Blumenfeld(Neo4j)

• 全场用一个虚构公司贯穿：AutoFix Group，「你可以把它想成类似 Pep Boys 那种连锁汽修」，全国性汽车维修连锁。资产分两类——一堆维修工位（bay）、车辆手册 / 安全公告（bulletin）/ 召回通知（recall）的文档库，以及一个记录了所有维修工单的数据仓库。→ 详细
• 三个 persona 决定了后面每一个 demo 问题的出处：车间一线技师「Danny」（车已经开进工位、当场要答案）、想做 co-pilot 辅助技师的管理层、以及「像 Sam 这样的人，也就是我们——真正得把东西做出来的 AI 工程师」。→ 详细
• 技术底座是 BigQuery（数仓）+ 云存储（PDF 文档），但讲者明确说「这些模式同样可以扩展到 Databricks 和 Snowflake」；课程仓库里甚至附了把数据灌进 Databricks、用 Genie 和 AI search 做对比的说明。→ 详细
• 所有数据都是讲者模拟生成的：「所有这些数据都是我模拟生成的，不是敏感数据」，目的是逼真地模拟一个「手册 + 公告 + 召回互相引用」的真实文档生态。→ 详细

• lakehouse（湖仓一体，把结构化的数据仓库和堆非结构化文档的数据湖放在同一套存储上）天然分两侧：warehouse 是表，data lake 是文档。「如今访问数据本身已经不太难了」——text-to-SQL 和向量检索都是现成的。→ 详细
• 真正的问题被他连问了三句：「你怎么给你的 agent 提供正确类型的上下文？它到底能不能以它需要的方式看到全部数据？以及能不能切出恰当的一个切片来回答对应类型的问题？」——注意重点全在「类型」和「切片」上，不在「能不能查到」。→ 详细
• 最关键的一句诊断：直接在 BigQuery 之上糊一个 co-pilot，「它确实能把数据拉对，但有时候会自信地给出错误答案（confidently wrong）」。少数几张表上的 text-to-SQL 没问题，「但当那些表变得巨大、你有上百张表的时候，或者当你有一个庞大的文档库、里面有成百上千甚至上百万份文档的时候，东西就会丢失、就会从缝隙里漏掉」。→ 详细

• 第一类是证伪：「我们缺了什么？我们是不是缺少某些文档，没法覆盖开进来的所有车型？或者，哪些文档我们其实根本没在用？」他直接点名这类是「在证伪」，而「语义检索只能匹配相似的东西……它没法真的找出『不存在的例子』」。→ 详细
• 第二类是全量模式：「我们最常见的问题模式是哪些？有没有什么东西我们反复修都修不好？有没有哪些特定类型的召回在成组地冒出来？」——「这类问题你必须遍历整个数据集才行」。→ 详细
• 第三类是关联本身：「当你面对一个『长得都差不多』的大 schema，里面有一堆非常相似的表，你怎么搞清楚该怎么正确地 join 它们？」→ 详细

• connection：本质上「架在你数据仓库之上的一个语义层」，管结构化数据怎么正确 join。课程里第一个讲。→ 详细
• table of contents（也叫 outline，目录）：用在非结构化文档上，「有点像一个树形结构，但节点之间还带有不同类型的连接」。→ 详细
• themes（主题）：「浮现出你数据里那些不那么显而易见、或者你事先根本不知道的全局模式，也就是发掘未知的模式和聚类」。→ 详细

• 现场举手：熟悉 graph 和 GraphRAG（把知识做成图、再让检索沿着图走的一类做法）的「还挺不少的」；用过 Neo4j 的「差不多有 30%、40%」；后面问到图数据科学（graph data science）时则「看来没有太多人」。→ 详细
• 属性图（property graph）模型三件套：node（人、地点、事物）、relationship（动词或关联，如「人拥有车」「人驾驶车」）、property（挂在点或边上的字符串 / 数字 / 日期 / 向量）。→ 详细
• 一句非常好用的直觉比喻：「当你不断往里加数据，它几乎就像是一堆预先 join 好的表，所有东西天然就互相连着，你可以非常轻松地在各个 node 之间跳转。」→ 详细

• 全程用 Claude Code 当 agent，模型是 Opus 4.5；讲者强调整套是模型无关的：「只要你能访问那个 MCP server，它就是模型无关的」，因为用的是 skills 框架 + MCP + CLI 三条通路。→ 详细
• 核心工具是 Neo4j CLI：一个命令行工具，让 agent 直接对图数据库跑查询；它还自带 Cypher skill（Cypher 是 Neo4j 的图查询语言，相当于图世界的 SQL）和 GDS skill（graph data science，图数据科学库，用来跑社区检测这类算法）。→ 详细
• 教学立场很明确：「我觉得我们现在已经到了这样一个阶段：很多人都不再一行一行手敲代码了……所以我基本上不会让大家手写任何 Cypher 查询代码。整个 workshop 我会演示怎么用 agent、配合写好的 spec 来帮你生成这些代码。」→ 详细
• 为什么必须用官方 skill 而不是让模型自由发挥：这些 skill 由内部团队维护、「一直紧跟最新的东西，比如 Cypher 25、26」；否则「它会跑到互联网上去抓四五六年前的 Stack Overflow 问答，然后给你一堆过时的、糟糕的 Cypher」。Neo4j CLI 里还能下载 agent memory、云基础设施、各语言 driver（Java / Go）等一大堆 skill。→ 详细
• 环境侧：整门课挂在免费的 Graph Academy 上，约 17 节课，按形状分节；用 GitHub Codespaces 一键起环境（也可 clone 到本地跑 shell 脚本），.env 里填 Anthropic key、BigQuery key 和每人独立预分配的 Neo4j sandbox 凭证。仓库里预置了 skill 文件、outline / search / theme 三个脚本、查 BigQuery 的极简 run SQL 脚本、留白待填的 spec、解决方案脚本，以及 PDF 原件和 markdown 版 corpus。现场 Wi-Fi 与 Claude 响应偏慢、等大家跟上、报名流程等占了不少时间，此处略过。→ 详细

• 课程用的 schema 刻意做小：以 work orders（工单）为星型中心，外围是 vehicles（车辆）、DTC 故障码、procedures（维修流程）、work order parts、parts，「它们之间通过很简单的主键-外键模式关联起来」。→ 详细
• 构建语义层的工具叫 NeoCarta，是 Neo4j 的 labs 项目（相对核心工程「迭代速度会快一些」的实验线），作用是「创建一个元数据 graph」；它还能承载业务术语、业务流程等等。→ 详细
• 动手步骤极简：从课程页复制脚本 → 新开一个非 Claude 的终端 → 允许粘贴 → 运行。跑完得到六张表和五条参考 join 路径；讲者已提前跑过没重跑，理由是「它应该是幂等（idempotent，同一个操作跑一次和跑十次结果一样，不会重复堆数据）的」。→ 详细
• 生成出来的图长这样：中间一个 node 代表 database，往外是 schema，经 HAS_TABLE 边到 table，再到 columns；列上还可以可选地挂「代表性取值（representative values）」帮 agent 猜内容。→ 详细
• join 关系的来源不止一种：本例用的是 BigQuery information schema 里的主外键约束，但「NeoCarta 也可以用查询日志（query logs）之类的东西，或者你也可以手动去定义你希望这些东西怎么 join，以及配上其他术语和指标」。→ 详细

• 「ontology（本体）、semantic layer（语义层）这些词最近被到处乱用，尤其是今年夏天。」他给了自己的判据：「ontology 帮助某个东西去解释和推理数据；而 semantic layer 帮助某个东西理解大家一致认可的统一术语是什么，这样它才能准确地查询数据。」 → 详细
• 语义层还要吸收「业务说法」和「物理表」之间的落差：数仓侧的 metrics views「用的是业务术语，可能跟你实际的物理数据模型不一样」，「这也是我们为什么要有这些 metadata graph 的原因之一，就是帮你管理这两者之间的差异、这个 delta」。→ 详细

• 现场 demo 的提问是「哪辆车装了零件 IC 2042？」。agent 的动作链是：调用 NeoCarta 的 MCP server → 读取存在 Neo4j 里的元数据语义层 graph → 拿到列、行、join 路径的信息 → 用这些去指导一次 text-to-SQL 查询 → 调那个极简的 run SQL 脚本打到 BigQuery。最终结果按品牌（make）分组给出车辆数量。→ 详细
• 这里是整场最需要划重点的一句：「注意我们这里真正在做的事情——我们并不是用 graph 把数据复制过来，这里没有往 graph 做 ETL。我们做的是把 graph 当作一个语义层。」 图里只有「哪些表、哪些列、怎么 join」这类元数据，业务数据一行都没动，还躺在 BigQuery 里。→ 详细
• 收益随规模放大：「当你的数据越来越多、表越来越多的时候，有这么一个语义层来指导所有东西怎么 join 在一起，是非常有用的。」→ 详细

• 有人直接问「为什么不把 OLTP 数据（在线业务库里那些天天被增删改的交易数据）直接迁进 graph」。回答给了三条现实阻力，值得整段记住：规模与同步——「很多生产环境的场景，你可能有 TB 级的数据，而且还在持续更新……你就得在搬迁的同时想办法做同步」；建模成本——「可能有很多额外的属性，或者有些东西你得写自定义的 ETL，因为有些内容你并不想放进 graph 里」。→ 详细
• 第三条最被低估：安全合规。「很多人往往要等到真的碰上了才意识到，就是安全合规的问题。因为如果你有敏感数据在某个系统里，哪怕你物理上能把它搬过去，出于安全原因你实际上可能并不被允许把那份数据直接搬到另一个数据库里。」→ 详细
• 反过来，什么时候 ETL 才值得：当你需要图查询的性能（比如供应链里从 A 到 B 的可变长度最短路径、超大规模递归 join），或者要跑图算法、生成 graph embedding（把节点在图里的位置压成一串数字，好做相似度比较）、做聚类。「那种情况下把数据搬进来就非常合理了。」另外，数据本来就是非结构化的时候，搬进图有额外好处——「因为这样你可以给它赋予一个 graph 结构」。→ 详细

• 图数据库的老价值是复杂查询快（供应链最短路径）；新价值是表示：「它能提供一种数据的视图或者说表示方式，让 agent 能理解表和表之间可能如何关联。所以哪怕最终的 join 可能只有三四跳，你可能得先理解上百张表才能得出那个结论。」→ 详细
• 因此重心转向 ontology / semantic layer / virtual graph：「也许你想让数据待在原地，你还想继续用 SQL、按你原来的方式去访问它，但你需要某种方式来引导 agent 正确地做这件事。」virtual graph 已发预览版，给你一个数据库的 graph schema 并允许直接跑「下推式（push down）的 Cypher」——好处是「你在查询接口层就有了这个视图，而不只是在 metadata 语义层上有」。→ 详细
• NeoCarta 的现状很坦白：它由 field team（一线客户团队）做出来，「非常客户驱动」，目前主打传统 SQL 数仓；更少结构化的数据甚至文档也在考虑范围，「所以现在正在形成一个 backlog。一切都在飞快推进」。已知在做的是 Databricks connector，可能还有 metric views。→ 详细

• 文档侧的原料：PDF 格式的技术公告（bulletin）、篇幅长得多的手册（manual）、召回通知（recall），另有一份 markdown 版 raw corpus 方便读内容。这些是多章节文档，且彼此交叉引用——手册讲 ABS 系统的平台代码和诊断排障时会链到别的文档。→ 详细
• 目标不是「搜关键词」，而是给 agent 一份能导航的目录：「基本上就像人一样，如果你去看一本书的目录……你可以读懂那些缩进」。参照物是 page index 这类文档导航方案。→ 详细
• 结构是包含树 + 跨文档链接的二合一：technical library → bulletins 子文件夹 → 文档 → 章节，这是树；再叠上指向其他文档的 link。「所以它不只是一个自上而下的树状目录，它还带有这些 link。」→ 详细
• 让这套能被 agent 用起来的关键设计是分层 URI（把每个节点的 ID 设计成像文件路径一样的层级字符串，如 technical-library/bulletins/xxx）：「如果我在下面这个 TSB 通知这里，我就知道它属于 safety bulletin，而且它属于 technical library」。拿到一个 URI 就能「真的从 graph 里抓出一个 node，这个 node 上有原始文本，或者甚至只是一个指向原始文本的链接」，还能顺着拿子树往下钻。→ 详细
• 一句话概括这个形状给 agent 的新能力：「不只是做 vector search 或者词法检索那种搜索，而是在某种意义上真正地在文档之间穿行。」→ 详细

• 他先向听众确认了 GraphRAG 的常规做法：「GraphRAG 里我们通常还会有一个 entity extraction（实体抽取，让大模型从文本里认出人名、零件、车型这类实体并建成节点）的环节……然后把它们链接回原始的文档 chunk。这很好，而且效果也确实不错。」→ 详细
• 然后给出替代方案：「我这里要给你们展示的，是一种轻量得多的做法——我们实际上要用一种确定性的加载方式。」结构全部来自文档自身：包含树（文件夹 / 文档 / 多层嵌套的 section）、NEXT_SECTION 给出顺序、LINKS_TO 给出跨文档跳转，用的是「具名 link，有点像你在 Obsidian 仓库里可能会看到的那种」，也可以换成超链接。→ 详细
• 好处被他明确列了三条：第一，幂等——「你在一开始就不依赖 LLM」；第二，更快；第三，便宜且可复现（后面讲 themes 时展开）。适用条件也说得很清楚：「如果你已经有了本身结构性很强、互相之间链接也很多的文档，有时候为了快速把东西跑起来，用这种方式来做 graph 是非常划算的。」→ 详细
• 他给这种图起了个名字，值得抄进自己的词汇表：「我会说这更像是一个词法层面的、或者说文档结构的 graph（document structure graph），而不是那种完整的、靠 entity extraction 的 pipeline 来构建 graph。」 → 详细
• 幂等带来的运维红利在后面的问答里兑现：「假设你的整个 graph 明天全没了，只要你的文档没变，你重新加载一遍，得到的还是同一个 graph。所以最坏的情况就是你得把整个 graph 重新加载一遍。」增量也可以做——只更新变动的那个 node——但「你只需要意识到一点：它是会链接到别的东西的」，改名会牵动别的文档里的 URL 引用，「这里会有一些小的边界情况需要你去处理」，做好了就是部分同步（partial syncing）。→ 详细
• 加载实现本身也不神秘：load documents 里「就只是一些 Cypher 查询」，parse corpus「基本上就是用正则表达式来找出我们想要的那些内容」。前提是文档已经足够规整——「如果你有大量结构基本一致的手册，那你用正则加一些简单的 NLP 技术就够用了。如果文档更乱一些，你可能就得用 GLiNER 或者别的 LLM，这里面有不同的复杂度层级」。→ 详细

• 这是全场贯穿三个形状的统一工作法，也是他反复演示的动作。脚本文件里预留了一处「接线位」（wired query / WHERE 留白），prompt 指示 agent「去用 Neo4j 的 Cypher skill，并参考 doc outline format.md 这个 spec」，然后 agent 把查询写进去。→ 详细
• 他讲了自己为什么这么干：「这大体上就是我写更复杂的 Cypher 查询、更复杂的 graph 查询时的习惯做法：我会先给它写一份 spec。」 spec 里写清楚「这就是那个形状」、输出必须人类可读、需要支持哪些可选参数——「因为很多时候我们手上是一堆伪代码，我们并不确切知道该怎么把它们拼起来」。→ 详细
• 人类保留的是关键提示而不是代码：「在这个例子里，我确实给了它一个提示，让它用变长路径查询（variable length path query，一次查询里沿着同一种关系走不定层数），基本上就是为了把所有东西都按顺序排好。」→ 详细
• 产出的查询里那句 HAS*0..25 是重点：包含关系的边最多往下走 25 层，且这个深度在查询里是参数化的，「所以它给了你一个选项，可以决定你想遍历多深。这在某种程度上就是拼出这份目录时那种『图的味道』」。另有第二个「简单得多」的查询负责把 link 抓出来。→ 详细
• 三种调用方式当场演示：不带参数跑 → 返回整张图（「如果 graph 更大，我不会这么跑。我们这里最后能这么干，是因为我们只有几百份文档」）；depth=1 → 只往下一层；传入具体 URI（例如 Falcon 2.0 那份文档，或它链到的 coil identification）→ 「它基本上就会给我那份文档以及它链接到的所有东西」。→ 详细
• 这三个开关合起来就是这个形状的全部意义：「你能看到，一个 agent 现在可以怎样去抓取这些 URI，在整个 graph 里到处穿行，并给自己构造出这些分层的、带链接的视图。」 → 详细
• 反向次序也说清楚了：spec 不是从数据模型推出来的，而是先想「我们希望它对 agent 呈现出什么样子」，「定义好之后，我们就能得出想要的查询结构，再用它来指导我们的数据模型」——形状 → 查询 → 数据模型，反着来。→ 详细

• 「这个搜索文件会简单很多。基本上我就用一个 Lucene 风格的 index。这里我不打算用 vector 搜索」——Neo4j 自带 Lucene（一套经典的全文检索引擎，按关键词和词频打分，不是按语义相似度）全文索引，建在 document 和 section 两类节点上，「像 folder 我们就不放进这个 Lucene index」，返回结果带分数。→ 详细
• 和 outline 形状的接口就是那套 URI：先全文搜，再用 starts with 做后置过滤限定子树，「所以我就可以说，只在手册的这一部分下面搜索」。妙处在于「它仍然在利用那个层级化的包含结构、那棵树，但它是通过 URI 这个 ID 结构来实现的，这样就不用做那么多图遍历」。→ 详细
• 不用向量的真实原因很务实，来自他的研究岗位：「我要跟非常多不同的 AI 模型、在非常多不同的平台上打交道。你可能想不到，但是要把选项接通、让它能同时兼容六家不同的 vector 厂商，是挺麻烦的。」→ 详细
• 那语义能力从哪来？答案是 semantic expansion（语义扩展）：不在索引里做语义，而是「指示 AI 模型说：嘿，用你的世界知识——如果有人问『发动机抖动』，那可能指的是 misfire（失火）或者别的什么」，然后因为 Lucene 支持布尔查询，直接搜 misfire OR rough idle。把语义理解外包给模型，把召回留给确定性索引——这是个可以直接抄的架构选择。→ 详细
• 索引名叫 content_search，脚本传进去的字符串就是 Lucene 查询参数；先命中索引缩到一批文档和 section，再按 URI 前缀过滤。→ 详细

• 关系名是提前定死的（因为是确定性加载），「这多少有点靠品味或者主观判断」。他的选择是把 HAS 做成通用的多层包含关系：「如果我搞成 HAS_FOLDER、HAS_DOCUMENT_SECTION 这样，Cypher 就会变得很复杂。所以这就是我把命名保持得很短的原因。」→ 详细
• 权衡讲得很干净：「命名粒度越细，你的 agent 和下游工具在拼查询的时候就能越精确。但与此同时，你的数据模型也会变得越复杂。」代价在上下文里兑现——「如果你到了生产场景，有几百种不同类型的 relationship，那在 context window 里可能就很难管理了，也会导致模型不太容易顺利地把那些 Cypher 查询拼出来」。→ 详细
• 节点标签同理，而且他给了一个「时代变了」的判断：本场没有专门建 parts 节点，「我让 agent 自己去推断零部件、从文档里把它们抽取出来」。「两年前我大概会说你必须要有那个额外的 node。现在看起来 agent 已经足够聪明，可能不是所有时候都需要了。」→ 详细
• 但有例外：「比如我们在生命科学领域就经常看到，那里有非常具体的本体，涉及各种分子、药物之类的，你就真的需要把这些在 graph 里表示出来，否则你的推理根本讲不通。所以我不太想说『这要看用例』，我不想当那种人，但某种意义上确实就是这样。」→ 详细

• 有人问「文档名字取得准不准，对 agent 遍历有多重要」，回答是很重要：「如果你的文档命名很糟糕，而你又用那种大纲视图，那 agent 在尝试遍历的时候就没什么可依据的了，所以它可能会误解某个文档的含义。」——这也正是必须给 outline 配一个 search 的原因：「因为它可以真的去文档内部看一看。」→ 详细
• 他透露自己就用这套做个人知识库管理：「因为我自己实际上也用这套来做我个人的知识库管理。我有自己的开源库，里面就有这些工具。」而在他的真实使用里，「最大的问题是当你的文档已经过时或者发生了漂移（drift）的时候」。→ 详细
• 他正在考虑的解法是给节点加元数据字段：「也许我们需要加一个『最后更新日期』之类的字段，或者标记一个文档是不是权威版本（authoritative）。」→ 详细
• 除了文档名，链接名同样重要：像 Obsidian 那样给链接起别名 / 同义词「是非常有帮助的，因为这样就是『哦，我立刻就知道我为什么要链接到另一个东西上』」；如果原始数据没有这层信息，「有时候在 ingest 环节里用一下语言模型可能会挺有帮助的」——注意这是他唯一松口让 LLM 介入加载环节的地方。→ 详细

• 起点是只看文档之间的 LINKS_TO 关系单独建一张图：「我们有这些手册、这些召回通告、这些技术公告，它们彼此链接、互相引用」，比如「这份指南，它是一份手册，被所有这些不同的维修流程文档链接着」。→ 详细
• 视野拉远就会看到自然聚类，他顺手打了个所有做知识库的人都听得懂的比方：「这种情况在那些 Karpathy 风格的知识库里也经常发生——你会看到概念自然而然地开始聚到一起，而 graph 能帮你把这些主题浮现出来，也就是那些你原本并不知道存在的东西。」→ 详细
• 算法是 Leiden 社区检测（community detection：自动把「内部连得密、对外连得疏」的一坨节点圈成一个簇）。「它和 Louvain 很像……我基本上把 Leiden 看作是下一代的版本，它在运行方式上效率更高一些。」→ 详细
• 性能机制：先做 projection（投影），「我们把 graph 的一部分放进内存，然后在上面跑这些高并发的算法。这样，即使你的 graph 有几百万甚至几十亿个 node，我们也能开始做这种聚类」。投影前还做了一次结构折叠——「我们会按 URI 把 relationship 折叠合并」，把 section 之间的互链聚合到文档层级，「这样对于我们的文档之间如何链接，就有了一个更清晰的解读，而且这样我们也更容易提取出社区」。→ 详细
• 交给 agent 看的 theme 视图包含四样东西：主题（一桶文档）、conductance（电导）指标——「衡量的是：簇内部的 node 之间连接有多紧密，相对于它们向簇外部连接的程度」，用来判定紧密互链还是松散互链；用链接标签做 top shared targets（最常被共享的目标）；以及每簇里中心度最高、被链接最多的文档。→ 详细
• 结果说服力很强：在完全没有 AI 打标的情况下，「仅仅依靠文档结构，我们就能看出第一个簇是关于 BCM、总线（bus）之类的东西……下一个簇是关于刹车的——刹车盘、刹车片、液压管路。所以全都是制动相关的东西。」→ 详细
• 这套东西的定位是回答全域问题：「问题都集中在哪些地方？文档在哪里比较薄弱？如果新来了一批关于某个不同主题的数据，新的文档应该归到哪里去？」→ 详细

• 「注意，它其实从来没有给 theme 起过名字，这正是这套做法的关键点。所以你拿到的所有东西都是直接来自文档本身。」 链接名、排名靠前的文件名，全部原样取自数据；而因为附带 URI 和文档 ID，agent 可以立刻跳回 outline 或 search 形状继续下钻——「所以这就给了 agent 在多个工具之间来回跳转的能力」。→ 详细
• 好处是可复现性：「只要数据不变，我每次跑出来的结果都是一样的。如果数据变了，结果也会随之变化以反映数据。所以它非常稳定。」→ 详细
• 代价也说了：「因为这套方法基本上只看文档元数据和链接元数据——如果这些东西本身没有被很好地打好标签，那这个视图一开始可能不会特别有信息量。」这正是微软那套 GraphRAG 要做重度实体抽取 + 分层级 LLM 摘要的理由：他们用的是同一个 Leiden 算法，但会「在每个主题之上再做一层由 LLM 驱动的摘要」。→ 详细
• 三条代价并列，几乎是一句可以贴在墙上的判断：「但很显然，那样成本更高、速度更慢，而且你跑两遍，结果可能不一样。所以每种做法之间都有取舍。我给大家展示的是比较轻量、比较简单的做法……如果你才刚开始接触这块，从这里入手可能更容易上手。」 → 详细
• 概念上他也把这套接回了熟悉的坐标系：「这其实也很像最初微软那套 GraphRAG 的思路——全局搜索 vs 局部搜索，对吧？我们这里在做非常类似的事情，但方式非常轻量，我们基本上没有用任何 LLM 抽取。」→ 详细

• 唯一暴露出来的超参是 gamma，控制切多细：默认 gamma=1 时跑出 13 个组，调到 gamma=2 得到 14 个，「它基本上就是把结果切得更碎、分成更多组」；GDS 文档里还有更多参数，而且这类算法是层次化的，「你还可以选择你想要的粒度层级」。「随着你不断推进、对自己的语料库理解得越来越深，你可能会想去调这些超参数。」→ 详细
• 图很大时怎么把视图裁到能塞进上下文：按社区大小设阈值截断，「对于小于某个阈值 X 的社区，你就不一定需要把它们凸显出来」；但他补了一句反例——「有时候小社区反而非常重要，这也正是那个 conductance 指标的作用……你同样可以拿它来做截断」。→ 详细
• 时序数据怎么办：Leiden 是「吸进投影→打标签→投影销毁」的一次性算法，所以数据持续更新时就反复重跑，「你就可以得到差不多像一个时间序列一样的、不同时刻的主题 id」，既能对快照时点生成摘要，也能观察主题随时间演化。→ 详细
• 这个玩法远早于 AI：「很多人其实在 AI 出现之前就已经在用了，他们会把它用在比如说欺诈检测上，像是看信用卡拒付欺诈，或者其他一些像反洗钱那类的场景，用来看聚簇……他们得反复跑，来看事情随时间怎么变化，然后预测未来。」→ 详细

• CLI 能干两件事：跑查询，以及抓取 graph schema。「这让我能做的事情就是先搞清楚 graph 里有什么，然后基于这个去写查询。」→ 详细
• 它填补的正是三个固定形状之间的缝：「当你有一个事先没预料到的问题时，这就非常有用，agent 就得自己在这些 shape 之间把东西拼接起来，它必须自己写一个自定义的 Cypher 查询。它可以非常高效地做到这一点。」→ 详细
• 他给出了一个时间尺度上的判断：「我看到把它和 skills 一起用之后有很多提升。比起我们哪怕一年前、或者半年前的 text-to-Cypher 体验要好太多了。 如果你打算写 Cypher，或者要用 agent 做任何 text-to-Cypher 的事情，我强烈推荐使用 Neo4j CLI，以及那些 Cypher 和 GDS skills。」→ 详细
• 并且预言了固定形状的未来：「一旦你把 Neo4j CLI 交给你的 agent，它就会变得非常强大……而且会出现一些情况：它宁愿这么干，也不用某个预设的 shape。随着我们的 text-to-Cypher 能力提升、随着我们不断积累更多 skills，它会越来越倾向于更自由形式的用法，频率会高得多。」——为了让听众看清形状怎么协作，他在 demo 里特意禁用了 CLI。→ 详细

• 问题原型来自车间技师：「对于这个 VIN（车辆识别码）、报出这个特定故障码的情况，我们在类似车型上做过哪些修复动作是有效的？」商业动机极其具体：降低 comeback ratio（返修率）——「返修率基本上就是客户因为修完没解决问题而不得不再跑一趟的次数」。→ 详细
• agent 的完整路径（他特意要求它把步骤讲出来）：加载 autofix skill → 全文检索做 grounding（搜故障码 + misfire OR rough idle，命中最高分的发动机型号，确认自己找对了文档）→ tree shape 找交叉链接和成因（从手册链到各维修流程）→ 拿 join path → 回数仓按 VIN 查工单。→ 详细
• 结论是一个具体零件号：「有个旧款点火线圈后来做过改版，必须用新版来替换。」路径上每一步都踩在前一步的确定性结果上。→ 详细
• 与纯向量方案的对比是这场最实用的论证：用 vector search 加 Databricks 的 AI search / Genie「你也能做到这件事，但经常发生的情况是，为了找到它在那个 tree shape 上做关联所需要的东西，它得做多得多的 vector 命中，而每一次命中都是一次出问题的机会：找不到正确的文档，或者干脆产生幻觉，扯出某个跟这个特定零件其实无关的失火问题。但因为它是基于 tree shape 做了 grounding，它就能拿到正确的信息，然后再把它关联回表里。」→ 详细

• 问题是双向的缺口扫描：「我们的书面维修流程和我们在一线实际看到的问题之间，是否存在不匹配？哪些文档是缺失的？或者反过来那半边：在我们的数仓数据里，有哪些文档我们压根没有用上？」提问者画像是主管或分析岗。→ 详细
• 为什么这类问题难，他说得极其到位：「它有点像在证明一个否定命题，或者说找一处不匹配，因为你其实是在说：我也不知道我要找的是什么，但我要找的是一个缺口。」而向量检索按定义做不到——「如果你只靠那个的话，按定义你根本没法去搜索一个『不存在』。你只能搜索那些确实存在的东西。」→ 详细
• 因此得出全场的战略级结论：「当你开始问这些更全局性的问题、这些全域级别的问题时，graph 会非常有用，尤其是当这些问题是关于某种模式，而你甚至可能还不知道自己在找什么的时候。」 → 详细
• 跑出来的结果分两半：一半是「有一堆文档我们可能根本没覆盖到，因为我们看到这么多返修，很可能就是用错了零件造成的」；另一半是「我们用的那些 DTC 代码在仓库里压根没有对应内容」。具体落到数字上——两个 field code 属于「标题不匹配 / 用错误的流程做了诊断」（库文档里那几个零件根本没提到正确的维修方式），另外两个 DTC 代码完全没有 code 级别的文档。→ 详细
• 最诚实、也最有教学价值的一段是他当场承认 agent 走了弯路：「可惜的是这里它没有用 outline，它本来应该用的，因为它一旦用 outline，就能顺着遍历、把所有链接都找到，效率会高不少。那样它就不用做这次耗了不少时间的全文检索大范围爬取了。不过即便如此，因为它有分层 URI，加上全文检索上的语义扩展，它最终还是找到了。这是个很好的教训：当它真的用 outline 时，返回会更快。」——形状给对了，agent 走错路也还能兜住；但选路本身仍然是 skill 设计的活儿。 → 详细

• 最后一问用 theme 形状：「我们所有技术公告和召回里的共性模式是什么，以及每一项大概影响了多少台车？」——「所以这是一个覆盖度的问题」。→ 详细
• 执行链条：跑 theme pattern 抽出高层主题 → 去工单历史里把各类维修方式拉出来 → 做一次类似 join 的操作把它们归到正确的主题下。→ 详细
• 结果显示 agent「用了 themes，没有用 search」，并用 connection 形状回数仓取「受影响的车辆数」，最终「把它们按不同的主题类型归了组，下面再挂上对应的车辆和工单，并按百分比分组」——三种形状在同一个问题里各司其职。→ 详细

本场没有 lightning round，但讲者每 10-15 分钟主动停下来收问题（开场即声明「有问题请直接举手」，并让 Ben Squire、Ryan 在场边解环境卡点）。以下逐题列出：

1. 能不能用 Cursor 代替 Claude Code？ 应该可以，他本人没测过；顶部有仓库链接，clone 下来跑 shell 脚本即可本地起环境。→ 详细
2. Neo4j / NeoCarta 战略上在做什么？ 从「把数据导进图」转向「数据留在原地、用图引导 agent」：ontology、semantic layer、virtual graph（预览版，下推式 Cypher，把视图放到查询接口层而不只是元数据层）。→ 详细
3. 为什么不干脆把 OLTP 数据推进 graph？ TB 级数据持续更新导致同步难、需要自定义 ETL、以及最容易被低估的安全合规限制（敏感数据物理上能搬、制度上不许搬）。需要图查询性能、图算法、embedding、聚类时才值得搬。→ 详细
4. 每次初始化 NeoCarta 会重建整个 graph 吗？ 不会。build connections 通过 MCP server 函数把元数据 ingest 进去后就一直在，且是幂等加载；他自己上完课后没重跑，直接在上面查。→ 详细
5. Cypher skill 是怎么来的、还能拿到哪些？ 内部团队开发并持续更新到 Cypher 25/26；通过 Neo4j CLI 可下载一大堆 skill：agent memory、云基础设施、Java/Go 等各语言 driver。不用它，模型会去抓四五六年前的 Stack Overflow，给你过时的 Cypher。→ 详细
6. bronze / Delta 表这类怎么办？ 目前 NeoCarta 主打传统 SQL 数仓，更少结构化的数据甚至文档在考虑中，backlog 正在形成；已知在做 Databricks connector 和 metric views，可会后找 Ryan 聊。→ 详细
7. 怎么知道 agent 真的调用了它该调用的东西？ 看工具调用记录（connections 那步调的是 MCP server，会出现在 tool call 里）；教学场景他还会在 prompt 里直接要求「明确讲清楚你用了哪些步骤和什么逻辑」；生产系统则应该看日志。→ 详细
8. 加载文档的代码在哪、怎么解析？ load documents 里就是 Cypher 查询，parse corpus 用正则；文档规整时正则 + 简单 NLP 就够，更乱就得上 GLiNER 或 LLM，「有不同的复杂度层级」。→ 详细
9. 能换其他模型吗？ 可以。现场用 Opus 4.5，但整套是 skills 框架 + MCP + CLI，「只要你能访问那个 MCP server，它就是模型无关的」。→ 详细
10. relationship 该怎么命名、谁来命名？ 确定性加载下由人提前定，「有点靠品味」；HAS 刻意做通用以免 Cypher 复杂；粒度越细 agent 越精确但模型越复杂，几百种关系类型会撑爆上下文窗口。→ 详细
11. 这是不是语义检索的替代品？ 「我觉得把它称为『替代』是有点天真的」——大多数人最终会做混合检索，他自己至少会配全文搜索。但证伪类问题、理解「某文档关联哪些零件」这类，语义搜索确实答不好：理论上可以疯狂发 vector 查询捞段落，「但出错的概率更大」。→ 详细
12. node label 要不要预先定义？ 同样是建模品味题。本例不建 parts 节点，让 agent 自己抽；「两年前我大概会说你必须要有那个额外的 node」，但生命科学那种强本体场景仍然必须显式建模。→ 详细
13. Lucene 索引到底怎么工作、怎么按 section 限定？ 索引名 content_search，建在 document 和 section 节点上；先全文命中，再用层级 URI 做前缀后置过滤。→ 详细
14. 已有 graph 但还没建 Lucene 索引，能让 Claude Code 建吗？ 「我觉得可以，我这门课最开始可能就是这么干的」；但 Neo4j 的索引配置非常灵活（单节点 / 多节点 / 多属性组合），「这种灵活性在你让 AI 模型去做的时候，也可能成为它的阿喀琉斯之踵」。→ 详细
15. 文档命名准不准，对 agent 遍历有多重要？ 很重要；命名糟糕时 agent 会误解文档含义，所以必须配 search 增强。他自己用这套做个人知识库，最大的痛点是文档过时和漂移，考虑加「最后更新日期」和「是否权威」字段；链接别名同样关键。→ 详细
16. 新文档进来怎么办？ 幂等加载兜底：文档没变就重跑得到同一个图，最坏情况全量重载；也能只更新变动的 node 做部分同步，但要处理改名导致的跨文档 URL 引用等边界情况。→ 详细
17. agent 应该先 outline 再 search，还是反过来？ 两种都成立：可以先看目录再搜，也可以先搜到相关文档再顺着它的链接铺开。→ 详细
18. 拿到 themes 之后要不要用 LLM 打标签？ 本场用「前者」（只展示数据原文）：稳定可复现、便宜、快；LLM 摘要（微软 GraphRAG 那套）信息更好读但更贵、更慢、两次跑结果可能不同。→ 详细
19. 时序数据怎么处理？ 反复重跑 Leiden，得到一串带时间戳的主题 id，可看演化；欺诈检测、反洗钱在 AI 之前就是这么用的。→ 详细
20. 图很大时怎么把视图裁到可管理？ 按社区规模设截断阈值，或用 conductance 指标截断——但要小心「有时候小社区反而非常重要」。→ 详细
21. 怎么保证节点上的关系是对的？ 本方案「照单全收地采信源数据」，错链或坏格式章节不一定能发现；但 outline 形状的一个副作用是可以让 agent 自动遍历、充当图的监督者去发现畸形数据。「我不知道我们有没有一个完美的解法。清洗脏数据一直都是个老大难。」→ 详细
22. 知识库规模变大后准确率如何，有 benchmark 吗？ 就今天演示的内容没跑过专门 benchmark；但客户会构建自己的定制 ontology 并跑 benchmark，对比「这种查询模式 vs 普通 vector search」在特定数据集上的效果。「今天这门课更偏概念」，而且 skill 怎么写「永远有优化空间」。→ 详细
23. 结构化的 connection graph 和非结构化的文档 graph 之间有链接吗？ 没有，两张图完全没打通。agent 是从一边抽出零件号或故障码，再回另一边查文档，「用这种方式在实时做自己的 join」。「你完全可以把这种链接建起来，那对更确定性的映射会很有价值。这里我们没做，主要原因其实是为了上手快，因为我确实想提供一份容易跑起来、而且不依赖特定模型的代码。」→ 详细

收尾：workshop 全程可在线免费重做；Anthropic 的 key 会被撤掉（需自备），BigQuery 的 key 会多留一阵；课程后面还有几节没现场讲的信息性章节和可选练习课。→ 详细

• 讲者没有留个人邮箱或社交账号。现场三人组：Zach Blumenfeld（Neo4j AI 研究工程师，主讲）、Ben Squire（资深开发者布道师）、Ryan（合作伙伴架构师，负责帮客户落地）。→ 详细
• 唯一给出的持续入口是免费在线课程平台 Graph Academy（约 17 节课，配 Codespaces 环境和完整仓库）；NeoCarta 路线图相关问题他建议「会后找 Ryan 聊」。→ 详细
• 他提到自己有一个用于个人知识库管理的开源库（内含 outline / search 这类工具），但现场没有报出仓库地址。→ 详细