Arch, Better Replace Vector Search With Graph Theory for Financial AI

Arch 与 Better 在金融 AI 中用图论替代向量搜索 嵌入相似度在受监管业务中难以奏效，因向量搜索无法检测缺失数据或强制执行有效路径，需要确定性图结构来约束概率性 AI 智能体。 Keith Soura 阐述了为何向量嵌入在高风险受监管环境中存在不足，指出智能体需要确定性图拓扑而非概率相似度来安全执行操作。结合 Better Mortgage 和 Arch 的生产系统实践，他展示了诸如 Tarjan 强连通分量、支配树以及传递约简等经典算法，如何压缩庞大的状态空间、隔离瓶颈并检测向量搜索无法发现的缺失记录。通过将概率性 LLM 与带版本的图结构及强制的 Fact ID 引用相结合，机构可以安全地推动 AI 智能体从被动的可观测性迈向可审计的生产级自动化。 向量嵌入与 RAG 的作用更像百科全书而非地图，缺乏执行高风险金融操作所需的确定性寻路能力和安全性。 (0:04) 将监管规则编码为事实和活动会产生极为庞大的状态空间（约 10^140），若不进行确定性图剪枝，向量搜索便无法对其进行管理。 (5:16) 历经数十年检验的经典图算法（如支配树和介数中心性）提供了亚毫秒级、零 Token 消耗的确定性工具，用于编排 AI 智能体。 (8:18) 联邦证据架构在每次 Git 合并哈希时静态编译工作流图，确保每个运行中的智能体引用的都是完全相同版本的业务逻辑。 (11:15) 应用 Tarjan 强连通分量算法仅在 Better 的抵押贷款系统中识别出五个承重循环，并揭示了与信用子图相关的放贷流程减速 6 倍的问题。 (12:43)

Keith Soura argues that standard retrieval-augmented generation (RAG) is inadequate for high-stakes, regulated enterprise automation because vector similarity cannot enforce deterministic execution paths or identify missing data. Instead, pairing probabilistic language models with classical graph theory provides the topological map required to prune combinatorial state spaces and satisfy regulatory compliance. Failure Modes of Vector Retrieval in Regulated Operations (0:04) Semantic vector search operates like an encyclopedia or a flashlight: while effective at locating conceptually similar reference material, it cannot chart an end-to-end operational course or guarantee reproducible paths. In heavily regulated domains such as mortgage underwriting, non-deterministic similarity searches are fundamentally unsafe for autonomous operations, such as executing multi-million-dollar transactions or signing off on statutory credit checks. Soura identifies four primary architectural breakdowns where vector embeddings fail. First, global structural workflows must be computed dynamically across networks rather than retrieved from static text chunks. Second, vector similarity cannot detect missing requirements because "absence doesn't have an embedding"—vector indices cannot query documents, dependencies, or signatures that do not yet exist. Finally, relying on embeddings for agent steering introduces probabilistic drift, whereas compliance demands provable determinism without stripping away an LLM's capacity for contextual reasoning. Pruning Combinatorial Complexity with Classical Graph Algorithms (5:16) Encoding Fannie Mae's 1,200-page lending regulations at Better required modeling operations as facts and activities. Production measurements revealed roughly 1,800 registered activities, 26,000 fact references, and 5,400 raw dependency edges. With a typical loan touching 200 activities carrying five or more states each, the reachable state space reaches 5^200 (approximately 10^140 states). Attempting to navigate this combinatorial volume directly through an LLM would overwhelm context windows and generate unsustainable token expenses. To manage this scale, engineering teams turned to classical graph theory. Tarjan's strongly connected components algorithm identified that Better's massive dependency graph contained only five non-trivial operational cycles, allowing agents to isolate routine consumer re-negotiation loops safely. Applying transitive and reachability reductions compressed 5,400 raw edges down to approximately 1,200 essential edges. Dominator trees and chokepoint detection isolate actionable subgraphs in sub-millisecond times, enabling conversational voice agents to maintain natural latencies below 50 milliseconds. Entity Traversal and Gap Detection in Finance (24:40) Graph traversal solves live diagnostic problems that static documentation search cannot address. During a live mortgage origination run, when a primary credit bureau API experienced unscheduled downtime, an agent traversed dependency paths and investor guidelines to autonomously locate, validate, and execute an approved secondary credit API in under one second. At Arch, an alternative investment platform managing positions across 886 database tables, a sample of 725 investor nodes showed that 716 belonged to a single connected component, establishing that roughly half of all alternative investment positions are co-held. This structure allows the system to compute dynamic exposure to private assets (such as SpaceX) across multi-tiered feeder funds and special purpose vehicles by traversing paths and multiplying ownership percentages, preserving an auditable source trail. Furthermore, graph-based cohort analysis compares investments across peer nodes; seeing that eleven of twelve expected Schedule K-1 tax forms have arrived automatically surfaces the missing document and triggers an autonomous agent to chase down the fund administrator. Probabilistic Reasoning Built on Deterministic Rails (34:22) Better and Arch structure their systems by layering probabilistic reasoning loops directly onto deterministic graph rails. The operational graph is treated as an ephemeral, disposable projection generated from a canonical system of record, compiled against a static Git commit hash on every code merge to ensure every running agent references identical business logic. In implementations like Better's Betsy and Arch's Archie, agent actions are mathematically bounded. Agents cannot invent execution steps outside explicitly defined graph transitions, and strict governance watchers immediately halt any assertion that does not cite a valid Fact ID tied to a derivation subgraph. Soura outlines four operational pillars for removing human-in-the-loop dependencies: extracting data into formal provenance facts, verifying integrity through redundant graph calculation paths ("diamonds"), running deterministic analytics traversals, and enabling agents to subscribe directly to graph state changes. Soura concludes that enterprise AI must shift from passive observability to production automation by adopting graph theory as a deterministic control layer. While this topological framework provides the auditability required by institutional regulators like Fannie Mae, its real-world implementation depends on organizations rigorously translating intricate legal and operational rules into formal fact and activity dependency networks.

