--- id: "dZgA6btnb_s" title: "不要让模型编造数字" channel: "AI Engineer" host: ["未在本段落中确认"] guests: ["Vinoo Ganesh"] date: "2026-10-25" updated: "2026-10-26" duration: "20:58" duration_seconds: 1258 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=dZgA6btnb_s" canonical: "https://pod-exp.pages.dev/dZgA6btnb_s/" transcript_jsonl: "https://pod-exp.pages.dev/dZgA6btnb_s/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 基础设施","金融基础设施","模型评测"] series: ["AI 基础设施"] --- # 不要让模型编造数字 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Kepler CEO Vinoo Ganesh 介绍了一套面向金融研究的 AI 架构：模型负责规划与检索，但不直接产出数字，计算交给确定性代码；每个数字都应绑定可点击、可核验的来源。系统先从 SEC 文件中提取事实并建立引用注册表，再结合结构化数据、企业内部文档、混合搜索和重排序，处理单位、量级、期间与来源冲突。平台还通过逐文档授权和租户隔离防止数据泄露；无法验证的数字会被过滤或尝试修复。演讲也指出，普通 RAG 在金融场景中不足以保证精确性和可审计性，AI 的边界仍在于它不能替代完整的投资团队。 ## [0:14] 开场与 Kepler 简介 · YouTube **Vinoo Ganesh：** 谢谢大家来参加。我叫 Vinoo Ganesh，是 Kepler 的 CEO。我的几位队友也在现场。很高兴能来这里和大家交流。 这场演讲最初源于 AIE 的 World’s Fair 活动。我们当时从高层次介绍了 Kepler，以及我们如何开展工作。如今我们最受关注的一件事是：Anthropic 对我们的架构和技术做了一次全面深入的研究。World’s Fair 演讲之后，大家问得最多的问题是：“你们到底是怎么做到的？” 我们的合作伙伴和朋友 TurboPuffer 邀请我来分享 Kepler 如何把 TurboPuffer 作为整个技术生态中的一个组成部分。顺便宣传一下：大约 25 分钟后，Jack 和我还会在主舞台演讲。如果你想了解 AI 时代的基本面投资，欢迎 25 分钟后过来听。 简单介绍一下我的背景。我叫 Vinoo，是 Kepler 的 CEO。我在 Palantir 开始职业生涯，负责那里的计算层；之后创办了一家数据即服务公司，再后来担任 Citadel 的业务工程负责人。我们构建 Kepler 时学到的很多东西，都直接来自这些经历：在对准确性和保真度有极高要求的环境中，理解如何搭建并运用底层基础设施——或者不管现在流行怎么称呼它。 接下来，我来介绍一下 Kepler 做什么。我知道我们已经…… ## [1:48] 为什么大型语言模型与金融数字难以兼容 · YouTube 我们最近参加了不少活动。今天我们也很高兴出现在 Gemini Force 的博客文章里，他们刚发布了一个新模型。 核心原则是：如果你是在金融行业工作的分析师，就绝不会把一个客户或投资组合经理（PM）无法明确验证或追溯来源的数字展示给他们。比如，看到“营收增长了 12.4%，达到 4182 亿”，这类数字必须准确无误。问题在于，我们现在使用的都是概率机器。大型语言模型从根本上说就是概率机器。让它们富有创造力、很酷的特质，也正是它们难以用于关键任务场景的原因。 一种常见做法是在生成答案后再附上来源。这听起来不错，但事后补来源会遇到问题。首先，尽管很多人这么认为，大语言模型其实并没有真正阅读你的文档。它们会把一堆内容切成块，做语义搜索，再检索出一些可能有点相关的信息——如果运气好的话。 因此，很多人遇到的第一个大问题是来源错了：比如从 Seeking Alpha，或 Venu 那篇随手写的、声称 Palantir 每股会值 10 万美元的 YOLO 博客里取信息。另一种情况是来源正确，数字却错了。比如读 10-K 或 10-Q 时，你可能看到数字 17。它究竟指什么？是 1700 万、170 亿、1700 万日元，还是 1700 万美元？这 1700 万是这家公司 2023 年的营收，来自 2025 年提交的 10-K 吗？还是说 17 是页码？只要工作环境要求结果可验证或数字准确，这些都必须考虑。 最后还有心算的问题。增长率、利润率、估值倍数、模型本身并没有真正完成计算。有些情况下，模型会编写代码来计算，但模型本身并不会以能确保保真度和准确性的方式进行计算。 ## [4:02] 模型引用数字，代码负责计算 · YouTube 因此，我们最终需要开发这样一种架构：模型负责引用数字，却绝不负责写出数字。Kepler 的核心机制是检索系统找出正确来源（这要感谢 TurboPuffer，稍后会谈到），代码负责计算。这里的代码不是模型写出的数学表达式，而是由人预先编写的确定性代码。 ## [4:30] 从 SEC 文件构建引用注册表 · YouTube 我们处理了 SEC 的整个数据语料库，总计超过 3000 万份文件。希望很快能和 TurboPuffer 的朋友合作，把这些内容呈现给大家。我们做了一步预处理，并注册了我们称为“引用”的内容。 所谓引用，实际上是从申报文件中提取出来的确定性数值，例如营收数字、损益表、资产负债表中的项目，以及管理层讨论与分析（MD&A）中以人工撰写文字说明的内容，比如“嘿，我的营收增长了 37%”。这类内容大约有 2 万条。 我们还揭示了三类可以作为引用锚点的申报事实。这意味着，我们能否告诉你某个数字的出处，取决于你能否点击这个数字，并回到它所来自的原始文件。在生产环境中，我们会拒绝无法验证的引用。也就是说，如果一个数字没有引用，模型在结构上就无法生成包含它的输出。 最后，过滤器正确提取出的引用数量大约是 2.1 万条。我稍后会再详细介绍。关于 Kepler 的工作方式，Anthropic 也有相关内容；想了解更多，可以搜索“Google Kepler Anthropic”。其中的关键是：语言模型负责规划，确定性软件负责处理每一个数字，或者更广义地说，负责处理每一条事实。 ## [6:03] Kepler 如何端到端回答问题 · YouTube 我们来拆解一下整个流程。用户提出问题后，大语言模型会充分了解可用工具，并据此制定计划，其中包括确定性的检索步骤、引用过滤器、边界框等。 具体来说，假设我问：“Google 的调整后 EBITDA 是多少？”要回答这个问题，需要从多份 10-K 中检索事实，可能还要跨越不同年份；还得判断投资者演示材料和财报电话会议披露了哪些新信息，或者是否出现了重述，以便更新数字。模型会负责推理这些步骤。之后，我们用工具检索和计算、构建表格，并把整个基础设施登记到引用注册表中。 引用注册表让我们不只能提供数字或事实的数值大小和相关元数据，还能标注事实的类型。举个简单例子：假设我查看 Palantir 的 2025 年 10-K，其中说 Palantir 2023 年的营收是 10 亿美元。那么我刚才说的所有数字都需要加上上下文。尽管这 10 亿美元出现在 2025 年的 10-K 中，也必须标注并作为 2023 年的数据点处理。我说了“十亿”，但如果你看 10-K 或 10-Q，文件里通常只写数字“1”；“十亿”这个单位可能在表格很远的地方单独标着。我们必须给这些复杂对象加上注释，才能产出有意义、可追溯且正确的结果。 模型会在生成后继续说出各种内容，这是它们的本性。如果模型编造了一个数字，而我们无法确定性地证明它来自可信来源，该怎么办？我们必须通过一个后处理步骤，把这类信息剔除。 这样处理后，我们就能提供完整的可追溯性。我认为——而且我相信这是事实——我们提供的追溯粒度是市场上最高的。你可以在 Kepler 平台中点击所有内容。稍后我会展示截图，证明这套架构在整个系统中都能奏效。接下来，我们谈谈 TurboPuffer 在其中如何发挥作用。 ## [8:27] 结构化事实：数值、单位、量级与期间 · YouTube 感谢 TurboPuffer 让我们有机会在这里做这场交流。首先来看一份 10-K。假设我们看到“净销售额总计”这一项，旁边的事实是 416,000。这个数字本身并不能说明什么，对吧？它需要带上相关事实，例如数值、单位、量级和所属期间。 在这个领域工作的人可能会说，XBRL 能解决所有问题，我们不必担心从文档中提取信息。要是 XBRL 只有大约 10% 的时候出错，这种说法或许成立。但更关键的是，投资决策中有多少人只看公开信息？其实很少。他们有自己的 OneDrive、自己的 BIP sync、自己写的各种投资备忘录，以及大量内部信息。因此，我们的架构不能只处理 10-K 和 10-Q，也必须覆盖你的内部数据、SharePoint、Box、Ignite、OneDrive 和 Outlook。 于是，我们会把已经结构化的数据整理好，对尚未结构化的部分实施搜索。这样就能在 TurboPuffer 中创建一个命名空间，将 BM25 与混合搜索结合起来，同时保留 Kepler 平台的完整保证。 ## [9:48] 在 turbopuffer 上进行混合搜索与重排序 · YouTube 下面介绍我们的做法。这大概是大家正在拍照的那张幻灯片，也就是“神奇的一页”。我不担心透露这些内容，因为这是个很难、变化也很快的问题。 我们使用 zero entropy、zero embeddings，这里的维度是 1280。ANN，也就是近似最近邻，再加上 BM25，是我们在整个命名空间中检索信息的方式。看大家都在拍照，太棒了（笑）。这就是我们如何在命名空间中真正抓取信息。 我们会做 reciprocal reranking，确保取回正确的内容，通常是 60K 或 60 份文档；之后还会再做一轮重排序。这是一种可信的重排序方式，会优先取回我们更信任的来源。 例如，不同来源可能各自提供一些声称描述同一件事、但彼此不同的信息。如果财报电话会议的文字记录中，发言人说“我的营收是这个数”，而这个数字与 10-K 中的内容不一致，这不是漏洞，而是一个特性：我确实有两条不同的信息，需要加以消歧。你也需要意识到这一点。 我们用 cross-encoder 进行重排序，然后把结果返回给模型。这个流程建立在两件事上。第一，随着新信息进入，我们能够以极低成本重新生成嵌入。生成嵌入并不便宜；如果你能高效地做到，那很好。但如果你托管自己的嵌入模型——除非你确实自己托管——这件事会变得非常昂贵，也很困难。因此，我们的策略是先广泛搜索，再重排序。 ## [11:30] 租户隔离与安全 · YouTube 租户隔离也非常重要。处理任何文档时，都有不少安全因素需要考虑。比如，如果 Citadel 的一个交易团队看到了另一个团队的研究，那就很糟糕，对吧？因此，文档层面也必须内置安全控制。 首先，从中间的查询到达文档开始，每次命中都会在 PostgreSQL 中重新授权。也就是说，在每一项计算过程中，我们都会检查引用、数值和文档。每个构建环节都会增加新的过滤条件。随着时间推移，我们会逐步构建复杂的过滤器，确保查询信息和数据时，不会在不同来源之间意外泄露数据。 只有 Auth 本身能够创建受限范围的令牌来生成这些信息。当然，用户和“aura”都来自经过签名的设备。我们通过这种方式确保安全，也确保你的超额收益（alpha）留在公司的生态系统内。在一个人人都能使用大语言模型的世界里，什么是 alpha 也是个有意思的问题，可以之后再聊。好，接下来怎么确保一个数字能够出现在 Kepler 平台中？ ## [12:39] 让每个数字都可追溯 · YouTube 首先，我们会为平台中的每条事实分配唯一标识符。这些标识符既要能做实体识别，也要能做实体消歧。每个来源 ID 都对应一组元数据，关联着存储在确定性引擎中的事实。 为了以可定制的方式展示输出，我们需要一个显示值。比如，你希望在整个 Kepler 平台中以“千美元”或日元显示数值，或者采用其他单位，我们就必须能够在后处理中转换并呈现实际结果。我们还必须告诉你结果是如何得到的、来源在哪里。 Kepler 的一条不变原则是：平台中的每个数字、每条事实都可以点击，并查看它实际来自哪个来源。这样我们才能提供真正可引用、确定且可复现的数字。这也是我们能向用户提供的幂等性保证：无论在哪里反复运行同一个查询，都会得到相同结果。 这就是我们必须处理的情况。我们跑完整个数据语料库后发现，所有引用中有三分之一是模型没有做过的计算。这意味着，无论引用来自网页结果、电子表格，还是申报文件的附件，模型本身都可能从自己的语料库或训练数据中编造一堆内容，这些问题很难处理，尤其是查询历史数据时。比如，2005 年的营收数据很可能已经在模型的训练语料中。但即便模型从训练语料中调出了这个数据，我们也无法保证它取自正确年份和正确口径，更无法保证能追溯回来源。 总的来说，这里面三分之一是模型没有做过的数学计算——换句话说，所有引用中有三分之一涉及模型未执行的计算。接下来，我们来看看如何在实际运行中做到这一点。 ## [14:42] 剔除无法验证的内容 · YouTube 随着生成过程不断向前推进，我们会把这些过滤器和引用交给大语言模型，让它实际解析。可以把它理解为：大语言模型对指针进行解引用。随后，系统会在注册表中查找来源，并从注册表取出信息，为你提供可追溯性。 这里真正强大的一点是：如果没有匹配项，我们就会剔除这个数字。这是个非常激进的做法。它意味着你的大语言模型不会像你想象中那样，成为一个能自由发挥、进行猜测和预测的绝佳思想伙伴。就目前而言，如果你依赖模型幻觉，Kepler 并不是一个特别有用的工具。比如，你想发挥创意，或者写营销文案，Kepler 就不是适合的产品。 这也意味着，在金融行业的某些领域，例如靠机会主义销售来开展业务的银行业，可能不那么依赖数字准确性，因为工作目标是销售产品，而不是建立由准确、可追溯信息支撑的 DCF 模型。通过将结果与来源进行核对，我们实际上构建了一个覆盖任意数据语料的真实依据检索引擎，既包括公开上市公司，也包括你自己的内部数据。 这有点令人恼火，因为平台就不能像很多人希望的那样，拥有神奇而强大的能力。那么，我们如何判断应该剔除一条引用，还是尝试修复它？核心想法是增加一个后处理步骤，尝试修复引用。也就是说，如果发现某条信息无法可靠追溯，我们要判断是否应该尝试修复，并实时通过智能体推断它来自哪个来源。答案是，在某些领域我们确实会这么做。这大概是这场演讲中我们可以稍微保留一些、不完全讲透的第二部分，也就是 Kepler 如何保护自己的知识产权。好，接下来看看我们实际运行这些查询时的一些数字。 ## [16:42] 普通 RAG 的问题 · YouTube 大多数从业者现在都在用大语言模型包装金融研究，并认为只要检索增强生成（RAG）做得好，结果就会正确。我们用自己的过滤器测试，方式类似于直接运行 Claude 或 ChatGPT；在评估中，过滤器拒绝了 10,981 条引用。也就是说，我想其中大约有 3,810 条是完全错误的数字。 如果你从事金融分析，这实在令人担忧。这意味着只把 Claude、OpenAI 或其他模型接到一个普通 RAG 工具或向量数据库上，并不足够。如果你只需要语义搜索，确实有很多很酷的事情可做。但只要涉及数字准确性和可审计性，你就不能信任普通 RAG 平台。 这对许多本质上只是 ChatGPT 包装器的初创公司来说是个令人不安的现实。我不是在贬低它们，这只是我们当下所处的现实。因此，必须出现一种新架构，把可审计性和可追溯性与数字准确性等确定性能力结合起来。 模型不会做数学。这是个很简单、但非常关键的洞见。只要遇到模型被迫计算，或者无法推理清楚的情形，我们就会让它无法输出结果。通过后处理步骤，模型不能写出它无法引用的内容。也就是说，平台在结构上无法生成虚构数字。这里我谨慎地说，是平台在结构上做不到；模型本身仍然会产生幻觉，而且确实会。 ## [18:32] Kepler 实际演示 · YouTube 接下来简单看看 Kepler 的界面。这只是平台展示确定性可追溯能力的一小部分。如果有帮助，我很乐意带大家逐步了解。比如，问一个简单问题：“Apple 2025 年的营收是多少、增长有多快？”每个数字都可以点击，因此你不仅能看到它来自 10-K、10-Q、8-K 还是投资者演示材料，还能看到背后实际执行的计算。 比如，系统取了两个数字，算出增长了 6.4%；这一切都会在平台中呈现并且可以追溯。我认为，这种架构会成为标准。如今，金融研究工具的建设者和 AI 从业者面临的机会，受到架构限制——现有架构并不支持他们想要的工作流程。 现在可以搭建完全托管的智能体，让它们基于生成的信息提出想法，但你仍然无法据此产出 DCF。这就是为什么就在附近、或者此刻正在工作的分析师，还得从 S-1 文件中提取信息，把 PDF 里的内容搬进 Excel。我们的目标就是终结这种状况。 ## [19:46] 保证的边界 · YouTube 最后我想强调一件很重要的事：我们的保证也有边界。我们让模型引用数字，而不是编写数字；核验每一条引用；把算术运算交给计算层，而不是模型层；隔离不同租户，并衡量召回率。 这意味着，我们可以保证你在平台上开展的、基于真实依据的研究具有独特价值，但这并不意味着我们现在就能打造一支取代所有人的全功能对冲基金。 我看到的趋势是，投资者会变得更加“quantamental”（量化与基本面结合）。这就是未来，也是机遇。我们越能把独特的检索机制与确定性检索结合起来，就越有机会进入一个非常强大的阶段：AI 终于可以替我们完成那些不想做的事，而不是坐在那里做我们其实想亲自做的构思工作。 最后还有一个附录。非常感谢大家，感谢你们拨冗聆听。