Arch CTO Replaces Vector RAG With Graph Theory to Steer Financial AI

Arch CTO 用图论替代向量 RAG 引导金融 AI 向量嵌入无法表示缺失数据或控制执行路径，因此确定性图拓扑对于防止受监管市场中的概率型 AI Agent 采取违规操作至关重要。 Keith Soura 指出，尽管向量嵌入就像一本事实百科全书，但在零容忍环境中运行的自主 Agent 仍需要借助图论来确定性地引导复杂的多步骤工作流。结合 Better Mortgage 和 Arch 的生产系统实践，他详细阐述了支配树、Tarjan 强连通分量算法（Tarjan's SCC）和传递规约等经典图算法如何压缩庞大的状态空间、消除依赖瓶颈，并为响应时间低于 50 毫秒的语音 Agent 提供动力。Soura 解释说，图结构提供了必不可少的确定性护栏——用于管理状态流转、检测向量搜索无法察觉的缺失数据，并强制要求可验证的 Fact ID 引用。这些技术共同构成了一个四支柱架构，推动企业级 AI 从审慎的可观测性迈向安全、端到端的生产自动化。 向量 RAG 类似于上下文百科全书，但图论提供了安全引导复杂、零容忍金融工作流所需的确定性地图。 (0:04) 跨越 1,200 多页监管条例的抵押贷款承保规则构成了一个庞大的可达状态空间（约 10^140），无法通过暴力穷举或全部嵌入到 LLM 上下文中。 (5:50) 支配树和强连通分量等拥有数十年历史的图算法能在亚毫秒级运行，可作为 AI 推理 Agent 的确定性工具。 (8:49) 在 Git 合并的构建阶段预先计算不可变依赖图，不仅能实现联合 Agent 推理，还能严格限制人工工作流的循环回路。 (11:15) 传递可达性规约消除了 25% 的冗余依赖边，将 Better 的活跃图从约 5,400 条边缩减至约 1,200 条核心边。 (15:37)

Keith Soura, CTO at Arch and former engineering leader at Better, argues that relying solely on probabilistic Retrieval-Augmented Generation (RAG) is insufficient for regulated financial workflows. To ensure compliance, safety, and speed, AI agents require deterministic graph algorithms to act as steering maps over complex operational and legal state spaces. The Limits of Vector Embeddings in Regulated Systems (0:04) In high-stakes financial operations such as mortgage underwriting and capital movement, non-deterministic similarity searches introduce unacceptable compliance risks. Soura compares vector embeddings to an encyclopedia: useful for retrieving static context, but incapable of deterministically steering an AI agent from point A to point C every single time. Pure vector representations struggle with structural system requirements. Embedding models cannot compute dynamic global paths, prune massive operational spaces, or represent absent data—such as a missing tax form—because non-existent items yield no vectors. Relying on probabilistic semantic proximity as an operational control plane leads to brittle implementations and high token costs. Taming Combinatorial State Spaces Through Graph Pruning (5:50) Navigating regulatory regimes like the 1,202-page Fannie Mae Selling Guide creates astronomical combinatorial complexity. In Better's loan system, mapping roughly 1,800 registered activities, 26,000 fact references, and 200 execution steps per loan yielded a theoretical state space of approximately 5^200 (or 10^140) states—vastly exceeding the number of atoms in the universe. Rather than passing this raw complexity to an LLM context window, the team leveraged classical graph algorithms executing on local compute in sub-millisecond time. Dominator trees prune unreachable states to isolate critical paths, while transitive reduction condensed the active mortgage dependency network from roughly 5,400 raw edges down to 1,200 essential edges. Additionally, Tarjan's algorithm identified five non-trivial strongly connected components, allowing the system to bound necessary human revision loops within strict 30- to 45-day legal closing windows. Deterministic Orchestration in Voice and Autonomous Resolution (18:51) Under Better's architecture, pre-computed static graph artifacts generated during CI/CD enforce valid transitions for LLMs under the rule that 'nothing fires that isn't wired.' During live telephone mortgage applications handled by the voice agent Betsy, the system maintained end-to-end response latencies below 50 milliseconds by dynamically hot-swapping updated subgraph context slices directly into the model context when borrower liabilities shifted, preventing hallucinations. This deterministic wiring also enables automated root-cause diagnosis. When a loan stalled due to an unscheduled third-party credit bureau API outage, the agent queried the upstream dominator tree, verified investor underwriting criteria on the compliance graph, and routed the request through an approved alternative API. The stall was diagnosed and cleared in under one second without human intervention. Graph Topology Across Alternative Investments at Arch (24:37) Applying graph theory to alternative investments at Arch revealed similar structural leverage across an 886-table relational schema ingesting capital calls, distributions, and K-1s. Topological analysis of 725 client nodes showed that 716 belonged to a single connected component, demonstrating that over 50% of underlying portfolio positions are co-held. Resolving data quality for one entity cleans records across a $206 billion network of tracked cash flows. Graph structures also resolve ambiguous legal and financial terms. They disambiguate managing fund entities from access feeder vehicles and enforce strong typing on cash flows, explicitly distinguishing permanent gains from recallable distributions, which often comprise 30% to 40% of returned funds. Furthermore, complex portfolio tasks—such as determining fractional exposure to pre-IPO assets—are evaluated as weighted path traversals with complete primary document provenance. Soura concludes that transitioning from passive agent observability to reliable autonomous action requires four production pillars: fact extraction with source provenance, topological integrity verification, traversal-based analytics, and agents governed by mandatory Fact ID citations. While this architecture confines models to verified rails, the operational overhead of encoding and maintaining massive legal rule sets into dependency graphs remains a demanding prerequisite.

Arch首席技术官兼Better前工程负责人Keith Soura指出，向量检索（RAG）本质上是概率性且非确定性的，犹如提供参考信息的“手电筒”或“百科全书”；但在零容错、强监管的金融与资金流转场景中，AI代理必须依托图论构建的确定性“地图”来进行路径约束与合规推进。 向量检索的局限与金融状态空间的组合爆炸 (0:04) 在房屋抵押贷款与另类投资等强监管领域，纯概率性的语义相似度匹配存在重大风险。以美国房利美（Fannie Mae）长达1202页的《销售指南》为例，海量法规条款相互嵌套且前置条件动态重叠。在Better的代码库中，系统包含超1800个活动节点、约2.6万个事实引用以及约5400条派生边；一笔标准贷款需触及约200个活动，每个活动至少对应5种状态。这使得单笔贷款的理论状态空间达到5的200次方（约10的140次方），数量级远超已知宇宙的原子总数。若试图使用大模型暴力上下文或向量嵌入处理该组合空间，不仅会导致算力成本激增，更无法在数学上保证路径的可复现性与准确性。 Soura总结了向量相似度在复杂系统中的四大核心盲区：全局系统结构必须动态计算而非直接存储；缺失的事项无法生成向量嵌入（系统无法检索尚未送达的文件或未发生的状态）；向量距离不能充当转向控制层；图路径必须作为边界护栏而非僵硬枷锁，既为LLM保留语义推理空间，又阻断其非法的业务跳转。 经典图算法赋能：传递归约与组织拓扑对齐 (8:49) Soura强调，将图论与大模型结合无需发明新的数学理论，而是依靠已验证数十年的经典算法。这些算法在本地运行仅需亚毫秒级延迟，且无模型API调用开销。通过传递归约分析，团队将Better房贷依赖网络中约5300至5400条原始边剪枝至约1200条核心边，去除了约25%具有相同可达性的冗余依赖；利用支配树（Dominator Trees）识别前置瓶颈，可将庞大状态空间收敛为极小的可达子图；借助Tarjan强连通分量算法，全图仅检测出5个非平凡循环，使系统既允许借款人调整预审额度等合理的人工修改循环，又能设定边界防止流程死锁。 在系统工程层面，该依赖图在代码合并时即预编译为与Git哈希绑定的静态不可变工件。利用无监督社区发现算法对运行时路径聚类时，团队发现最大的核心集群包含228个活动，横跨贷款专员、审批员、估价师等6种业务角色。这种代码拓扑与组织边界的映射，推动平台实现了自动化的工作区临时权限分配，消除了跨部门审批壁垒，每年为机构节省数百万美元运营成本，并转化为借款人的利率优惠。 确定性轨道上的AI自愈与毫秒级语音交互 (18:51) 显式依赖图赋予了AI代理亚秒级自主诊断与自愈业务阻塞的能力。Soura分享了一例放款受阻的真实案例：面对停滞状态，AI代理无需漫无目的地检索宽泛的合规手册，而是沿支配树向上反向查询，迅速锁定未满足的收入与征信两项事实依赖，并排查出主征信机构API正处于非计划停机维护。随后，信贷代理遍历二级市场投资人合规图谱，确认该贷款允许采用备选征信方案，随即自动调用备用接口补全事实数据，整个自愈闭环在不到一秒内完成，阻碍放款的条件随之解除。 这种低延迟图推理同样支撑了全自动语音代理Betsy的落地。为保证自然电话沟通，Betsy端到端处理延迟必须严格控制在50毫秒以内。当异步征信数据流入，或借款人在通话中随意提及新增资产或负债（例如“刚买了一艘游艇”）时，图引擎即时重新计算债务收入比（DTI），并将受影响的局部子图切片热插拔注入到LLM的当前上下文窗口中。在“未连线即不触发”的原则约束下，LLM既发挥了自然语言理解与同理心沟通的优势，又受到拓扑轨道的物理限制，杜绝了虚构贷款条款或遗漏法定义务的风险。 另类投资图谱扩展：穿透暴露与缺失检测 (24:37) 在另类投资平台Arch，图论被用于解析海量跨机构私募基金的非结构化PDF（包括出资催缴、分红分配和K-1税表），并映射至包含886张数据库表的底层关系架构中。系统将有限合伙人（LP）与普通合伙人（GP）建模为二分图。对725个客户节点的拓扑分析表明，其中716个归属于同一个巨型连通分量，超过50%的底层投资头寸由平台内不同客户共同持有。这种“命运共同体”特征意味着，针对单一基金实体的数据校准能即时向外扩散，实现对2060亿美元实际资金流动的高效校验。 此外，系统在边与节点上实施强类型定义，将普通现金回报与占比达30%至40%的“可召回分红”严格区分，并在图中解耦资产管理GP与其专属支线/联接基金载体。当查询对特定未上市企业（如SpaceX）的真实穿透敞口时，系统将其转化为沿着有向加权路径相乘的遍历计算，每一步骤均附带不可篡改的原文档出处。针对向量检索无法识别“缺失数据”的缺陷，图谱依托同类群体的完成度推断出未送达的税表，并自动触发外联代理向基金管理人催缴，使非结构化数据管理转化为确定性动作。 Soura认为，面向复杂金融业务的生产级AI架构包含抽取（沉淀完整来源链）、验证（图拓扑交叉校验）、分析（基于路径遍历的穿透计算）与自主执行（监听图增量事件）四大支柱。运行时图投影完全基于单一体系统一派生且可随时重建，代理生成的每一项决策或输出均必须引用具体的Fact ID与推导子图，未引用的操作会被系统守卫直接拦截。这种将概率性推理锚定在确定性图轨道上的架构，标志着AI系统正从被动的“观察监控”转向具备监管可追溯性的自动化生产落地。