Arch首席技术官、Better前工程主管Keith Soura指出，传统检索增强生成（RAG）因非确定性与缺乏拓扑感知，无法胜任高监管金融业务；企业应利用经典图论为AI智能体构建确定性状态流转与拓扑地图。 高监管金融场景下RAG的局限 (0:04) 在房贷承销与另类资产管理等高度监管领域，系统操作直接涉及数千万美元的资金划转与严格的法律合规性。嵌入向量检索仅能提供基于语义相似度的百科全书式参考，无法保证智能体每次执行都沿确定性路径推进。例如，美国房利美（Fannie Mae）的销售指南包含1200页复杂的PDF逻辑，其中后文的特定异常条款可能随时推翻前置假设，形成类似代码逻辑中的循环跳转。面对这种跨越庞大法律文档的隐式依赖，非确定性的语义检索无法提供可证明的确定性流程保障。 组合状态空间爆炸与经典图算法剪枝 (5:16) Better将房贷流程抽象为“事实”（Facts）与“活动”（Activities）两项基本元语。在其生产代码中，系统注册了约1800个活动并维护约26000个事实引用，产生约5400条活动间调用边。单笔贷款通常涉及200个活动，若按每个活动5种可能状态计算，全域理论状态空间高达5^200（约10^140），远超可观测宇宙的原子总数。若盲目将所有状态放入向量数据库，将耗尽模型上下文并带来高额开销。为此，团队引入经典图算法处理：利用支配树（Dominator Trees）在亚毫秒级内将状态空间剪枝为可执行子图；通过介数中心性（Betweenness Centrality）定位高负载活动枢纽；并采用传递约简（Transitive Reduction）与可达性约简，将5300余条原始边压缩至约1200条核心边，使智能体规划视角高度精简。 强连通分量与运行时确定性排障 (12:43) 现实中的金融申请并非理想的有向无环图（DAG），借款人频繁修改贷款额度等行为会引入循环依赖。Better应用塔扬算法（Tarjan's SCC Algorithm）遍历整个依赖网络，证实这套庞大系统实际仅包含5个非平凡强连通分量，从而成功将周期性循环约束在可控范围内。分析同时揭示，信用子图中的任何操作延误都会对全流程造成6倍的放大性迟滞。在运行时，当一笔贷款因主信用局API宕机而停滞时，智能体借助支配树向上回溯依赖，在1秒内确诊缺失环节，并依据图上编码的投资者准则自动评估备用API，在合规前提下自主完成降级调用与数据恢复。 另类投资的实体解析与“缺失数据”检测 (24:40) 在另类投资平台Arch，系统需处理数十万支基金发出的非标PDF凭证与886张数据库底表。分析显示，725个样本客户节点中有716个属于同一个连通分量，表明近半数头寸在不同投资者间存在共同持有；图模型借此穿透了约260亿美元的资本流向。针对SPV及联接基金构成的多层结构，系统不再固化计算美元数额，而是通过遍历投资者到标的资产（如SpaceX）的所有活跃路径并连乘持股比例，动态计算实际敞口。更重要的是，图结构解决了向量检索的盲区——“缺失没有嵌入向量”（Absence doesn't have an embedding）。系统依靠同业群组分析（Cohort Analysis）发现缺失状态（例如某投资组合中12份K-1税表已到账11份，暴露出应有而未到的第12份），进而自动触发智能体向基金管理人定向催缴。 确定性轨道上的概率推理架构 (34:22) Better的Betsy与Arch的Archie均采用了“确定性轨道上的概率推理”架构。系统将可随时重构的投影实体图与底层权威记录解耦，并在代码合并时按Git提交哈希进行静态编译以锁定业务拓扑。在多智能体协作或执行操作时，治理监控层（Governance Watcher）强制要求智能体的每一步推演必须引用带有衍生子图的具体事实ID（Fact ID）；一旦缺少凭证，操作会被立即阻断。同时，智能体的可用行动空间完全受限于图拓扑允许的转移节点，从根本上防止非法跳转。整套自动化体系由数据提取、菱形冗余校验（Diamonds）、拓扑遍历分析及图状态事件订阅四大支柱支撑，使企业能在满足严苛合规审计的前提下安全实现去人工化自动化运行。 Soura强调，企业AI演进的核心在于从被动的观察与围栏防御，转向由确定性拓扑驱动的自主生产自动化。让大语言模型专注于语义理解与灵活推理，同时依靠历经验证的经典图论提供受控的状态转移地图，是金融级智能体突破合规与安全瓶颈的关键路径。

## Background 本内容由 YouTube 频道 Ai4 于 2026 年 8 月 20 日发布，主讲人为 Arch 首席技术官、Better 前工程负责人 Keith Soura。页面简介指出，企业 AI 普遍依赖的 RAG 模式就像一本百科全书，难以指引复杂业务的执行路径，而图论则是 AI Agent 必不可少的“地图”，能够在高合规金融业务中构建确定性的转向层。 ## TL;DR Keith Soura 结合 Better（房贷科技）与 Arch（另类投资）两家金融科技企业的生产级实践，深入剖析了传统 RAG 与向量嵌入在面对复杂依赖与合规流程时的根本局限。演讲展示了如何利用支配树、强连通分量、社区发现等经典图算法，对具有超大状态空间的业务流与实体关系进行确定性剪枝、依赖分析及瓶颈诊断。通过在规范真实数据源上构建图谱投影，并建立“确定性导轨 + 概率推理”的分层治理架构，系统能够赋予 AI Agent（如 Betsy 和 Archie）毫秒级自愈、动态切片与严格可审计的执行能力，实现从被动可观测性到全自动生产化的跨越。 ## Atmosphere & style 演讲风格务实硬核、幽默风趣且极具极客气质，讲者以数学系背景的自嘲开场，迅速将观众带入深度的工程架构探讨。内容贯穿了生动的生产一线故事——从早年吃中餐外卖硬编码 1200 页法规的创业经历，到数年后在 Agent 架构中删掉当年 Todo 注释的释然，充满工程落地的真实厚重感。整场分享节奏紧凑、逻辑严密，既有扎实的数学理论推导，又有对大模型时代工程范式跃迁的深刻洞见，令人深受启发。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=0aOhTixTq1A&t=4s) 单纯依赖 RAG 与向量嵌入进行相似度检索就像百科全书，擅长语义匹配但在高风险金融合规场景中无法提供确定性、可证明的执行路径；图论则是 AI Agent 的'地图'。 - [07:16](https://www.youtube.com/watch?v=0aOhTixTq1A&t=436s) 面对房贷业务 200+ 业务活动组合产生的超大状态空间（~10^140），传统 RAG 上下文成本极高，而经典的图算法（如支配树、强连通分量、介数中心性）可在毫秒级确定性裁剪状态空间。 - [11:15](https://www.youtube.com/watch?v=0aOhTixTq1A&t=675s) Better 采用联邦证据架构，在 Git 合并时生成静态图地图（Graph Provider），并与实时数据源联合分析，通过 Tarjan 算法精准识别关键环路和信用子图的延迟瓶颈。 - [15:46](https://www.youtube.com/watch?v=0aOhTixTq1A&t=946s) 通过传递性规约和可达性分析，团队将 5,400 条依赖边大幅剪枝至约 1,200 条，并在社区发现算法指导下重塑跨角色的动态权限分配，大幅削减运营成本。 - [18:51](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1131s) 在房贷卡单诊断中，Agent 沿着支配树向上遍历仅需一次逆向查询即可秒级定位未满足依赖，并沿第三方依赖子图自主调用备选 API 完成数据自愈。 - [21:27](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1287s) 实时语音 Agent 'Betsy' 在 50ms 极低延迟要求下，通过'没有连线就不触发'的图切片路由机制，在保证自然对话的同时在数学上杜绝非法越权与数据幻觉。 - [24:40](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1480s) Arch 将另类投资底层 886 张数据表图谱化，发现近 50% 资产头寸跨客户共同持有（'共享命运'数据质量），单次数据清洗与穿透验证即可惠及全网客户。 - [29:47](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1787s) 对于 SpaceX 等多层嵌套股权的复杂穿透风险敞口计算，在图拓扑中退化为附带完整源文档存证的亚秒级图遍历路径回溯。 - [31:37](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1897s) 向量相似度检索无法表征'数据缺失'，而图谱同类群分析（Cohort Analysis）能够推导预期状态，精准识别遗漏的 K-1 税表并自动触发 Agent 追讨。 - [34:20](https://www.youtube.com/watch?v=0aOhTixTq1A&t=2060s) 系统治理哲学是在'确定性导轨'上构建'概率推理系统'：图谱作为真实数据源的可重建投影，强制要求 Agent 每一项输出绑定事实 ID，确保合规可解释与 100% 确定性复现。 - [36:11](https://www.youtube.com/watch?v=0aOhTixTq1A&t=2171s) AI Agent 走向全自动生产化必须依托四大核心支柱：抽取（完整血统事实）、校验（冗余与菱形依赖审计）、分析（退化为图遍历）与风险/绩效（拓扑实时计算）。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=0aOhTixTq1A&t=4s) 演讲者背景与主题引入 演讲者 Keith Soura 现任替代性投资平台 **Arch** 的首席技术官（CTO），同时也是 **Better**（原为房贷银行，现为跨美英的多银行软件提供商）的董事会顾问、前工程负责人及联合创始人。 Keith 开场打趣说，自己当年在学校攻读数学，本质上是为了“避免与人类交流”，结果却被老板派来参加 Conference 演讲。他指出，在涉及资金流转与合规要求的金融领域，单纯依靠概率型的检索增强生成（RAG）存在巨大风险： - **RAG 的局限**：RAG 和向量嵌入（Embeddings）就像一本百科全书，擅长提取上下文和语义相似度，但无法在非确定性系统中安全且高效地画出从 A 到 C 的**确定性路径**。 - **确定性调度的必要性**：在涉及 underwriting（承保/核保）和资金调拨（如跨银行划转 1000 万美元）的场景中，系统必须提供可证明、可重复且符合法规的确定性执行路径。图论（Graph Theory）正是充当了这张指导 AI Agent 行动的“地图”。 ```mermaid flowchart LR accTitle: RAG百科全书与图论地图对比 subgraph RAG ["RAG 模式 (百科全书)"] direction TB A["向量嵌入 / 上下文检索"] --> B["语义相似度匹配"] B --> C["非确定性路径 (存在合规风险)"] end subgraph Graph ["图论模式 (地图)"] direction TB D["图算法 / 静态依赖图"] --> E["确定性拓扑遍历"] E --> F["可证明、可重复的执行路径"] end end ``` --- ### [02:11](https://www.youtube.com/watch?v=0aOhTixTq1A&t=131s) 案例一：Better 房贷业务的复杂性与规则膨胀 以 Better 公司的住房贷款业务为例，在美国买房的过程极其繁琐（相比之下，冰岛等国家只需一小时便可在银行完成所有手续）。在美国，房屋贷款受到多层级、多机构规则的交织约束： - **错综复杂的法规体系**：包含联邦法规、各州法规、地方政府与市政法规，以及针对不同人群（如退伍军人的 VA 贷款、USDA 农场贷款、FHA 贷款等）的特定条款。 - **庞大的非结构化文档**：行业标准买方房利美（Fannie Mae）的 *Selling Guide*（销售指南）今年长达 **1200+ 页**，全是由律师团队编写的 PDF，且随着政府换届与国会立法频繁更新。 - **规则间的交叉依赖**：不同页码之间的逻辑高度交叉（类似老式代码中的 GoTo 语句）。例如第 400 页规定了如何收集信用财务信息，而第 900 页又规定了若信用报告发现新事实时必须跳回前文重新核验。 --- ### [04:51](https://www.youtube.com/watch?v=0aOhTixTq1A&t=291s) 从人工硬编码到膨胀的依赖图 八年前，Better 的早期工程团队为了解决规则交叉问题，在纽约的办公室里边吃中餐外卖边将 1200 页的法规逐条翻译为代码，构建了一套核心系统： - **Facts（事实）与 Activities（活动）**：系统包含“事实”（关于借款人已知或计算出的信息）和“活动”（执行的操作）。“活动”可以接收事实（如当 DTI 负债收入比超标时触发解释请求），也可以产生新事实。 - **庞大的图规模**：在演讲前几周提炼的代码库数据中，系统已包含： - **1,800 个注册活动**（其中约 1,000 个在日常高频使用）； - **近 26,000 个独立的 Fact 引用**； - **近 5,400 条派生的 Activity-to-Activity 边**。 --- ### [07:16](https://www.youtube.com/watch?v=0aOhTixTq1A&t=436s) 状态空间的“宇宙级”爆炸与求解工具箱 单笔标准房贷（额度在 5 万至 68 万美元之间）通常会触及约 **200 个 Activity**，每个 Activity 拥有约 5 个状态。 - **组合爆炸**：潜在的可达状态空间达到 $5^{200} \approx 10^{140}$，其复杂程度远远超过了已知宇宙中的原子总数。 - **RAG 的成本灾难**：如果尝试将如此庞大的状态信息全部嵌入向量库，Token 账单将呈爆炸式增长。 - **确定性裁剪与图算法**：实际上绝大多数状态对特定借款人是不可达的。图论算法（如 Dominator Trees、Betweenness Centrality、Strongly Connected Components 等）提供了极低成本（通常小于 1 毫秒）且确定性的裁剪工具，能在近乎实时的情况下帮 Agent 定位关键节点、消除冗余并切断无效路径。 ```mermaid flowchart TD accTitle: 图算法对房贷状态空间的裁剪 subgraph Space ["超大状态空间 (~10^140)"] S1["200+ 活动节点"] S2["26,000+ Fact 引用"] end subgraph Cutting ["确定性图算法裁剪"] C1["Dominator Trees (主导树门控)"] C2["SCC / 强连通分量 (环路识别)"] C3["Centrality (瓶颈/载荷识别)"] end subgraph Agent ["Agent 实际遍历路径"] A1["极小可达状态子图 (毫秒级响应)"] end Space --> Cutting --> Agent ``` - 经典图算法不仅计算廉价（大部分为开源库实现），而且拥有数十年的数学理论支持。 - 演讲者在查看 Git Blame 时发现，自己在多年前就写下了“需要用图算法优化此处”的 Todo 注释，如今终于在 Agent 架构中真正将其兑现并删除了该注释。 --- ### [11:15](https://www.youtube.com/watch?v=0aOhTixTq1A&t=675s) 联邦架构与房贷时间线优化 Better 为 AI Agent 设计了单一推理环路与多源联合数据（Federated Evidence）相结合的架构： - **静态图地图（Graph Provider）**：在每次 Git Commit/Merge 时自动构建并生成包含 Git Hash 的静态图结构。Agent 借此验证自己是否掌握最新版本的“地图”。 - **动态数据源**：将 Graph Provider 与生产数据库、经典向量嵌入、可观测性数据（Observability）以及实时用户行为反馈进行联合分析。 在房贷业务中，时间就是生命。房利美规定每笔贷款从启动到完成有 30 至 45 天的严格法律期限： - **强连通分量（SCC）与环路控制**：通过 Tarjan 算法对全图分析，团队在庞大的依赖图中仅发现了 **5 个非平凡的强连通分量**。这些环路往往来自于合规的反复修改（如买房者为配合不同挂牌价多次修改预审合格信 Pre-qualification Letter）。算法能够允许必要的逻辑循环，同时明确界定其边界。 - **信用子图的瓶颈效应**：分析显示，信用（Credit）子图中的任何微小卡顿，都会导致整个贷款流程发生 **6 倍的整体延迟**，成为导致无法按时结案（Close on time）的主要诱因。 --- ### [14:50](https://www.youtube.com/watch?v=0aOhTixTq1A&t=890s) 触发图（Triggering Graph）的规约简化 在处理复杂的触发逻辑时，演讲者展示了一种图规约（Reduction）机制： - **传递性规约**：若节点 A 触发 B，且 B 触发 C，则可在向 Agent 提供上下文时简化为“A 触发 C”，移除中间的遍历节点。 - **分层加载与降本增效**：中间过程的详细信息可以留作后续异步加载，而给 Agent 呈现的则是类似于 Google Maps 放大视图的高层级地图。这种处理极大降低了 Agent 在图拓扑中遍历的计算复杂度与延迟成本。 --- <ElicitationsGroup message="想要深入了解图论与 AI Agent 结合的更多细节？"> <Elicitation label="了解 Better 如何利用图算法诊断卡顿的贷款流程" query="详细解释 Better 如何利用图算法和可观测性数据，在几秒钟内诊断卡住的贷款流程？"/> <Elicitation label="探讨 Arch 在替代性投资中的图架构应用" query="演讲中提到的 Arch 公司是如何将图理论应用到替代性投资（如 K-1、资本呼叫）中的？"/> <Elicitation label="对比 RAG 与 Graph Agent 在金融合规中的优劣" query="对比 RAG 与 Graph-based AI Agent 在金融合规和Back-office自动化中的具体优缺点及应用场景。"/> </ElicitationsGroup> ### [15:46](https://www.youtube.com/watch?v=0aOhTixTq1A&t=946s) 依赖图剪枝与组织拓扑重构 在房贷处理系统的初始状态下，依赖关系网极其庞大，包含约 5,300 至 5,400 条边。但在对其进行可达性分析后，团队发现其中有四分之一的边具有完全相同的可达性逻辑，完全是架构上的冗余。通过在代码合并期（Merge Time）进行图剪枝和传递约简，整个图结构被精简到了大约 1,200 条边。这种精简对于需要毫秒级响应的高速推理系统至关重要，尤其是在开发语音 Agent 的场景中——人机通话中的任何不自然停顿都会彻底破坏用户体验。相比之下，传统的向量嵌入（Embedding）技术虽然能将文档、提示词、工具和知识索引到链路上，却无法从数学上精简推理循环，只会在多轮对话和复杂推理时导致上下文窗口迅速膨胀爆炸。 进一步地，团队在没有向算法灌输任何公司预设架构或工作流程规则的前提下，利用社区发现（Community Detection）算法对真实代码运行图进行了聚类和图着色分析。结果揭示了代码执行拓扑与真实组织架构之间的巨大错位。最典型的一个聚类包含了 228 项独立的业务活动，表面上是一条连续的处理流水线，但在现实组织中却跨越了 6 种不同的专业角色：结算专员（Closers）、贷款处理员（Processors）、估价师（Appraisers）、合规披露与法务团队（Disclosures & Legal）、贷款业务员（Loan Officers）以及核保专员（Underwriters）。这些持牌专业人员在处理同一笔贷款时面临着繁复的权限隔离和法定责任边界。 通过识别这些自然形成的工作集群，团队不仅对软件代码进行了模块化解耦，还直接推动了组织层面的工作方式变革。过去员工在流转文件时需要频繁提交各类跨部门权限申请，而在重组后，只要员工在一个特定的业务活动集群中协同处理某笔贷款，系统便会在处理期间动态自动下发所需权限。这种拓扑驱动的微小效率提升，在成千上万名贷款业务员的规模效应下，每年能为企业节省数以百万计的薪酬支出，而这些节省下来的运营成本最终能以更低的贷款利率直接反哺给借款客户。 ```mermaid flowchart TD accTitle: 依赖图剪枝与组织拓扑重组流程 subgraph S1["图压缩与剪枝"] A["初始状态: ~5,400 依赖边"] --> B["可达性分析 & 传递约简"] B --> C["优化状态: ~1,200 核心边"] end subgraph S2["社区发现与聚类"] C --> D["无监督社区发现算法"] D --> E["识别出 228 个活动的业务大集群"] end subgraph S3["跨角色协同与动态赋权"] E --> F["重叠的 6 类持牌角色<br/>(核保/法务/结算/估价等)"] F --> G["动态集群权限自动下放"] G --> H["每年削减数百万美元运营成本"] end ``` --- ### [18:51](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1131s) 真实卡单诊断：从图遍历到自动自愈 以一笔真实的房贷卡单为例（已脱敏），该贷款在即将进入放款结算（Closing）的关键节点意外停滞，面临错失签约期限的巨大风险。如果单纯依赖基于 Embedding 的 RAG 系统，AI 只能检索到房利美《销售指南》中的政策说明、内部流程规范以及“当前贷款处于卡单状态”这一表面事实，却完全无法定位“为什么这笔特定贷款在此时此刻失败”。但如果借助依赖图谱，排查过程被简化成了极其精准的图遍历操作：系统只需执行一次查询即可捕获异常状态，再执行一次逆向查询沿着支配树（Dominator Tree）向上遍历，就能精准锁定导致停滞的具体业务活动及其两个未满足的事实依赖项——一份缺失的信用报告和一项未完成的收入验证。 在定位到潜在依赖项后，系统迅速针对目标数据源发起高并发查询。排查结果显示，外部信用评级机构的 API 正在进行非计划内的停机维护，导致信用报告拉取失败。此时系统既可以选择升级转人工，也可以触发专用的“信用报告 Agent”。该 Agent 沿着集成的第三方服务依赖子图进行自主探索，并结合购贷投资人（Investors）对信审规则的具体政策约束，判定当前贷款类型允许采用备选评级通道。Agent 随即调用备选信用机构的 API 成功获取数据并写回事实库，使整张状态图在 1 秒之内完成全量状态刷新，阻断状态瞬间解除。 - **确定性根因定位**：无需全量扫描庞大的状态空间，仅需在支配树的核心关键路径上向上回溯，即可毫秒级锁定阻断依赖。 - **高确定性自动恢复**：Agent 沿着合规规则与 API 集成图谱自主寻找符合投资人政策的备选路径，全程耗时不到 1 秒即可完成数据自愈。 - **向量检索与图遍历的本质差异**：Embedding 只能提供静态知识的“百科全书”，而图结构赋予了 Agent 可以在动态环境中导航并采取行动的“实时地图”。 --- ### [21:27](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1287s) 实时语音 Agent “Betsy” 与确定性状态约束 为了服务那些无法坐在电脑前、网络受限但习惯于电话沟通的借款人，团队与 OpenAI 合作推出了名为“Betsy”的实时全双工语音 Agent。在电话语音交互场景下，人类对停顿极为敏感，系统端到端响应延迟必须被严格压制在 50 毫秒以内。面对房贷业务中极其庞大的状态空间，传统的 LLM 轮询或全量上下文加载策略完全失效。 ```mermaid flowchart LR accTitle: Betsy 实时语音 Agent 上下文动态切片机制 A["客户电话交互<br/>(端到端延迟 < 50ms)"] --> B["事实变更触发<br/>(如异步信用流 / 口述游艇负债)"] B --> C["图切片路由机制<br/>(仅激活订阅该事实的子图)"] C --> D["确定性状态重算<br/>(如重新计算 DTI 负债收入比)"] D --> E["动态子图上下文注入<br/>(LLM 语言表达受拓扑约束)"] ``` 在实际通话过程中，Betsy 可以一边与客户交流，一边在后台异步拉取信用报告及第三方信贷数据以实时计算决定贷款选品的关键指标——债务收入比（DTI）。如果外部异步数据流在通话中途推送了借款人新增的债务信息，图引擎会立即触发 DTI 重新计算，并将这一动态生成的局部子图上下文即时注入到当前 Agent 的推理上下文中，避免了让大模型不断循环轮询 API 的低效操作。同样，如果借款人在电话中无意提到“我刚买了一艘游艇”，即使当天信用报告尚未体现该笔贷款，Agent 也能在图谱中预设占位符与等待条件，引导后续流程追踪。 这种架构揭示了在概率性大模型之上构建确定性业务系统的核心法则：“没有连线，就不触发（Nothing fires that isn't wired）”。LLM 依旧可以使用最自然、富有人性化的口语与借款人沟通，但在图谱的刚性约束下，模型在数学上被限制在当前切片的子图路径内：它既不可能捏造事实数据，也不可能越权跳过法定风控节点提出违规问题，从而在不可出错的金融核心领域实现了安全可控的自动化。 --- ### [24:40](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1480s) 跨行业复用：Arch 另类投资图谱与“共享命运”数据质量 八周前演讲者加入专注于另类投资（Alternative Investments）的金融科技平台 Arch。刚入职时，他在庞大的通用代码库中发现了严重的循环依赖，随即使用代码分析工具（如 `madge`）将依赖拓扑分析与环路消除机制集成到了 CI 流水线中——这证明图算法在代码架构重构与业务数据流分析中具有完全通用的数学力量。在另类投资领域，核心业务涉及数十万支私募股权基金（Private Funds）以随机时间间隔发来的非结构化 PDF 文件与扫描件，包括出资通知（Capital Calls）、收益分配（Distributions）以及 K-1 税表。Arch 将这些原始凭据解析并挂载到底层包含 886 张核心数据表的资产拓扑骨干网中，拆解为 LP（有限合伙人：谁持有资产）与 GP（普通合伙人：谁发行资产）两大图谱体系。 ```mermaid flowchart TD accTitle: Arch 另类投资穿透图谱与数据验证机制 subgraph S1["非结构化凭据提取"] A["几十万支私募基金 PDF 凭证<br/>(出资通知 / 分配单 / K-1税表)"] --> B["原始数据提取 & 溯源打标 (Provenance)"] end subgraph S2["实体图谱与共享命运"] B --> C["底层 886 张数据表统一图谱化<br/>(LP 持有端 vs GP 发行端)"] C --> D["725 节点连通分支分析:<br/>716 节点强连通 ($26B 穿透资金)"] D --> E["数据质量'共享命运':<br/>近 50% 资产头寸为共同持有"] end subgraph S3["穿透验证与敞口分析"] E --> F["真实穿透验证<br/>(比对实际银行流水 vs 基金经理宣称估值)"] F --> G["强类型约束<br/>(识别可回拨分配 Recallable Distribution)"] end ``` 通过对 725 个客户节点构成的样本进行图连通分支（Connected Components）分析，团队发现其中 716 个节点紧密连接为一个巨大的单连通子图，覆盖了在这些实体之间流转的超过 260 亿美元的穿透投资资金（演讲者称之为“资金之河”）。这一拓扑特征揭示了另类投资行业的一个底层事实：将近一半的投资头寸是跨客户共同持有的（Co-held），机构与天使投资人往往共同注资到相同的标的企业或基金中。 在共同持有的拓扑结构下，数据质量呈现出“命运共同体（Shared Fate）”的特征：只要平台为某一家基金精准清洗并验证了一次数据，其带来的数据质量红利就会自动倍增扩散给持有该基金的全部机构与个人客户。不同于传统机构仅依赖 Embedding 语义搜索去被动检索基金经理自说自话的自查报告（Self-reported marks），Arch 借助图谱将原始凭据、银行账户实际资金流水、历史分红与分配款项进行端到端对账，真实还原每一笔资金的实际动向。 - **强类型依赖与商业防坑**：图谱对分配类型进行了极严格的类型标注。例如“可回拨分配（Recallable Distribution）”在法律上随时可能被基金要求退回，若 Agent 仅将资金简单相加并告诉客户“这是您已落袋的收益”，客户一旦将资金消费挪用就会引发流动性灾难。 - **基金实体身份消歧**：行业普遍混淆了“基金管理人是谁”与“通过何种渠道代销接入”。通过图谱拓扑分离管理实体与访问通道，系统彻底解决了基金实体的跨平台身份归一化问题。 --- ### [29:47](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1787s) 穿透敞口计算与缺失数据的图谱化表征 在另类投资领域，高净值客户最常提出的核心痛点问题之一是：“我对某家特定底层公司的总风险敞口到底是多少？”例如在 SpaceX 传出潜在 IPO 传闻时，持有大量多层嵌套私募基金的投资人急迫想知道自己能从中获益几何。由于投资路径通常经过了母基金（Fund-of-Funds）、SPV（特殊目的载体）、联名基金等多层股权穿透，直接计算数值极其繁琐且极易出错。在身份消歧完成的实体图谱中，敞口计算退化为纯粹的图遍历：系统沿着从客户实体到目标公司的所有连通路径进行回溯，直接返回各条路径上的投资比例集合。图谱上的每一次节点跳转（Hop）都严格附带底层源文档的溯源存证（Provenance），使得整个计算过程完全透明、可审计且具备亚秒级计算性能。 对于基于 Embedding 的传统检索系统而言，最致命的弱点在于无法回答**“数据缺失”**的问题——你无法通过语义相似度去检索一份根本不存在的文件。在另类投资的报税季，一个拥有 1,000 项投资的家族办公室可能涉及 2,000 个投资主体，面对陆续收到的 2,000 份税表，如何证明是否有税表漏发？Embedding 检索面对空白只会返回语义最接近的无关内容或直接沉默；而具备预期约束的实体图谱能够以确定性的数学结构编码“应当存在的数据实体”，从而精准标出缺失的具体节点，让 AI Agent 在税季主动向管理人催缴遗漏文件。 ### [31:37](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1897s) 基于图谱同类群分析与“缺失”检测：告别静态清单 在替代投资场景中，投资者最迫切需要解答的核心问题往往非常接地气：“我的报税单（Tax Return）在哪里？”或者“我现在可以报税了吗？”。常规的工程思路通常是跑一个 Cron 定时任务加上几行 SQL 查询，基于静态的 Checklist（检查清单）来比对。然而，静态检查清单根本无法应对真实世界中动态变化的业务逻辑——投资标的处于不断流动之中，图谱拓扑也是实时更迭的。预期的设定不应该来自写死的规则，而应当来自图谱中同类节点（Peers）的推导。 ```mermaid flowchart LR accTitle: 缺失 K-1 表格的图谱同类群推导与 Agent 追讨流 subgraph S1["图谱推导层"] P["投资组合全景图谱"] --> C["同类群分析 (Cohort Analysis)"] C --> D["发现异常：11 份已到，第 12 份 K-1 缺失"] end subgraph S2["确定性执行层"] D --> T["触发确定性追踪事件"] T --> A["追讨 Agent"] A --> F["联系基金管理人追回 K-1"] end ``` 以税务文件 K-1 为例：某个投资组合中预期有 12 份 K-1 表格，系统之所以能断定底部的第 12 份 K-1 缺失，仅仅是因为同图谱上的其他 11 份已经就绪，系统据此对整体投资全景具有全局认知。一旦图谱分析给出了置信度极高的“缺失”信号，下游的自动化 Agent 就会被确定性触发，直接向对应的基金行政管理人（Administrator）发起追讨。单纯依赖向量检索（Embedding Similarity）根本无法发现“不存在的事物”，而利用图谱的状态推导与触发机制，则能构建出原本无法实现的确定性智能行为。 - **静态清单的致命缺陷**：静态 SQL 或规则无法动态感知整体组合的变动，无法推导“理应存在但尚未到达”的状态。 - **同行推导（Peer Derivation）**：利用图谱同类群分析（Cohort Analysis），依据已到达的 11 份 K-1 计算置信度，精准定位缺失的那 1 份。 - **闭环自动化**：图谱变化直接触发专职 Agent，自动联系管理人催缴文件。 --- ### [32:45](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1965s) 向量相似度无法解决的核心短板与确定性导轨 依赖向量嵌入（Embedding）进行相似度检索在面对深层系统架构时存在天然的技术盲区，这也正是传统 RAG 频繁导致工程师陷入无休止调试泥潭的根源： 1. **全局结构无法存储，只能计算**：真实的系统状态极度特殊且分散，它并不直接固化存储在某处，必须通过图算法在线计算、泛化并剪枝，才能提供给智能系统使用。 2. **“缺失”（Absence）没有向量嵌入**：这是极关键的洞察——当一件关键事务“没有发生”或“缺失”时，向量空间中根本不存在代表该时刻的 Embedding。如果无法告诉 Agent 某物缺失，Agent 就连最基本的业务问答都无法完成。 3. **图谱的路径是导轨而非枷锁**：图上的拓扑指引绝不应过度约束 Agent。过度束缚会让 Agent 丧失其最具价值的能力——即基于语义理解、常识推理和解释能力进行“创造性”思考（否则花钱买 LLM Token 便毫无意义）。系统要做的是通过交叉验证（Cross-checking），从物理路径上封死任何可能导致合规风险的错误岔路，“绝不能将 Embeddings 作为唯一的转向导轨（Steering Layer）”。 --- ### [34:20](https://www.youtube.com/watch?v=0aOhTixTq1A&t=2060s) 确定性导轨上的概率推理系统：Betsy 与 Archie 的治理哲学 真正的技术突破不在于发明全新的模型，而是将沉淀了数十年的图论与数据库技术进行模块化分层，在“确定性导轨（Deterministic Rails）之上构建概率推理系统（Probabilistic Reasoning System）”。系统维持唯一规范的真实数据源（Single Canonical System of Record），所有图谱都只是该数据源的投影；投影随时可销毁、可重建，没有任何状态丢失的负担。 ```mermaid flowchart TD accTitle: 确定性导轨与概率推理协同架构 subgraph Layer1["规范记录与投影层"] SR["规范真实数据源 (System of Record)"] --> PG["图谱投影 (可销毁 / 可重建)"] end subgraph Layer2["确定性导轨 (Rails)"] PG --> TR["专用状态转移路径 (Dedicated Transitions)"] PG --> FID["可引用事实 ID (Citable Fact IDs)"] end subgraph Layer3["概率推理层 (AI Agent)"] TR --> AG["Agent 执行 (Betsy / Archie)"] AG --> G["监管与看门狗模型 (Watchers)"] FID --> G end subgraph Layer4["合规与可解释性输出"] G -->|无 Fact ID 立即阻断| ERR["拦截未知幻觉"] G -->|验证通过| OK["可证明、可重现的推理链 (Fannie Mae 等监管机构认可)"] end ``` 在这套架构下，无论是 Better Mortgage 的 "Betsy" 还是 Arch 的 "Archie"（演讲者调侃自己的命名习惯极其简单粗暴——就是在公司名后加个字母 "Y"），都严格遵守底层安全边界： - **强制引用事实 ID（Citable Fact ID）**：Agent 在与自身、其他 Agent 或人类交互时，吐出的每一句话必须回溯到图谱中具备完整来源证明（Derivations & Subgraphs）的具体事实 ID。监管治理模型和看门狗（Watchers）一旦检测到 Agent 输出了没有引用事实 ID 的内容，会将其视作非法操作立即阻断。 - **状态转移图严格限制行动空间**：Agent 执行的操作只能来自图上已定义好的专用转移路径（Dedicated Transitions）。“Agent 之所以不会走错路，是因为你一开始就根本没把那条错误的路给它。” - **监管可解释性与确定性重现**：这也是团队能够向 Fannie Mae（房利美）等极严苛的监管机构自证合规的核心所在。在高度监管的推理链条中，系统能够使用完全相同的数据版本与图拓扑，100% 确定性地复现每一次推理过程。 --- ### [36:11](https://www.youtube.com/watch?v=0aOhTixTq1A&t=2171s) 迈向全自动生产化：图驱动 AI Agent 的四大核心支柱 演讲者阐明了这套方法并非不可外传的商业秘笈，而是所有人都可以复现的标准工程演进路径。企业让 AI Agent 从“带有侥幸心理的被动观测与防守（Observability）”走向“真正的全自动生产化（Full Production Automation）”，必须依托四大核心支柱： | 核心支柱 | 实现机制与技术内涵 | |:--- |:--- | | **抽取（Extraction）** | 将非结构化或半结构化信息转化为带有完整数据血统/溯源记录（Full Provenance）的图谱事实（Graph Facts）。 | | **校验（Verification）** | 自动审计并交叉验证图谱中所有的冗余路径与“菱形依赖（Diamonds）”，作为系统内置的第一道防御机制。 | | **分析（Analytics）** | 摒弃复杂的即席联合查询，复杂的商业分析与指标计算在底层退化为直观的图遍历（Graph Traversals）。 | | **风险与绩效（Exposure & Performance）** | 直接在图拓扑上实时计算敞口与投资绩效，确保每次推演结果在数学上均完全可重现（Reproducible）。 | 在这种机制下，智能 Agent 只需简单订阅图谱状态的变化事件。当它们生成响应时，引用的凭证直接沿着当前遍历的图关系链回溯到原始文档本身，彻底告别了每次调用都往上下文窗口塞入海量无关上下文的落后做法。 最后，演讲者总结道：解决传统“人类在环（Human in the loop）”高壁垒任务的关键，就是赋予系统一条关于“Agent 过去做了什么，以及接下来要走哪一步”的严格可证明链路。他鼓励大家认真阅读经典的图论书籍，掌握经典数学工具为当代 AI Agent 带来的降维打击能力。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=0aOhTixTq1A&t=4s) RAG 和向量嵌入（Embeddings）就像一本百科全书，擅长提取上下文和语义相似度，但无法在非确定性系统中安全且高效地画出从 A 到 C 的确定性路径。 — Keith Soura > [07:16](https://www.youtube.com/watch?v=0aOhTixTq1A&t=436s) 潜在的可达状态空间达到 5^200 ≈ 10^140，其复杂程度远远超过了已知宇宙中的原子总数。 — Keith Soura > [11:15](https://www.youtube.com/watch?v=0aOhTixTq1A&t=675s) 信用（Credit）子图中的任何微小卡顿，都会导致整个贷款流程发生 6 倍的整体延迟，成为导致无法按时结案的主要诱因。 — Keith Soura > [21:27](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1287s) 没有连线，就不触发（Nothing fires that isn't wired）。 — Keith Soura > [18:51](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1131s) Embedding 只能提供静态知识的“百科全书”，而图结构赋予了 Agent 可以在动态环境中导航并采取行动的“实时地图”。 — Keith Soura > [29:47](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1787s) 对于基于 Embedding 的传统检索系统而言，最致命的弱点在于无法回答“数据缺失”的问题——你无法通过语义相似度去检索一份根本不存在的文件。 — Keith Soura > [32:45](https://www.youtube.com/watch?v=0aOhTixTq1A&t=1965s) 绝不能将 Embeddings 作为唯一的转向导轨（Steering Layer）。 — Keith Soura > [34:20](https://www.youtube.com/watch?v=0aOhTixTq1A&t=2060s) 在确定性导轨（Deterministic Rails）之上构建概率推理系统（Probabilistic Reasoning System）。 — Keith Soura > [34:20](https://www.youtube.com/watch?v=0aOhTixTq1A&t=2060s) Agent 之所以不会走错路，是因为你一开始就根本没把那条错误的路给它。 — Keith Soura > 如果你的领域包含依赖关系、工作流程或流水线——它就是一个图。停止检索，开始遍历吧。 — Keith Soura ## Mentioned Keith Soura, Arch, Better, Better Mortgage, Fannie Mae (房利美), Selling Guide, Freddie Mac, FHA, VA, USDA, OpenAI, Betsy, Archie, Tarjan 算法, Dominator Trees (支配树), Betweenness Centrality (介数中心度), Strongly Connected Components (强连通分量), Community Detection (社区发现), 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=0aOhTixTq1A)