## Background 该视频由 Ai4 于 2026 年 8 月 19 日在 YouTube 平台发布。内容记录了 Arch 首席技术官、Better 创始工程师 Keith Soura 的主题演讲，深入探讨了为何在复杂的企业级金融与信贷合规场景中，单纯依赖 RAG 检索如同拿着手电筒查百科全书，AI 智能体必须依托图论构建确定性的业务“地图”才能实现精准导航与可靠执行。 ## TL;DR 演讲围绕“在确定性轨道上运行概率性推理”这一核心架构哲学展开。Keith Soura 结合 Better Mortgage 将 1,200 页房贷规则编码为超大规模活体依赖图，以及在 Arch 另类投资平台中穿透管理 2,060 亿美元资金图谱的实战经验，揭示了 RAG 向量相似度在处理状态空间爆炸、动态依赖和缺失数据感知上的致命缺陷。通过将支配树、介数中心性与强连通分量等经典图算法封装为智能体工具，并结合 Fact ID 强制引用与状态机防护栏，系统能够在秒级内实现精准排障与合规证明，推动 AI 真正走向端到端的生产自动化。 ## Atmosphere & style 演讲开场幽默自嘲，主讲人调侃自己钻研数学原为避开社交却被推上台演讲，瞬间拉近了与技术听众的距离。随后，通过引用卡尔·萨根式的宏大视角与祖父在 IBM 总结的工程格言，整场分享迅速沉浸入硬核、严谨且极具工业实战厚度的技术布道氛围中。演讲风格犀利、节奏紧凑，既有对盲目堆砌 RAG 做法的透彻剖析，也洋溢着重拾经典计算机科学工具赋能现代 AI 的工程师激情。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=4s) 单纯依赖向量检索（RAG）像查阅百科全书，擅长语义匹配但缺乏确定性路径规划能力；在强监管的金融场景中，必须引入图论构建确定性地图以保证合规与可复现性。 - [02:14](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=134s) 房贷等复杂金融规则充斥着庞大的交叉依赖和例外跳转，Better 通过将 1,200 多页法规离散化编码为由“事实”与“活动”构成的活体依赖图来进行管理。 - [05:13](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=313s) 一笔普通房贷的理论状态空间高达 5^200（远超宇宙原子总数 10^80），若无序全量送入向量数据库在工程和成本上皆不可行，破局关键在于依赖图的拓扑剪枝。 - [08:49](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=529s) 经典图论算法（支配树、介数中心性、Tarjan 强连通分量等）具备亚毫秒级计算性能，将其封装为 LLM 工具可为智能体提供坚固的确定性推理能力。 - [11:15](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=675s) Better 采用联邦证据架构，在 Git Commit/Merge 时将图拓扑编译为静态工件，使图谱充当确定性导航层，并与生产 DB、RAG 及运行指标解耦协作。 - [15:37](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=937s) 通过传递性触发图剪枝，系统将原始依赖边从 5,300 多条精简至约 1,200 条，不仅避免了上下文窗口爆炸，还通过社区发现算法直接映射并赋能了跨角色组织架构。 - [18:51](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1131s) 在处理贷款卡单等异常时，确定性 Agent 沿依赖图向上遍历可在 1 秒内精准定位缺失依赖，并自动查询备用渠道完成合规修复。 - [21:26](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1286s) 实时语音 Agent Betsy 依托图拓扑建立了确定性防护栏，遵循“未连线者皆不触发”原则，在保证低延迟自然交互的同时杜绝幻觉与非法操作。 - [24:37](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1477s) 图架构成功跨界迁移至另类投资平台 Arch，将由 LP、GP 和资产构成的复杂资金流动与税务凭证转化为可穿透、可遍历的实体图谱。 - [31:21](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1881s) 向量嵌入只能表示“存在”而无法表达“缺失”，图谱通过群组分析和拓扑预期能够精准推导出未送达的 K-1 税表等缺失文件并自动触发追缴。 - [34:17](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2057s) 系统通过规范事实库与 Fact ID 强制引用机制构建防护，Agent 的每句输出必须绑定事实 ID，向监管机构证明推理链具备数学确定性与百分之百可复现性。 - [36:16](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2176s) 围绕提取、验证、分析、敞口与绩效四大支柱，图驱动架构使溯源链直接内嵌于遍历路径中，摆脱海量 Prompt 上下文与人工在环瓶颈，迈向生产级端到端自动化。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=4s) RAG 的局限与金融合规中的确定性需求 演讲者 Keith Soura 首先幽默地调侃起自己的数学背景：他在学校钻研数学主要是为了“避免与人类打交道”，而他的老板却执意派他来参加大会，打破了他“坐在角落敲电脑”的理想生活。Keith 现任替代投资平台 Arch 的首席技术官（CTO），同时也是数字抵押贷款银行及金融软件提供商 Better 的董事会顾问、前工程主管兼创始工程师。他本次演讲的核心议题聚焦于当前企业级 AI 最流行的范式——检索增强生成（RAG），以及它在强监管、重确定性的金融场景中所面临的严峻边界。 ```mermaid flowchart LR accTitle: RAG 与图论导航的对比 subgraph RAGMode["RAG 模式（百科全书）"] R1["向量相似度检索"] --> R2["非确定性上下文"] R2 --> R3["路径不可复现 / 无法验证"] end subgraph GraphMode["图论模式（确定性地图）"] G1["实体与依赖图谱"] --> G2["确定性遍历路径"] G2 --> G3["可证明的合规与执行"] end ``` 在涉及资金流转的金融业务中，单纯依赖相似度检索存在致命缺陷。RAG 擅长寻找语义相关的上下文，但由于底层大语言模型的非确定性本质，直接让其接管关键业务操作无异于灾难——“你绝不会想把控制权交给一个非确定性系统，让它把 1,000 万美元从一个银行账户转到另一个账户，这体验太糟糕了（That's a bad vibe）。”企业真正需要的是一条确定性的行动路径，既能让智能体以自然的交互方式与用户沟通或自动化后台流程，又能确保每一步在数学与工程上百分之百可验证。 - **百科全书 vs. 地图**：向量嵌入与 RAG 就像一本详尽的百科全书，包含海量事实信息，但无法规划从起点到终点的可靠路线；图论（Graph Theory）才是能够保证每次都沿着同一路径精准达成的“确定性地图”。 - **合规底线**：在信贷核保（Underwriting）等受联邦严格监管的领域，任何决策流程都必须具备可解释性与可重复性，这是概率性模型单独无法满足的。 --- ### [02:14](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=134s) 房贷业务的复杂网络：从 1,200 页规则到代码化 为阐明图模型在复杂业务中的价值，Keith 回顾了大约 8 年前创立 Better Mortgage 时的探索。在美国购买房产是一个极其繁琐且充满压力的“拜占庭式”流程，充斥着海量文书、信用审查与多方博弈。相比之下，在联合创始人之一的故乡冰岛，购房流程仅需约 1 小时：买卖双方直接走进银行，填写少量表格，完成审核并转账即可。Better 的初衷便是打破美国房贷的繁冗现状。 然而，美国房贷体系受制于跨越数十年的庞大法规网络。这些规则交织着联邦、各州、地方乃至特定市镇（如纽约市）的法律，并按贷款产品类型细分（如退伍军人贷款、USDA 农业贷款、FHA 贷款等）。更具挑战的是，这些规则并非清晰的清单或 Excel 表格，而是动辄上千页的法律 PDF 文件。例如房利美（Fannie Mae）作为美国常规住房贷款最大的二级市场买家，其 2024 年度的《销售指南》（Selling Guide）整整有 1,202 页，完全由庞大的律师团队编写。 ```mermaid flowchart TD accTitle: 房贷规则交叉依赖关系 P400["指南第 400 页<br/>信用财务数据收集规则"] --> Decision{"信用报告是否触发<br/>例外条件？"} Decision -- 是 --> P900["指南第 900 页<br/>例外重置条款（PDF GOTO 跳转）"] P900 --> P400 Decision -- 否 --> Proceed["继续正常核保流程"] ``` 规则之间的相互交叉与条件覆盖极其复杂。例如指南第 400 页规定了收集信用财务数据的具体流程，但翻到第 900 页，又会指出若信用报告中出现特定情况，第 400 页的某些规则就会失效，必须倒退重走流程——这就像是古老代码中不可控的“PDF GOTO 语句”。在没有现代大模型辅助的 8 年前，Better 的工程师们只能叫上中餐外卖，围坐在纽约昂贵的办公室里，一行行将这 1,200 多页的复杂规则全部离散化地硬编码进系统。 --- ### [05:13](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=313s) 事实与活动：超越宇宙原子数的庞大状态空间 这场规则编码的最终产物，演化成了一套由“事实（Facts）”与“活动（Activities）”构成的超大规模活体依赖图（Living Dependency Graph）。事实构成了关于借款人已知或可推导信息的状态图，而活动则是对这些事实做出响应并触发具体操作的执行单元： - **双向交互**：活动既消耗事实，也受特定事实状态触发（例如借款人的债务收入比 DTI 超过阈值时，自动触发要求提供解释信的活动），同时活动执行后又会产生新的事实并写回图谱。 - **现网图规模**：系统登记了约 1,800 个业务活动（日常活跃调用的超过 1,100 个），包含近 26,000 个离散的事实引用，以及从代码中推导出的近 5,400 条活动间依赖边（Activity-to-Activity Edges）。 ```mermaid flowchart LR accTitle: 事实与活动状态机循环 F1["已知事实 (Facts)<br/>（如收入、资产、负债）"] --> A1["触发业务活动 (Activities)<br/>（如拉取信用报告、计算 DTI）"] A1 --> F2["生成新事实 (Derived Facts)<br/>（如 DTI 超标预警）"] F2 --> A2["后续纠偏活动<br/>（如要求借款人说明资金来源）"] ``` 这种庞大结构带来的状态空间是极其骇人的。Keith 引用了他最崇拜的卡尔·萨根（Carl Sagan）式的宏大视角：一笔典型的房屋贷款通常会触及约 200 个活动，每个活动平均具有 5 种以上的状态，这意味着单笔贷款的理论状态空间高达： $$5^{200} \approx 10^{140}$$ 作为对比，整个可观测宇宙中的原子总数仅约为 $10^{80}$ 左右。一笔几十万美元的普通贷款，其潜在状态组合在数学上竟远超宇宙原子总量数十个数量级。如果试图将这种无序的状态空间全量送入向量数据库做嵌入与检索，不仅计算开销会引发 CFO 的愤怒，在工程上也毫无可行性。所幸在实际业务中，绝大多数状态对于个体借款人而言是不可达的。破局的关键在于利用图结构在特定节点进行精确剪枝，这是单纯的向量嵌入无论如何也做不到的。 --- ### [08:49](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=529s) 经典图论工具箱：让智能体拥有确定性地图 Keith 指出，当前 AI 领域的许多突破并不是因为发明了全新的底层数学，而是现代算力终于使得几十年前的经典计算机科学成果得以高效落地。他回忆起自己的祖父——一位曾为 IBM 大型机设计了 40 年装配线的物理工程师，常说“工程师的水平取决于其工具的优劣（An engineer is only as good as his tools）”。几十年来图论领域积累的经典算法，正是现代 AI 智能体最坚固的工具箱。 | 图算法 / 结构概念 | 在智能体系统中的核心用途 | 业务收益 | |:--- |:--- |:--- | | **支配树 (Dominator Trees)** | 识别哪些前置活动严格把守（Gate）后续状态 | 阻断不可达路径，将天文级状态空间骤降至实时可用级别 | | **介数中心性 (Betweenness Centrality)** | 发现流量是普通节点 4 到 6 倍的承重节点（Load-bearing Nodes） | 为智能体提供无需盲目遍历的确定性搜索切入点 | | **瓶颈与阻塞点检测 (Choke Points)** | 快速定位吞吐量异常受限的关键环节 | 指引智能体或人工核保团队优先实施流程优化 | | **强连通分量 (Tarjan's SCC)** | 圈定并隔离具有循环修改依赖的业务子图 | 允许合规修改循环的同时保证全局流程有界收敛 | 这些图算法具备压倒性的工程优势：计算逻辑完全确定、计算成本极低，且几乎所有算法在现代开源图计算库中都能以亚毫秒级（Sub-millisecond）的速度在大型图结构上完成运算。将它们封装为智能体可直接调用的确定性工具，智能体便能在近乎实时的交互中做出高精度决策。 --- ### [11:15](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=675s) 联邦证据架构与静态图谱提供者 Better 围绕图引擎构建了一套支持智能体进行确定性推理的联邦证据架构（Federated Evidence Architecture）。整个系统围绕一个统一的推理主循环（Reasoning Loop）运转，图谱与各类生产数据源作为插件化的证据提供者（Providers）接入： ```mermaid flowchart TD accTitle: 智能体推理与联邦证据提供者架构 subgraph Core["核心决策层"] RL["统一推理主循环<br/>(Reasoning Loop)"] end subgraph MapLayer["确定性导航层"] GP["图谱提供者 (Graph Provider)<br/>在 Git Commit / Merge 时编译静态拓扑"] end subgraph DataLayer["动态证据提供者 (Federated Evidence)"] P1["传统向量嵌入 (RAG)"] P2["生产数据库 (Production DB)"] P3["系统可观测性数据 (Observability)"] P4["实时用户行为监控 (Live Telemetry)"] end GP --> RL P1 --> RL P2 --> RL P3 --> RL P4 --> RL ``` - **编译期构建图谱**：图结构并非在运行时动态昂贵生成，而是在代码合并（Merge）阶段作为 CI 构建产物直接编译生成。每个 Git Commit Hash 对应唯一的图拓扑静态工件，智能体通过匹配 Git Hash 即可瞬时确认自身掌握的信息是否为最新版本。 - **职责分离**：图谱提供者专职充当“地图”，而传统向量检索、生产数据库、运行指标及用户实时操作轨迹等其他提供者则补充具体业务事实，二者解耦且支持灵活插拔。 --- ### [13:11](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=791s) 环路处理、信用子图瓶颈与图剪枝机制 房贷业务具有严格的时间法律约束。以房利美常规贷款为例，整个流程从发起到完成必须在 30 至 45 天内闭环，期间还分布着多项法定倒计时。一旦超时，贷款不仅会失去利润，银行还可能面临法律诉讼。因此，精准识别流程中的瓶颈与死循环至关重要。 ```mermaid flowchart LR accTitle: 传递性触发图剪枝 subgraph Detailed["详细底层执行路径"] A["活动 A"] --> B["活动 B"] B --> C["活动 C"] end subgraph Pruned["智能体宏观规划视图"] A_prime["活动 A"] == "传递性跳跃 (直接剪枝中间态)" ==> C_prime["活动 C"] end ``` 许多人倾向于将工作流理想化为有向无环图（DAG），但现实业务中不可避免地存在修改循环（Revision Loops）。例如借款人在看房时，常需根据纽约房产中介的要求反复微调预审资格信（Pre-qualification Letter）的额度，以防拿着 100 万美元的资格信去买 60 万美元的公寓而丧失议价空间。通过运行 Tarjan 强连通分量算法，工程团队在巨大的图谱中仅识别出 5 个非平凡的强连通分量，从而成功圈定并打破了潜在的无限循环，保证了业务闭环。 - **信用子图的倍增瓶颈**：拓扑分析揭示，信用审核（Credit）子图中的任何微小延迟，都会在全局贷款流程中引发高达 **6 倍** 的链式延误，成为导致贷款无法按时交割（Close on time）的首要元凶，进而损害买家、卖家、中介及银行全链条的利益。 - **触发图传递剪枝（Triggering Graph Reduction）**：当系统存在 $A \to B \to C$ 的级联触发链时，智能体在宏观路径规划时可以直接建立 $A \to C$ 的抽象跳跃，将中间繁杂的过渡状态剥离，待后续异步按需加载，如同在数字地图中灵活切换缩放层级（Zoom out），大幅降低了上下文开销与推理延迟。 ### [15:37](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=937s) 图剪枝与拓扑对齐：从代码结构到组织架构 通过对图进行约简与剪枝，图遍历的效率、速度和成本都得到了质的飞跃。在房贷业务的真实案例中，经过约简后，原本庞大复杂的图结构从 5,300 到 5,400 条边骤降至约 1,200 条边。由于四分之一的边具有完全相同的可达性，系统可以直接在合并时（Merge Time）移除冗余关系，无需将它们塞入主推理循环。若仅靠传统的向量嵌入（Embedding），即便将文档、知识、队列、提示词和工具全部向量化，也根本无法指导系统如何精简推理闭环，最终只会导致上下文窗口在对话中迅速爆炸。 更具启发性的是，团队使用社区发现算法为工作流图着色，在完全未输入任何组织结构先验知识的情况下，仅凭代码中的实际工作流拓扑，就直接映射出了公司的组织架构。如果团队结构与应用拓扑完美契合，图表上的每个条形原本应为单一颜色，但现实中却呈现出复杂的交错。以一个包含 228 个独立活动的集群为例，实际业务中有 6 种不同角色（结算员 Closers、处理员 Processors、估价师 Appraisers、法务/披露团队、贷款专员 Loan Officers 以及持牌核保员 Underwriters）共享该处理路径。 ```mermaid flowchart LR accTitle: 拓扑对齐与自动权限解耦流程 subgraph S1["图拓扑分析"] A["5,300+ 原始依赖边"] --> B["消除同等可达性冗余"] B --> C["约简至 ~1,200 条核心边"] end subgraph S2["社区发现与角色聚类"] C --> D["识别出 228 个活动集群"] D --> E["跨越 6 种核心角色与法务边界"] end subgraph S3["组织协同赋能"] E --> F["动态按工作群授予临时权限"] F --> G["消除跨部门繁琐审批流程"] end ``` 这种拓扑分析带来了意想不到的管理红利： - **消除权限审批痛点**：员工在处理某个具体贷款文件时，只要处于相应的工作集群内，系统就会动态自动授权，无需繁琐的人工审批。 - **巨大的财务与业务收益**：当这种微小效率提升扩展到数以万计的贷款专员时，每年能为企业节省数百万美元的用工成本，并能直接转化为提供给借款人的利率优惠。 --- ### [18:51](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1131s) 诊断卡单：图遍历与确定性代理在秒级内的闭环排障 在真实的房贷流程中，贷款中途卡单（Stuck Loan）极为常见。若使用传统的 Embedding RAG，系统只能检索出《房利美售楼指南》中的通用规范或内部政策，泛泛解释“贷款通常为什么会卡住”，却无法诊断眼前这笔特定贷款究竟为何无法进入结算环节。而依托依赖图（Map），系统只需要发起一次探测查询感知异常，再发起一次图遍历向上追溯，即可精准定位阻塞的活动及其未满足的事实依赖。 在一次真实的排障场景中，系统沿着支配树快速锁定核心作业分支，排查出卡单由两项潜在依赖导致：收入核实与征信报告。随后代理对这两个目标系统发起定向查询，发现征信机构的 API 正在进行非计划停机维护。 ```mermaid flowchart TD accTitle: 征信依赖受阻时的自动图遍历与切换 A["贷款在结算阶段卡单"] --> B["沿图向上遍历阻塞节点"] B --> C["定位到缺失征信报告依赖"] C --> D{"主征信机构 API 是否在线？"} D -- "否 (非计划维护中)" --> E["触发信用报告智能代理"] E --> F["遍历投资人规则图校验替代方案"] F --> G["调用备用征信 API 并回填事实"] G --> H["全图状态刷新 / 异常解除 (< 1秒)"] ``` 整个解决过程丝滑且完全自治： - 智能代理发现主 API 宕机后，并未停滞，而是自动检索图中的投资人规则，确认当前购买该贷款的投资人是否允许使用备用征信拉取渠道。 - 确认合规后，代理顺着集成图找到可用的备选 API，完成征信拉取并插入数据。 - 整个图状态瞬间刷新，阻塞条件随之解除，全过程耗时**不到 1 秒**。 --- ### [21:26](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1286s) 毫秒级语音代理 Betsy 与概率系统的确定性防护栏 在电话销售与服务场景中，低延迟是生命线。许多客户没有电脑或良好的网络环境，但电话人人皆有。为此，公司与 OpenAI 合作推出了实时语音代理 "Betsy"，能够在线完成身份验证、借款申请录入直至预批的全流程。语音交互要求整体延迟必须远低于 50 毫秒，在面临状态空间极为庞大的房贷场景时，图架构发挥了决定性作用。 当用户在电话中交流时，系统在后台异步流式拉取征信数据并动态重算关键的“债务收入比”（DTI）。整个推理链路展现出极强的动态响应能力： - **异步数据驱动上下文更新**：若通话过程中收到外部征信机构推送的新增负债通知，图引擎会立即触发 DTI 重新计算，并将这一全新的子图上下文直接注入 Betsy 的上下文窗口，无需代理反复轮询外部 API。 - **处理口头未预期披露**：当被问及“是否有其他债务”时，如果借款人随口提到“我刚买了一艘游艇”（尚未体现在当日征信报告中），系统会立即在依赖图上设置占位符（Placeholder）和等待条件。 正如演讲者强调的那样：“Nothing fires that isn't wired”（未连线者皆不触发）。这种将大语言模型（LLM）严格绑定在图上的机制，成功在概率性（Probabilistic）模型之上构建了确定性（Deterministic）控制层。LLM 可以自由发挥自然语言表达能力，但由于受到图路径的刚性约束，它绝不可能编造图上不存在的事实，更无法执行非法操作或提出合规之外的问题。 --- ### [24:37](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1477s) 跨界另类投资：在 Arch 构筑资金图谱与消除循环依赖 图理论工具不仅适用于房贷，同样能够跨领域迁移。在转向专注于另类投资（Alternative Investments）的平台 Arch 后，演讲者发现系统内同样存在庞大的代码循环依赖，于是立即使用 `Madge` 等工具进行循环消除，并将图分析深度植入到持续集成（CI）流水线中。 在业务端，另类投资涉及大量的资本金划拨（Capital Calls）、收益分配（Distributions）以及合伙企业税务文件（K-1 表格）。数十万家私募基金定期以 PDF 图片或扫描件形式发送报告。Arch 的底层架构包含约 886 张数据库表，其本质就是一个由 LP（有限合伙人，持有端）和 GP（普通合伙人，发行端）构成的复杂关系图谱。 ```mermaid flowchart TD accTitle: 另类投资领域的数据穿透与图谱流向 subgraph Ingestion["非结构化原始凭证"] D1["PDF 扫描件 / 报告"] --> E1["实体解析与事实抽取"] D2["K-1 税务表格"] --> E1 D3["资本金划拨通知"] --> E1 end subgraph CoreGraph["核心图谱关联 (716 个实体组成的连通大组件)"] E1 --> G1["资金穿透流向 (总计约 $206B)"] G1 --> G2["头寸共同持有识别 (约 50% 共同持有)"] G2 --> G3["多级出资穿透与曝光度分析"] end ``` 通过对 725 个客户节点的抽样分析显示，其中多达 716 个节点构成了一个巨大的单连通分支： - **数据质量风险共担**：分析表明近一半的投资头寸属于多方共同持有。在另类投资中，只要修正了一只基金或一项投资的数据质量，就能同时惠及持有该头寸的超过半数客户。 - **穿透自报数据的“资金之河”**：传统机构往往直接 Embedding 基金经理的自报估值数据，而 Arch 追踪的是由约 716 个实体间流动构成的约 2,060 亿美元真实资金网络，记录资金在账户间的真实划转与回流。 --- ### [28:36](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1716s) 穿透敞口计算与缺失数据的图谱推理 在复杂的另类投资网络中，准确的数据类型标注（Type System）至关重要。例如，“可召回分配”（Recallable Distribution）虽然表面上是打入账户的资金，但其中 30% 到 40% 的金额未来可能被基金随时召回。如果没有图谱类型的严格约束，LLM 可能会误将其算作可用净收益，导致客户误判自身财务状况。 通过图谱解析基金与管理机构的真实从属关系后，诸如“我对 X 公司的实际穿透风险敞口（Exposure）是多少？”这类极为复杂的金融问题（例如在 SpaceX 首次公开募股前测算其持仓收益），便彻底退化为了简单的图遍历问题： | 分析维度 | 传统 Embedding / 报表方案 | 图遍历（Graph Traversal）方案 | |:--- |:--- |:--- | | **穿透逻辑** | 检索分散文档，人工或 LLM 拼凑多层基金持仓 | 沿图遍历所有连接投资实体与目标公司的投资路径 | | **计算结果** | 容易发生幻觉或遗漏多层持股折算 | 返回带权重的路径集合，数学计算精确快速 | | **可追溯性** | 难以溯源到具体凭证条款 | 路径上每个跃点（Hop）均附带原始单据 Provenance 标注 | | **缺失数据感知** | 无法准确检索“不存在”的事实 | 通过拓扑断链与依赖约束，明确感知缺失的税务单据 | 在面对海量私募基金的 K-1 税务报表等核心材料时，传统基于文本相似度的 Embedding 完全无法回答“当前缺少了哪些尚未寄达的必要文件”，而依赖图则能凭借拓扑结构的完整性定义，精确锁定缺失的数据节点。 ### [31:21](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1881s) 缺失状态的检测：为什么向量检索无法表达“缺失” 当一家机构在 2,000 个不同的投资工具中拥有资产，且理论上应当收到 2,000 份税务报表时，如何判断自己是否漏掉了某一份？如果单纯依赖传统的 RAG 向量嵌入（Embedding），未到达的文件根本不存在于数据库中——“缺失”形成的是一个上下文黑洞，系统对此无能为力。但在一个编码了预期（Expectations）的图结构中，可以通过群组分析（Cohort Analysis）基于当前投资组合的全貌，以确定的置信度推导某份文件是否应当存在。这正是 Agent 回答客户高频核心诉求（如“我的税表在哪里？”或“我能不能报税了？”）的基础。 ```mermaid flowchart TD accTitle: 缺失文件的图拓扑推导与催缴流程 subgraph Portfolio["投资组合预期与群组分析"] P1["已确认 12 笔关联投资"] --> ARR["11 份 K-1 税表已送达"] P1 --> EXP["预期：应收到第 12 份 K-1"] end subgraph AgentAction["确定性触发与执行"] ARR & EXP --> DET{"拓扑推导发现缺失"} DET --> AG["触发 Agent 催缴机制"] AG --> ADM["向基金管理人自动催要 K-1"] end ``` 这种推导无法仅靠静态的 Cron 定时任务加 SQL 语句完美实现。现实中的投资结构随时在变动，静态检查清单根本无法捕捉动态变化的预期；真正的预期必须由图谱上同类节点（Peers）的状态推导而来。例如，只有当底层组合中的其他 11 份 K-1 表格已按时归档，系统才能确信第 12 份 K-1 处于缺失状态。一旦拓扑推导出确切的缺失事件，就会触发专属的 Agent 自动向基金管理人（Administrator）进行追缴。图谱底座将不确定性的模糊排查，转化为了完全确定性的系统行为。 - **动态预期推导**：不依赖死板的静态清单，利用图谱中同类关联实体的到达情况动态判定缺失。 - **自动化追缴闭环**：检测到缺失 K-1 后，由图事件触发 Agent 执行定向催缴，消除人工排查成本。 --- ### [32:45](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1965s) 向量相似度计算的局限与 Agent 的确定性护栏 依赖纯向量相似度（Similarity）的技术方案在工程实践中存在四大难以克服的硬伤，通常需要堆砌大量补丁代码与高昂的调试成本： 1. **全局拓扑结构无法存储**：全局结构不是静态存放在某处的，而是动态计算出来的。图计算能够将庞杂的状态泛化并剪枝，使其成为系统可高效消费的形态。 2. **缺失没有向量嵌入（Absence doesn't have embedding）**：向量空间只能表示“存在”，无法表示“缺席”。当关键事实丢失时，没有嵌入向量能直接告诉 Agent 发生了什么。 3. **图谱指导并非过度死板的死锁约束**：为 Agent 划定图谱边界并不意味着剥夺 LLM 的语义解释与推理能力。如果把 Agent 限制得毫无灵活性，购买 Token 的推理价值就荡然无存；正确的方法是通过图拓扑交叉校验，在保留推理能力的同时，杜绝让公司陷入监管合规风险的错误路径。 4. **向量不能作为转向层**：语义相似度不能充当底层的控制逻辑，必须由图拓扑来担当确定性的转向轨道。 演讲者指出，核心架构哲学是将**概率性的推理系统建立在确定性的轨道之上（Probabilistic reasoning on deterministic rails）**。 --- ### [34:17](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2057s) 确定性轨道：Fact ID 强制引用与合规可证明性 为了确保 Agent 在高监管行业中的安全落地，系统构建了多层防护机制： ```mermaid flowchart LR accTitle: 规范化事实引用与状态机安全架构 subgraph GroundTruth["单一事实来源与投影"] SSOT["单一规范事实库<br/>(Canonical System of Record)"] --> PROJ["可重构实体图投影"] end subgraph Execution["受控推理与监管拦截"] PROJ --> FID["可引用 Fact ID 与推导子图"] FID --> AGENT["Agent 推理与输出"] AGENT --> GOV{"治理模型 / 监听器检测"} GOV -- "无合法 Fact ID 引用" --> STOP["立即阻断 (Off the table)"] GOV -- "合法状态转移" --> ACT["执行下游动作"] end ``` 系统确立了单一的规范事实库（Canonical System of Record），所有图谱都只是该记录系统的投影，可随时丢弃并重新构建。无论是 Agent 之间的自省交互、多 Agent 协作还是与人类对话，治理模型（Governance Models）和监听器都会强制执行一条铁律：**Agent 表达的每一句话，必须回溯并引用具体的事实 ID（Fact ID）**。所有事实的推导过程（Derivations）都保存在子图中，任何无法提供有效 Fact ID 引用的陈述都会被判定为非法并立即阻断。 Agent 可以执行的动作只能来自于图谱预先定义的专用状态转移（Dedicated Transitions）。“你永远不给它错误的岔路，它就绝不可能走错路。”演讲者调侃自己的命名习惯——在 Better Mortgage 叫 Betsy，在 Arch 叫 Archie，就是把公司名末尾加个“y”——但这种架构带来的业务价值极其严肃：它使得团队能够向 Fannie Mae（房利美）等监管机构证明，AI 在受监管推理链（Regulated Reasoning Chains）中的每一步推导都具备确定性的数学证明，且在相同版本和数据下百分之百可复现。 - **Fact ID 引用制**：Agent 的任何输出均需绑定可追溯的实体事实 ID，否则直接被安全拦截。 - **状态转移硬约束**：通过图拓扑直接限制 Agent 的可选操作集，从物理路径上防止越轨操作。 - **监管可复现性**：满足金融监管要求，实现复杂推理链条的版本化归档与全流程可审计性。 --- ### [36:16](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2176s) 从可观测性迈向全自动生产环境 团队将图驱动的 Agent 架构归纳为四大落地支柱，推动系统从“被动观测与提心吊胆的防护”全面转向“完全自动化的生产环境”： | 支柱 (Pillar) | 在图架构中的具体职责 | |:--- |:--- | | **提取 (Extraction)** | 将非结构化数据提炼为带有完整来源谱系（Full Provenance）的图事实（Graph Facts）。 | | **验证 (Verification)** | 对图中所有的菱形分支结构（Diamonds）进行交叉检查与自动审计，构成核心防御机制。 | | **分析 (Analytics)** | 将复杂业务分析简化为图上的路径遍历（Traversals），实现极低计算开销。 | | **敞口与绩效 (Exposure & Performance)** | 敞口风险与投资表现均在图拓扑上实时计算，保证过程与结果绝对可复现。 | Agent 订阅图上的状态变更事件，并在回复时自动附带指向原始凭证的引用链条（Citation Chains），整个过程直接在正在遍历的图上完成，无需在 Prompt 中塞入海量冗余上下文。这彻底解决了以往必须“人工介入（Human in the loop）”的业务痛点，使得 AI 能够安全、完全自主地接管复杂的生产级业务。 最后，演讲者总结了整个方法论的操作步骤（Order of Operations），并热情呼吁在场的工程师重温图论经典著作，拥抱图驱动的确定性架构：“停止简单的检索，开始进行图的遍历。” - **零额外上下文开销**：溯源链本身就是图遍历路径，无需反复向大模型上下文注入外部巨量文档。 - **生产级自主运行**：凭借可证明的历史执行链与下一步预测链，消除人类在环的瓶颈，实现真正的端到端自动化。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=4s) 你绝不会想把控制权交给一个非确定性系统，让它把 1,000 万美元从一个银行账户转到另一个账户，这体验太糟糕了（That's a bad vibe）。 — Keith Soura > [08:49](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=529s) 工程师的水平取决于其工具的优劣（An engineer is only as good as his tools） — Keith Soura > [21:26](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1286s) Nothing fires that isn't wired（未连线者皆不触发） — Keith Soura > [32:45](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1965s) 缺失没有向量嵌入（Absence doesn't have embedding） — Keith Soura > [32:45](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=1965s) 概率性的推理系统建立在确定性的轨道之上（Probabilistic reasoning on deterministic rails） — Keith Soura > [34:17](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2057s) Agent 表达的每一句话，必须回溯并引用具体的事实 ID（Fact ID） — Keith Soura > [34:17](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2057s) 你永远不给它错误的岔路，它就绝不可能走错路。 — Keith Soura > [36:16](https://www.youtube.com/watch?v=yTTNXxuxJ1s&t=2176s) 停止简单的检索，开始进行图的遍历。 — Keith Soura ## Mentioned Keith Soura, Arch, Better Mortgage, Ai4, Fannie Mae (房利美), Freddie Mac, FHA, VA, USDA, Carl Sagan, IBM, Tarjan's SCC (强连通分量算法), Betsy, Archie, OpenAI, Madge, SpaceX ## Video description Keith Soura - CTO, Arch The default answer in enterprise AI is RAG: chunk it, embed it, retrieve it. But you can have all the information in the world and still be lost. An encyclopedia contains every fact about every city on Earth — it can't get you from New York to Los Angeles. For that you need a map: an origin, a destination, and the ability to chart a course through the territory between them. When your domain is a web of interconnected workflows, entities, and dependencies, embedding similarity is the encyclopedia. Graph theory is the map. This talk shows what happens when you hand an AI agent the map, drawn from production systems at two companies in two very different corners of finance. At Better Mortgage, home lending is byzantine: the Fannie Mae Selling Guide alone is 1,200+ pages, before layering on Freddie Mac, FHA, VA, USDA, and state regulation. Better's platform encodes it all as a living dependency graph — tens of thousands of constantly-changing facts steering nearly 1,900 automated workflow activities through more than 25,000 declared dependency references across a dozen business domains. A typical loan touches \~200 activities with five or more states each: a reachable state space a factor of 10^60 beyond the number of atoms in the universe. No human — and no vector database — can hold that in its head. But graph algorithms published decades ago — betweenness centrality, strongly connected components, community detection, dominator trees — become extraordinary when handed to an LLM as callable tools: an agent that pinpoints the load-bearing single points of failure in the credit pipeline, proves more than three-quarters of the dependency structure architecturally redundant, detects organizational misalignment straight from topology, and diagnoses a stuck loan across six live data sources in seconds, for pennies. At Arch, the domain is alternative investments — capital calls, distributions, K-1s, wire verification across hundreds of thousands of positions — and the same pattern holds: one canonical system of record, projected into an entity graph an agent can traverse. Different industry, same architecture, same results — including a 374-file dependency cycle found by the same algorithm that maps loan workflows. The deeper lesson: the graph is not just how the agent sees the system — it's the deterministic steering layer that lets probabilistic AI safely act in domains with no room for error. We'll cover the math, the pluggable provider architecture that federates graph analysis with production data into one reasoning loop, and where this goes next: from observability to production automation. If your domain has dependencies, workflows, or pipelines — it's a graph. Stop retrieving. Start traversing. [Source](https://www.youtube.com/watch?v=yTTNXxuxJ1s)