[0:04] Keith Soura: RAG 和向量嵌入（Embeddings）就像一本百科全书，擅长提取上下文和语义相似度，但无法在非确定性系统中安全且高效地画出从 A 到 C 的确定性路径。 [7:16] Keith Soura: 潜在的可达状态空间达到 5^200 ≈ 10^140，其复杂程度远远超过了已知宇宙中的原子总数。 [11:15] Keith Soura: 信用（Credit）子图中的任何微小卡顿，都会导致整个贷款流程发生 6 倍的整体延迟，成为导致无法按时结案的主要诱因。 [21:27] Keith Soura: 没有连线，就不触发（Nothing fires that isn't wired）。 [18:51] Keith Soura: Embedding 只能提供静态知识的“百科全书”，而图结构赋予了 Agent 可以在动态环境中导航并采取行动的“实时地图”。 [29:47] Keith Soura: 对于基于 Embedding 的传统检索系统而言，最致命的弱点在于无法回答“数据缺失”的问题——你无法通过语义相似度去检索一份根本不存在的文件。 [32:45] Keith Soura: 绝不能将 Embeddings 作为唯一的转向导轨（Steering Layer）。 [34:20] Keith Soura: 在确定性导轨（Deterministic Rails）之上构建概率推理系统（Probabilistic Reasoning System）。 [34:20] Keith Soura: Agent 之所以不会走错路，是因为你一开始就根本没把那条错误的路给它。 Keith Soura: 如果你的领域包含依赖关系、工作流程或流水线——它就是一个图。停止检索，开始遍历吧。

[0:04] Keith Soura: When you are finding that similarity with a non-deterministic system, what you don't want to do is then give that system control of moving like $10 million from one bank account to another. That's a bad vibe and no one wants to do that. [0:04] Keith Soura: live in a corner with a computer [2:18] Keith Soura: an old school PDF go-to statement [8:18] Keith Soura: an engineer is only as good as his tools [14:57] Keith Soura: zoomed-out Google Maps [24:40] Keith Soura: $26 billion cash river [31:37] Keith Soura: Where's my tax return? [31:37] Keith Soura: Can I file my taxes? [32:45] Keith Soura: Absence doesn't have an embedding. Keith Soura: 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. Keith Soura: If your domain has dependencies, workflows, or pipelines — it's a graph. Stop retrieving. Start traversing.

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