[0:04] Keith Soura: 你绝不会想把控制权交给一个非确定性系统，让它把 1,000 万美元从一个银行账户转到另一个账户，这体验太糟糕了（That's a bad vibe）。 [8:49] Keith Soura: 工程师的水平取决于其工具的优劣（An engineer is only as good as his tools） [21:26] Keith Soura: Nothing fires that isn't wired（未连线者皆不触发） [32:45] Keith Soura: 缺失没有向量嵌入（Absence doesn't have embedding） [32:45] Keith Soura: 概率性的推理系统建立在确定性的轨道之上（Probabilistic reasoning on deterministic rails） [34:17] Keith Soura: Agent 表达的每一句话，必须回溯并引用具体的事实 ID（Fact ID） [34:17] Keith Soura: 你永远不给它错误的岔路，它就绝不可能走错路。 [36:16] Keith Soura: 停止简单的检索，开始进行图的遍历。

Keith Soura: An encyclopedia contains every fact about every city on Earth — it can't get you from New York to Los Angeles. For that you need a map: an origin, a destination, and the ability to chart a course through the territory between them. Keith Soura: The graph is not just how the agent sees the system — it's the deterministic steering layer that lets probabilistic AI safely act in domains with no room for error. Keith Soura: If your domain has dependencies, workflows, or pipelines — it's a graph. Stop retrieving. Start traversing. [8:49] Keith Soura: An engineer is only as good as his tools. [21:26] Keith Soura: Nothing fires that isn't wired. [28:36] Keith Soura: You should not go on that vacation with that money. You need to keep it in your bank account because someone will be asking for it back. [31:21] Keith Soura: If you've embedded the documents, you just have a hole and you can't really do anything. [34:17] Keith Soura: The actions that the agent performs comes from the graphs' dedicated transitions. So, what you want to make sure is that the agent can't take a wrong turn because you've never given it the road to turn on in the first place.

[0:04] Uh I was just making the joke that I I  spent a lot of time in school studying [0:07] math and specifically to avoid talking to  other human beings. Uh and here we are. [0:13] Uh it's it's my boss was like, "You're going to  a conference." I'm like, "No, I live in a corner [0:16] with a computer. That's not what we're doing."  But here we go. Uh so anyway, [laughter] I'm Keith [0:21] Soral. I am the CTO at a company called Arch,  which is an alternatives investment platform. [0:26] Uh and I'm also a board advisor and former head  of engineering and founding engineer of a company [0:31] called Better, which originally was a mortgage  bank and now is actually a software provider [0:36] that owns a bunch of banks across the US and the  UK. And I'm going to be talking a little bit about [0:41] the boundary of everyone's favorite enterprise  AI pattern, which is RAG, and uh regulated [0:47] spaces that need determinism, which is kind of a  weird boundary but an important one when you work [0:52] in finance and you're touching people's money.  So, that being said, let's let's dive right in. [0:59] I'll get my clicker works. Magic. So, one of  the core things about retrieval is it's great. [1:04] RAG works. Everyone knows about it. It's fun. But  the critical problem with it is that it just finds [1:11] context. It finds similarity. And when you are  finding that similarity with a non-deterministic [1:17] system, what you don't want to do is then give  that system control of moving like $10 million [1:21] from one bank account to another. That's  a bad vibe and no one wants to do that. [1:26] What you do want to do is chart a course  of deterministic actions and paths [1:30] that your agents can take while making it seem  like a natural course, whether that's talking [1:35] to a person in a natural way or actually  automating some things back office or both. [1:41] And that is where this combination comes in. So,  you can kind of think of RAG as your encyclopedia, [1:45] your embeddings as your encyclopedia. It has a  bunch of knowledge. It can generally help you [1:49] go from one place to another, but it can't really  chart you from A to C very efficiently. And more [1:56] critically, it can't get you from A to C along the  exact same path, provably, every single time. And [2:02] that is really important when we start engaging  in activities like underwriting, which are heavily [2:07] federally regulated, and for good reason.  That is where kind of graph theory comes in. [2:14] So, I'm going to start with my first case study,  uh which is Better. About 8 years ago, uh we [2:20] started thinking about home lending and consumer  lending. And if anyone here has purchased a home, [2:26] uh they know that that is not the most  fun process traditionally. Usually, [2:30] there's not a lot of joy. People don't like  to spend that much money. There's a ton of [2:33] paperwork. You're very stressed out. You have to  move. Credit checks. All kinds of things going on. [2:39] Not great. It is a Byzantine process. And a  group of us sat down and thought to ourselves, [2:43] why is it that way? In Iceland, where one of our  co-founders is from, it takes about an hour to buy [2:48] a house. You walk into a bank. You fill out some  paperwork. There's some checks. The other person [2:52] is there. The money's transferred, and you're  done. That's it. No intermediaries. It's just [2:56] a bank. And we thought, why can't we do  that in America? And in New York City, [3:01] which is where I live and where the co-founders of  Better live, as well. We want to fix that problem. [3:07] There are a lot of rules, though. And they've all  been assembled for good reason, but they've been [3:11] been assembled over decades. There are federal  regulations. There's state regulations. There [3:15] are local regulations. There are municipal  ones, like in New York City, they have their [3:19] own set of regulations. They're divided by  the type of product that you're going to get. [3:23] Did you previously serve in the armed forces? Are  you able to get a loan in that nature? USDA farm [3:28] loans. FHA. All kinds of things of that nature.  They all have their own rules. They all intersect. [3:33] And most of the rules are huge legal documents.  They are not beautifully written checklists, which [3:39] is what I love. They are not Excel spreadsheets.  They are not programs. They are 1,200 page PDFs [3:44] that are updated arbitrarily as administrations  roll in and out, and regulation rolls in and out [3:49] from Congress. We're going to talk a little bit  about the most common one, which is from Fannie [3:54] Mae. If anyone knows they're a GSE, they are  probably the most prominent buyer of home loans [3:59] back in for conforming home loans, so the standard  home loan that most Americans use in the country. [4:04] And their selling guide is 1,202 pages this year.  Uh all PDF, all written by a vast team of lawyers, [4:12] who I have to say good things about because  some of them are my friends. [laughter] [4:17] Uh the key the key challenge here is  the interaction between the rules. So, [4:21] I'm going to use Fannie's as an example. There  are some pieces of information on page 400 of [4:27] the selling guide that determine exactly how you  collect financial information related to credit. [4:34] On page 900, however, there's information about  how that could be wrong if you've later found out [4:40] through that credit report that a couple other  things are true. So, you have to go back. It's [4:43] very much a an old-school PDF go-to statement.  That problem was what we aimed to solve. And like [4:51] any good engineer, 8 years ago before the magic  of ChatGPT and Claude and all the other models, [4:58] uh we just sat down and we thought to ourselves,  "Let's order some Chinese food and sit at this [5:02] table that we're paying way too much for in  New York City and just code all 1,200 pages [5:07] discreetly." And we did. It was It was not a  good time. Uh just some of you may imagine. [5:13] But what that left us was a critical system.  We have two things, one called facts, [5:19] one called activities. The facts are also  a graph, and they deal with things that uh [5:26] we might know about a person or we might be able  to compute about a person as we take actions, [5:30] and those actions are the activities.  The activities have the power to both [5:34] accept facts. They can be triggered by certain  things happening. For example, let's say that [5:38] your DTI goes above a certain threshold, we might  trigger an activity that then goes and asks for [5:43] an explanation of why that happened. There are  many valid reasons, but some of them are not, [5:46] and they could interrupt your mortgage process.  We don't want that. We want to find out early. [5:50] They can also [clears throat] add new facts, and  that is where you get your lovely obvious graph [5:56] pattern. It's been in the code the whole time. My  guess is most of you probably have it somewhere, [5:59] too, whether it's in your code or  in your ORM or your migration files, [6:05] anywhere. Could be an Excel spreadsheet,  depending on your business, but it's always there. [6:11] This built a very large living dependency graph.  Although at the time we kind of didn't note it. [6:17] A little bit of spoiler alert there, but right  now, as of uh maybe 6 7 weeks ago, we had around [6:23] 1,800 registered activities. That's that's a lot  of activities, but only 1,100 of them, just over [6:28] 1,100 of them, were actually regularly used. There  were almost 26,000 individual fact references. [6:34] That's a lot of pieces of information. That's  how much data it takes to collate a mortgage in [6:38] America at this moment in time. And almost 5,400  of them were derived activity-to-activity edges, [6:44] meaning that there were activities that triggered  other clusters of activities. And if this sounds [6:49] weird, think about the idea of pulling a credit  report, realizing that your credit score is below [6:53] the credit score that you need for the product,  and us trying to figure out a way to get you [6:56] that loan anyway. There could be five or six  different paths we could take to get you there, [6:59] and we need to figure out which one is best, and  we need to figure out quickly cuz uh if money is [7:04] definitely uh being lost for every moment that we  don't originate. [sighs] These counts are actually [7:09] extracted directly from the code, so they're  not like random numbers. It's fairly large. [7:14] But if we think about this, just and I this is my  Carl Sagan moment cuz he's one of my favorites, [7:19] uh but if you think about this for a minute,  you have 200 activities on a typical loan, [7:23] and this is pulled from our data as well. Each  one of them has about five states. Some of them [7:26] have more than that. Uh so, five to the 200th  power, 10 to the 140th. The state space for a [7:32] single mortgage loan for anything from $50,000 to  $680,000 this year, effectively, is more complex [7:40] than the number of atoms in the universe. That's  That's not great. It's not a good feeling. Uh [7:44] and if you try to embed all of that information,  I guarantee you your bill is going to be terrible [7:49] and your CFO is probably going to not be happy  with you uh when that entropic bill comes due. So, [7:56] let's think about how we can deal with this. The  critical thing is that in that entire state space, [8:00] almost nothing is reachable for most people.  And that's because every person is a little bit [8:05] different financially, but they're all kind  of trying to achieve the same goal. And so, [8:08] what you need to do is start cutting that graph at  really specific places. No embedding can do that [8:13] for you. [sighs] I did a little git blame.  And if any of you in here are also coders, [8:20] you've experienced this moment, too. This is a  quote who I was like reading through the code [8:25] while I was building this presentation. I'm like,  "Wow, we knew that this was going to be a problem [8:28] back in the day. Who did this?" It was me. Uh not  a I also found a couple of bugs that I wrote at [8:33] the same time. So, it wasn't the best git blame uh  excursion, but that's okay. So, we knew that this [8:38] was going to happen. We left it to do. And today,  I'm going to talk about how that to do is now [8:43] done. I've actually deleted this comment from the  code as of now. Feeling pretty great about that. [8:49] Okay. Maybe we can go forward. There we go. So,  none of the math is new. This is the thing that [8:53] I want to talk about. I think that uh with  the AI revolution, LLMs, we talk a lot about [8:58] things that are new. They've unlocked incredible  possibilities. It's really neat. Everyone's really [9:02] excited. I'm excited. But, I think something  that's often lost is that this is not necessarily [9:07] a new discovery. It's a discovery that we finally  have the computing power to take advantage of. [9:12] And like any interesting discovery, there are  decades of research by brilliant human beings [9:18] on how this has been accomplished. And those  decades of research give us a really cool [9:23] toolbox. My grandfather was a physical engineer  who built real things for IBM. He built assembly [9:28] lines for mainframes for 40 years. And always  said, "An engineer is only as good as his tools." [9:33] And that is what I kind of want to talk about  here. I'm not going to go through every single [9:36] one of them and be a a boring math person,  but if anyone wants to geek out afterwards, [9:40] we can meet outside. I've been told that's  the place for math geeking. Um but there's [9:44] a couple of things here that are important. So,  one of the critical things that we want to talk [9:48] about in the presentation is dominators. We  want to find what gates what. That's what [9:52] brings that state space down from something  that's unreasonable and really expensive to [9:56] something that is actually usable by your agents  in near real time or like perceivably real time [10:02] uh by your users and the agents themselves. We  can also use algorithms to help find load-bearing [10:07] nodes. So, let's think about mortgage for a  minute and we'll talk about this a little bit, [10:11] but there are activities that possibly have four  times or five times or six times the throughput of [10:16] other activities. They're essentially clusters.  They're an important load-bearing component of [10:20] this network and they're a really great place  to start searching for things when you don't [10:23] know where to start and that's really helpful.  There are also other places where that number is [10:27] even higher and those are choke points. Those are  places where we can look for optimization early on [10:31] uh and we can point agents or humans at them very  quickly and be generally right most of the time. [10:36] So, it's a good way to start searching. There's  uh algorithms that help us find how those clusters [10:42] come out and we'll talk about that a little  bit in the second case study that I have today. [10:46] And then there are a few other tools which we can  talk about broadly with examples in the following [10:52] slides, but the critical thing here is that all of  these things are deterministic. They're all cheap [10:56] to run. You don't have to pay anybody for them.  Every open-source graph node and every textbook [11:00] on graph theory that you open will describe how  to implement these very very easily, very very [11:04] cheaply and most of them are sub-millisecond  on even very very large structures. So, [11:09] you don't have to worry about latency very much.  You can compute them pretty much on the fly. [11:15] So, let's talk a little bit about the  architecture that we developed at Better. [11:19] I'm sure it's familiar to anybody  who's used agents, but essentially, [11:22] we have one major reasoning loop, but we  have a bunch of federated evidence. So, [11:26] the graph provider that we're going to compute and  we compute this on merge. So, with every Git hash, [11:30] we actually compute this graph. It's easy and fast  to do. It's a nice artifact and then it becomes [11:34] statically referenced by all the agents that  are running it. And we can tell if agents have [11:38] the most recent information because they have the  most recent get hash, which is really important. [11:43] The graph provider is that map. The other four  pieces are whatever real data that you're going [11:47] to be piping in. So, this would be like your  classical embeddings, your production database, [11:51] maybe some observability. We think that that  observability is really important as a guiding [11:55] post. As well as other planning methodologies.  We have real user management in some cases where [12:01] we're allowed to do it, we can see what users  are actually doing and provide that feedback [12:04] to agents that are helping those users live on  the phone, for example. Any of those providers [12:09] swap out for whatever you're using. The only  really important part is providing the map. [12:16] So, every loan runs against a clock. That's is  an important, I guess, timing step to think about [12:21] mortgages. There are legal boundaries. In the  case of the mortgages that we're talking about [12:26] in Fannie Mae, you have between 30 and 45 days  from the beginning of the process to the end. [12:30] There are a bunch of other legal timers  that exist in between those guidelines. [12:33] And if you don't meet those times, you will not  make money on that loan, and you may end up in [12:37] court, which you don't want to do. That's not fun.  [clears throat] So, how do we make sure that we're [12:42] running smoothly? This goes to one of our first  tools that I mentioned. What are our load-bearing [12:47] areas and where are tangles? So, where where  do we have throughput problems? When we ran [12:52] this across all of the activities that we found,  Tarjan's is the the kind of obvious one for this, [12:58] we found only five non-trivial strongly connected  components in the entire graph, this massive [13:03] massive graph. And that was really interesting.  That mean we had five load-bearing structures [13:07] inside of this huge set of possibilities, and  that was what we could point our agents at [13:11] to begin their journey. Really, the point here  that's important is that revision loops exist, [13:18] and everybody likes to talk about DAGs and  how there are no cycles, but in the real [13:22] world there are cycles. In the example of loan  applications, people may go back and edit what [13:26] they need many times for pre-qualification  letters if anyone's ever had to deal with [13:30] realtors, and I'm sorry if there are realtors in  the crowd. Love you guys, too. But, if anyone's [13:34] had to deal with realtors, you might have to have  a pre-qual letter, especially in New York, to even [13:37] walk in the door and see an apartment that you're  trying to buy. You may want to change that number, [13:41] though, because you don't want to walk into a  $600,000 apartment with a pre-qualification letter [13:44] that says $1 million and then try to convince  them to give give you a better price. No one will. [13:48] So, you'll be adjusting this constantly. The trick  is to make sure that those loops are bounded. So, [13:53] what we want to do is actually allow cycles, but  then find where the cycles exist and break them. [13:58] And that is a key part of the structure. The  other thing that's important is the activity [14:04] uh clustering that I talked about. Credit is a  really great example, where what we found was [14:09] that any slowdown in any part of the credit  subgraph resulted in a 6x slowdown in the [14:15] overall origination process. That's really, really  expensive. And in fact, it was one of the leading [14:19] causes of people not closing on time. Not closing  on time is a bad feeling. The seller's upset [14:25] because they're not getting the money, and they  can't move out. The buyer's upset because they may [14:28] may not have a home, and they can't move in. The  realtor's upset because they're not making their [14:32] commission. And everyone that works at the bank is  upset because they're not making their commission, [14:35] either. No one is happy. And then regulators  get involved, and they're even less happy. So, [14:40] it's important to be able to identify those  spots. Using the toolbox allows you to do that. [14:44] It's not something that you could do with  an embedding. You could kind of find out [14:47] what things should look like, but you can't  necessarily find out what they actually are. [14:52] So, let's talk about this in one kind of specific  mechanism, the triggering graph. Uh I think [14:58] most engineers have used triggers before.  Anyone that's used GitHub or GitLab or any [15:02] other thing like that is definitely used  these. But, going through them briefly, [15:06] with a little diagram. So, kind of a  mechanism, and this is the reduction mechanism. [15:10] If A triggers B, and B triggers C, we can also say  that A triggers C. And when we start cutting the [15:15] graph apart to feed to our agents for context, we  can actually remove the middle of the traversal. [15:19] All that matters is the beginning and the end  in this case, because everything in between [15:23] is just kind of additional information  that might be useful and can be loaded [15:27] asynchronously later. It doesn't need to be  loaded or built on the fly. And that gives [15:31] a really nice kind of zoomed out version of the  map of Google Maps if you think of it that way. [15:37] Uh that is a lot easier to traverse, a lot faster  to traverse, and a lot cheaper to traverse. [15:42] The practical part here is what you can do once  you run that reduction. So, the real structure [15:47] is actually only like 1,200 edges once we reduce  in our case for the mortgage, not 5,300-ish, [15:52] not 5,400-ish. That's the graph that the agent  needs to reason about or begin reasoning about at [15:56] high speed, especially uh in our case when you're  doing it on the phone, so you have a voice agent, [16:01] and pausing is very unnatural. A quarter  of those edges have identical reachability. [16:07] That's how we removed them. So, basically,  at merge time, we can tell you whether or [16:11] not a proposed trigger is either already implied  somewhere on the graph and not have to add it into [16:16] the main reasoning loop, or we can do something  to tell you if the equivalent behavior um is [16:23] existent in another downstream subgraph. Now, that  allows you to simplify things a lot. And again, [16:28] from an embedding point of view, you might have  things embedded along that chain, like documents, [16:32] knowledge, queues, prompts, tools, that sort of  thing, but they're not going to actually tell you [16:37] how to reduce the reasoning loop. You're going to  have these massive context windows that are going [16:40] to explode when you start chatting with someone  or when you agent starts reasoning and working. [16:46] So, this is what this looks like for for us. Um  basically, we took this graph and we colored it. [16:52] We found communities based on the way that work  was actually being accomplished in the code [16:58] without giving the system any knowledge of how  the work was supposed to be accomplished or how [17:02] our organization was actually structured, which  is kind of fun. And what we found is that if teams [17:09] match that kind of topology that had been built,  then each bar would be one color. And it's clearly [17:15] I'm I'm pretty color blind, honestly, but that's  not the case. My my marketing department helped [17:18] me do the coloring. I'm very excited about that.  Um but uh that's not the case here. And it tells [17:23] you a couple things about kind of what's going  on and changes that you can make. This is where [17:27] things are crossing over from your application  topology to your organizational topology. [17:33] That top bar is a really great example. 228  individual activities. There are six roles in the [17:39] real organization actually sharing that processing  path. So, we have closers, processors, appraisers, [17:46] all of the disclosures and legal team is involved.  Loan officers are involved, underwriters are [17:50] involved, and those are licensed folks who  have a lot of obligations about this data. [17:54] And it's all in this giant cluster. The challenge  here is how we allow the agent to work across [18:01] all of those different boundaries because some of  them have legal boundaries, permission boundaries, [18:05] and things like that efficiently. And by  finding these clusters, we can actually [18:09] start to decompose our code and reorganize it in  a way that makes it easier to do work. It also, [18:14] frankly, has caused us to reorganize the  way that people work in the organization [18:18] because now you don't have to request access to  things if you're functioning inside of a a group, [18:23] a work cluster. It's automatically granted to you  while you're processing that individual loan file. [18:27] So, just small efficiencies like that can add  up a lot. Uh and when you scale that to tens of [18:32] thousands of loan officers, you're talking about  millions and millions and millions of dollars of [18:37] payroll a year, which also gets passed on to the  borrower as rate discounts and other things like [18:42] that. So, it's really it's really useful to  be able to draw this information out of that [18:45] graph that you've built. It's just kind of a side  effect. So, let's talk about kind of what this [18:51] looks like when we're processing a real loan. I'm  going to use a real example with obviously all of [18:54] the PII stripped out of it. That's very common  going back to credit. We have a stuck loan. [18:59] From an embedding point of view, what we could see  right now is that there is a loan that's stuck, [19:04] and we could probably pull some documentation  from the selling guide as well as our internal [19:07] policies, and probably some information about  how the organization is structured about what [19:12] a loan that's stuck usually looks like, sometimes  why it gets stuck, but we're not able to actually [19:18] tell the agent or person why this particular  loan has failed. Why are we stuck in closing? [19:24] In this case, we're going to miss a closing  because the loan has stopped. What do we do? [19:30] The graph, your kind of map, can actually  help you with this. In this case, you can [19:34] essentially use one query to understand that you  have a problem. It could be a trigger as well, [19:38] depending on how your system set up. And then  you can use one other single query to walk up [19:43] the graph from the condition that you're at to  basically find the stalled activity and its two [19:48] unmet fact dependencies. In this particular case  that I'm talking about, we had a credit report [19:53] that didn't come through as a possibility, and  we also had an income verification that was a [19:57] possibility. I say possibility going back to  the dominators thing, which is all we really [20:02] need to do is figure out where most of the  work is being done on this loan in that query, [20:06] and walk through that part of the graph. You  don't have to do the whole thing, which is [20:10] what makes this possible in kind of a real-time  feel if you're using agents with your customers. [20:16] From there, we just run a couple queries at  those two target systems, right? That's your [20:20] high latency moment. And what you find in this  particular instance, or what we found in this [20:24] particular instance, is that a credit report  didn't get pulled properly because that credit [20:29] agency's API was down for unscheduled maintenance.  So, we found that information, and you can either [20:35] escalate this to a person, or in our case, it  actually kicked off another dependency, which [20:39] is the credit report agent that went and tried to  resolve the credit report. It saw if this credit [20:43] agency's API was up. It was not. It went and it  looked at whether or not we were allowed to use [20:50] other credit report types or other credit pulling  methods to resolve the condition. Different [20:55] investors have different rules about how credit  can be used if they're going to buy the loan. [20:59] It learned that it could do it. It learned there  was another API available by walking the graph [21:03] of integrations that we have. It made the call  and inserted the information, the entire graph [21:08] updated at once, and the condition was  resolved. This took less than a second. [21:13] If you have humans in the loop, obviously  it might take a little bit longer, [21:15] but in this particular case we were lucky, and  that would not have been possible simply with [21:18] embedding. You need the map to tell the agents  where to go and how to do work afterwards. [21:26] So, why does all of this matter to me?  Why does the speed matter? I'm not just, [21:31] you know, an annoying engineer who's  obsessed with latency and perfection. [21:33] It matters because a lot of our interactions  are done through the phone. There are a lot [21:37] of people who don't have time to sit down at a  computer, who may not actually have a computer [21:40] with good internet access or modern browser,  but pretty much everyone has a telephone, [21:44] and they know how to use it, and everyone feels  pretty comfortable talking. So, we introduced [21:48] Betsy. Betsy's a real-time voice agent, and it  was part of a partnership that we had with OpenAI. [21:52] It's an incredible piece of technology. If  you call the the main line at the company, [21:56] you'll actually get to talk to her, so you can  try it out on your own if you're interested, and [21:59] feel free to test her, and if you find any bugs,  email me. [laughter] But, um it matters because [22:04] latency needs to be way less than 50 milliseconds,  and again, that state space was super super large. [22:11] Uh so, how do we deal with that? We want to  let's walk kind of the timeline of this. So, [22:15] a really common example is someone is giving Betsy  a loan application. She can take them online, [22:20] she can authenticate people, and she can actually  process everything through a pre-approval. [22:25] While she's doing this, an incredible thing  that's important for product selection is [22:28] debt-to-income ratio, and we have to pull some  data for DTI. While a person is talking, we are [22:33] pulling down information from a credit report,  we're also getting data from other providers, [22:38] and stream data asynchronously from the  credit providers about other types of [22:42] credit obligations that may be increasing this.  While we're talking, two things can happen. One, [22:47] we can actually receive asynchronous information  during the phone call that tells us that this [22:51] person has additional debt obligations. That's  going to trigger the graph to recompute DTI, [22:56] and what we're going to do, rather than expecting  the agent to keep looping through checking an API [23:00] about DTI and remembering it, we're actually  going to move that entire new subgraph context [23:05] into the agent's context during the  conversation so that it's accessible. [23:11] On top of that, you might have a situation where  someone's talking and we're asking. One of the [23:14] questions that we have to ask is, "Do you have  any other obligations that we should know about?" [23:18] And the person could say, "Oh, yeah, I actually  I forgot. I just bought a boat." Well, it's not [23:22] going to show up on your credit report that day,  but we can try to figure that information out [23:25] and put in placeholders that expect additional  updated information and set waiting conditions [23:30] on that graph. Again, can't really do that  with embeddings. That's pretty exciting. [23:37] This is what this looks like. This is not  a simulation. This is actually this firing [23:43] on the real graph with colors that again my  marketing team added for me because this is [23:47] all black and white when I did it. But essentially  what you can see here is that a trigger occurs. [23:53] It immediately cuts the graph into segments.  It only touches the portions of the graph that [23:58] actually subscribed updates on those facts. And  then you have one small slice of a very very [24:04] large state space. So, nothing that fires nothing  fires that isn't wired. And that is the critical [24:10] component that goes into case study two, which  is it's how you create determinism on top of [24:15] a probabilistic system. The LLM can still speak  to someone in the language that they understand. [24:19] It can still think about different ways to  approach a problem, but it can never misstate [24:25] the information that's being presented to it  along that graph. And it can't take wrong turns [24:29] that are illegal. It can't ask questions that are  wrong as long as you bind that agent to that map. [24:37] So, does this apply elsewhere? It seems  very mortgage-y. Yes. Uh I would say [24:43] most recently, about eight weeks ago,  I moved to a company called Arch. [24:48] And Arch handles alternatives investments. And  one of the first things that I noticed was that [24:52] there was a gigantic cluster of common code. And  I thought to myself, that's kind of gross. So, [24:59] Madge, if anyone's familiar with that, ran that  immediately. And now we have cycle reduction [25:03] built into our CI pipeline. It's the first thing  that translates. Again, same tool that we actually [25:07] use on the graph before, but this time on our  code. Going back to the tools for agents though, [25:13] what do we do? Alternative investments. What does  that mean? Capital calls, uh distributions, K-1s, [25:19] which are tax documents for partners. Uh all  these statements are arriving from thousands, [25:23] or in our case, hundreds of thousands of private  funds. They're arriving at random intervals. Most [25:27] of them are images sent as PDFs with a lot of  really interesting information that matters a [25:32] lot to the people who are invested in those funds.  We ingest all of that, those primary documents, [25:39] and then we turn them into a verified data  structure for the people who hold the positions, [25:42] because they kind of want to know what's going on  with their money, which seems like a fair thing. [25:46] There's a spine underneath all of the  schema. Uh there's about 886 tables, [25:50] which is not too many, but it's it's enough data.  And it's already a graph. That's a critical part. [25:55] There's two sides of that. There's the LP side,  which is who holds what, and there's the GP side, [26:00] which is who issues what. And those are the  two important parts of our investment scheme. [26:05] So, let's go back to our toolbox that we used  on the loans. That time we used it on the fact [26:09] graph. This time we're actually using it on the  relationships between all of these investments. [26:13] The image on the right is actually the finding.  So, took a sample of of client nodes. This is [26:19] about 725 of them. You can see that there  are some isolates on it, but in all of this, [26:26] 716 of that sample form a single large  component with a few distinct regions. [26:32] Why does that matter? And why is this tool  important for our analysis for the agents [26:36] that we're running on top of this interact  with our customers? A couple things, but one [26:40] really important one, which what it means is that  almost half of all of these positions are co-held. [26:45] It's very rare for someone for a VC to invest, be  the only person that invests in a company outside [26:49] of like an angel round, right? So, we can start  to see that people's money is kind of cohabitating [26:55] inside of companies and investments and that's an  important thing. Data quality is a shared fate in [27:00] our industry. So, where we were concerned about  timing and accuracy on the mortgage process, [27:05] here we're actually concerned about the initial  data quality because every dollar of information [27:09] that we have may actually be multiplied by the  number of people who've invested in that entity. [27:14] So, if we fix a fund once, if we fix an  investment once, if we reason about a fund once, [27:18] we're actually helping every single  client that's holding it, which as we said [27:22] is over half of the positions. So, the rest of  the industry kind of analyzes what managers are [27:28] self-reporting and that would be what you would  do if you were just embedding the documents you're [27:31] receiving. You'd be searching semantically  over them, you'd be finding similarities. [27:35] What we are trying to do is to actually describe  what people have actually done. Where is the money [27:42] going? How is the cash flowing? And that is a  much more interesting and telling thing to do. [27:49] What that turns into from this group  of people anyway is about 206 billion [27:53] dollars of invested money that's been  flowing in between only about 716 people [27:58] entities in this particular instance. I call  it the cash river, but it's not really cash. [28:04] I think it's really fascinating and this is again  basic toolbox. So, all of these are linked to a [28:11] position. That position is extracted from original  source documents. The document provenance is [28:16] tagged along the graph and then we try to validate  where the money is going through looking at actual [28:21] cash flows, looking at distributions, looking at  the movement of money through people's accounts [28:26] that are on the platform. It matters because the  marks are what the manager says they're doing [28:30] and this is what they've actually done with  your cash, which is a kind of fascinating thing. [28:36] We also type this. We type this very heavily and  the type matters too because that's another sort [28:41] of map for your agents to reason about.  A recallable distribution isn't actually [28:45] yours. So, if you're asking a question or your  customer's asking a question of your platform, [28:49] how much money have I gotten back? And you just  sum up all the money that's been returned to them, [28:52] that's not really the full story because like  30% or 40% of that in this particular instance [28:56] could actually be recalled by the fund later,  meaning that you shouldn't go spend it. [29:01] You should not go on that vacation with that  money. You need to keep it in your bank account [29:04] because someone will be asking for it back, and  that's critical. So, before you can traverse this [29:09] kind of map that we've built, you actually have to  make sure the map is true. And this is one of the [29:13] major findings that we had from applying this. The  finding was that the definition of fund was wrong, [29:20] actually, in the majority of platforms.  So, fund identity is unique per firm, [29:24] but firm conflates who manages the fund with how  you access it. And so, separating those items out, [29:31] we were actually able to use the same tools that  we used on the mortgage process to determine [29:36] who was actually contributing to the fund and  resolve the identity of the fund itself. And then, [29:41] back to the embedding cuz these things work  together, embed that in the graph itself. [29:47] This is kind of what that looks like and  why we why we care. A big question is, [29:51] "What's my exposure to company X?" Or, more  recently, if anyone was lucky enough to be holding [29:55] SpaceX before the IPO, you may have wanted to know  how much you were going to make from the IPO of [30:00] SpaceX. It's actually a really difficult question  to resolve, but you can, again, walk this graph [30:05] and the information that's embedded on it to  find that out, which is what the agents that [30:09] uh work for our customers do in this particular  instance. So, once the identity is resolved, [30:12] exposure becomes like simply a traversal. The  exposure to company X is via all paths that [30:18] connect kind of your question to that company or  your initial investment entity to that company. [30:24] If you walk back to the original company  from the funds that you're invested in, [30:29] you're simply returning the paths that have  those investment percentages. You're not [30:33] actually returning numbers, which means that  the entire graph itself is a representation [30:36] of information. And again, super computable,  super super fast. The answer's not the number. [30:42] It's just the set of paths. And every single  hop that you have is auditable again down to [30:47] the individual piece of information that  we already pulled it from. And all that [30:50] providence is recorded on the graph itself. So,  you can just return that slice of the graph. [30:57] Another really common question that  you can't answer with embeddings [31:01] that you can't answer with graphs  is when information is missing. So, [31:08] what happens when you need to retrieve something  that doesn't exist? This happens a lot. One of our [31:12] huge things that we deal with our tax statements.  Tax time is a very difficult time for many people. [31:18] And one of the core things that you have to  think about is if you have a thousand different [31:21] investments and they're in 2,000 different  investment vehicles and then you receive 2,000 [31:27] tax statements, how do you determine if you're  missing any tax statements? If you've embedded [31:32] the documents, you just have a hole and you can't  really do anything. If you have a graph that [31:36] encodes expectations, you can do cohort analysis  on the thing that we just built two slides ago [31:41] and determine whether or not you should have  something or not with some measure of confidence. [31:45] And that is again input to your agent so you can  start answering questions sort of like, "Where's [31:51] my tax return?" Or, "Can I file my taxes?" which  is what most of our customers want to know. [31:56] I know this could be done kind of with a cron job  and some sequel, but I think the static checklist [32:03] concept really can't know entirely what to expect.  Expectation should be derived from the peers on [32:09] the graph because the graph is constantly changing  and investments are always in flux just like most [32:13] things in the real world. So, you only know that  this in this particular instance that 12 K-1 down [32:18] at the bottom is missing because the 11 other  ones have already arrived and you understand the [32:24] total picture of investment for that particular  portfolio. When you do that, you essentially [32:29] can then chase the administrator for that K-1.  And we have agents that do that very thing. So, [32:35] again, you're using a triggering concept off  of the graph to create a deterministic behavior [32:40] that probably wouldn't be possible without  uh without the actual map underneath it. [32:45] So, where does all this boil down to? Uh it is  pretty simple. There are four things similarity [32:51] can't compute without a lot of additional effort,  uh which usually means a lot of additional [32:56] uh debugging if if you're in the engineering  side. So, the first one is global structure. [33:02] It's not stored anywhere. It's computed, right?  State is really particular. It's kind of general, [33:10] and we want to allow that computation to  generalize it for us and cut down the graph so [33:14] that it's usable by our systems. Um then I think  the other thing that we want to talk about is that [33:21] absence doesn't have embedding. That's what we  just discussed in the previous two slides. And [33:26] that is a huge thing. When is something missing?  There is no embedded moment for that. Informing [33:32] your agents what to do is really important  when something does go missing. Otherwise, [33:37] you can't answer basic questions. Lastly, any step  on the graph that informs the agent what to do [33:44] is not necessarily a constraint. And I think this  is where sometimes we go a little bit off of the [33:50] the rails with the the graph side. You don't want  to lock the agent down so tight that it can't be, [33:56] for lack of a better word, creative. You don't  want to take away the thing that makes spending [33:59] money on tokens actually useful, which is  reasoning and kind of the interpretation in [34:03] the semantics. What you do want to do is make  it almost impossible through cross-checking [34:08] to make a wrong turn that causes  a regulatory problem for you. [34:12] You just can't have those embeddings be the  steering label. Our layer is the is the key thing. [34:17] So, finally, kind of where does this fall for  me? What we've done is we've layered a bunch [34:23] of technologies and a bunch of tools that  have existed for decades, and we've created [34:27] a probabilistic reasoning system  on top of deterministic rails. [34:33] This is really, really important. So, there's  one canonical system of record. Everything is a [34:38] projection of that canonical system of record.  It's disposable because it's rebuildable. [34:42] You never have to worry about it. You're not  going to lose it. The second thing is when you are [34:48] dealing with your agent, your agent's either  talking to itself, to other agents, or to people, [34:53] what you do is you ensure that it can't say things  that don't actually go back to a siteable fact ID. [34:58] All these facts exist in a real place. The  derivations are recorded. You know what they [35:03] are because you have their subgraphs. You have  all that information if you've done all these [35:06] these steps. And when the agent is forced to  site the fact ID and your governance models or [35:13] uh your watchers know that anything that doesn't  have a cited fact ID is effectively off the table [35:17] and needs to be stopped immediately, you end up  in a much safer place where you can feel pretty [35:21] confident that the the agent is doing what you  want it to do. The actions that the agent performs [35:26] comes from the graphs' dedicated transitions. So,  what you want to make sure is that the agent can't [35:32] take a wrong turn because you've never given  it the road to turn on in the first place. [35:37] That is kind of the the point of Betsy. That's  the point of Archie. You'll notice that my naming [35:42] is really not great. That's uh I just put a Y at  the end of whatever company I'm working at. And [35:49] it's it's critical though to make that map  because you won't let the agent lose its way. [35:53] And that is sort of the thing that allows  us to work with partners like Fannie Mae [35:57] or other regulators and probably show them  that we should be allowed to use AI within [36:03] regulated reasoning chains because we can actually  prove the reasoning every single time and we can [36:07] repeat the reasoning with the right version and  the same data. Uh which is is pretty interesting. [36:13] I'm I'm pretty excited about that  part. So, where does this take us? [36:16] Where are we going next? How am I applying the  tools that I just talked about in my own job, [36:20] frankly, cuz everyone can do this. This isn't  like super secret or anything like that. Uh [36:24] we are just moving forward in a very obvious way.  We have four core pillars. We have extraction, [36:30] it's landing our values as graph facts that have  the full providence. Verification cross checks all [36:35] of the redundant paths. That's one of your like  guard mechanisms, that's really important. All of [36:39] your diamonds in your graph get audited. Analytics  just become traversals on that graph. And exposure [36:45] and performance are computed on the graph as  well. So, everything again is reproducible. [36:50] Agents that we have are subscribing to those  changes and they answer with citations back to the [36:56] source document, which are again just chains on  the same graph that they're already walking. So, [37:00] you're not loading a bunch of extra context.  This is kind of the move from observability [37:06] and watching and guarding what your agents do and  hoping that they do it don't do anything wrong [37:12] into a world where you have full production  automation and that is what we are working on now [37:17] and in in our engineering team and I'm sure what  many people are working on is how do you let these [37:20] agents run safely and autonomously autonomously on  problems that previously required a human in the [37:24] loop. The answer is that you have a provable chain  of what they've done and what they're going to do [37:28] next. So, that is kind of the core of of this  talk. If you want some homework, I kind of put [37:34] the order of operations up on the screen. This is  how I think about breaking this problem down every [37:39] single time. Um and I would just encourage you to  make sure that that you go read some great graph [37:45] theory books and I'll be around in the back if  people have math questions. Thank you very much. [37:50] [applause]