当大语言模型遇上行为预测：为何"下一个token"不是万能解法
本期 Stack Overflow Podcast 邀请到 Yobi CTO Frank Portman，围绕大语言模型（LLM）在行为预测、意图识别等非语言任务上的局限性展开对话。
从数学到代码：Frank Portman 的技术成长路径
Frank 的职业起点出人意料——他最初想成为一名数学家。高中时期，他虽接触计算机和电子游戏，却并未像许多技术从业者那样在 13 岁就开始写代码，"只是知道怎么打开终端"。
进入大学后，Frank 主修纯数学，但在选修课上转向了应用数学，特别是需要手动实现矩阵乘法等底层算法的课程。正是在这个过程中，他发现自己不再是求助者，而是开始被同学请教代码问题。他意识到自己对编程有天赋，并将软件开发描述为"一系列小型拼图"，与纯粹的软件工程——即解决业务问题——有所区别。
Frank 表示，数据科学和机器学习当时正成为热门领域，尽管没有正式的相关教育背景，凭借数学和统计基础，他决定尝试进入这一方向。
LLM 的核心局限：下一个 token 预测为何不适合行为预测
Frank 在节目中提出了一个核心观点：LLM 的归纳偏置（inductive bias）并非为行为预测设计。
模型擅长的是"你训练它做什么，它就做什么"，但用"收集全世界所有文本，也许还有视频，然后训练预测下一个 token"这一思路，是否真能自然涌现出决策能力，这一点并不明确。Frank 认为，LLM 在以下场景表现出色：
- 信息综合：在给定上下文中整合知识
- 代码生成：写作、编程等创造性任务
- 涌现能力：例如用莎士比亚风格写说唱歌词
然而，在不确定性下的决策——即意图预测、行为预测、流程推理等领域——LLM 的能力边界并不清晰。
组合路线：LLM + 专用工具
Frank 并非全盘否定 LLM 的价值。他提出，将 LLM 与正确的工具相结合，才是解决上述问题的可行路径。他将此形容为"agentic everything"（智能体化万事）的兴起，而非期待"一个 LLM 统治一切"。
在谈到 Yobi 的定位时，Frank 将公司描述为一家行为 AI 公司，正在构建行为的"基础模型"（foundation model），用于预测未来行为，应用于广告技术、营销等领域。
训练数据与模型架构：行为预测与语言模型的根本差异
Frank Portman 强调，他们所谓的"基础模型"，与文本、视频或图像生成模型有本质区别。核心差异集中在两个维度：训练数据和训练方式。
专有敏感数据，不适合直接用 LLM 范式
他们的训练数据是专有的、敏感的，甚至能从匿名浏览器会话中识别出具体用户身份。模型处理的也不总是文本，有时只是商品 ID——这种处理方式本身也是出于隐私保护的考虑。
目标不是聊天体验，而是"广泛预测未来行为"
他们训练模型的目标不是打造对话式 AI，而是构建一个广泛预测未来行为的基底表征（broadly predictive future behavior）。这意味着，给一个完全不在训练集中的商品投放广告，模型仍能表现良好——就像大语言模型从未在训练数据里见过"在历史长河中从未有人见过莎士比亚"这句话，却仍能写出类似句子一样。这正是"基础模型涌现"的意义。
技术架构：Transformer + 图神经网络的混合路线
Frank 坦言，从 PyTorch 在 GPU 分布式集群上运行的层面来看，训练过程与标准 LLM 非常相似。但他们的特殊之处在于： 图神经网络解决身份匿名化问题。 语言模型无法很好地处理匿名标识符之间的关联问题，而他们需要将大量匿名 ID 以尊重隐私的方式连接起来，因此图神经网络的图结构非常适合这类场景。
归纳式（Inductive）架构是关键挑战。 他们的数据中有大量离散、高基数的 token（如网站 URL、哈希后的用户 ID）。相比之下：
- 转导式模型（Transductive）：只认识训练时见过的节点，新节点需要启发式方法来近似表示，效果不理想。
- 归纳式模型（Inductive）：能泛化到训练数据中从未出现过的新节点。
用户行为在不断分化——一个人过去的路径可能与现在截然不同，模型必须能对这类新节点做出合理预测。因此他们投入大量精力研发归纳式架构。
规模差距：语言模型 vs 行为预测
语言模型的词表通常在数十万级别（大约六位数），但世界上人类行为的多样性比这高出三个数量级。这也是他们必须突破传统 LLM 范式的根本原因之一。
Frank Portman（12:16）指出，目前模型在行为层面仍是转导式的（transductive）。虽然有办法引入未见过的全新行为，但那是一个与核心用户表征体系相脱耦的独立流程。"我们希望能做到这一点，但这并不是最重要的，"他表示，"在这一方向上，我们已经触及了明显的边际收益递减。" Ryan Donovan（12:46）认为：人类的基本操作系统其实变化甚微。Frank 回应，虽然人们可能做出的行为状态在不断变化，但人们实际做什么的变化才是产品存在的意义——这两者需要区分清楚。
Frank Portman（13:20）明确表示不会进入物理 AI 领域（如机器人方向），而是坚持软件、个性化和预测的核心定位。 他提到一个关键判断："无论那家 LLM 公司走向何方，你可能根本不需要那么多 agent，你需要的只是工具。" 他进一步阐述：其公司的专有数据及其构建产品的方式，可以成为各类场景下的"决策预测推理层"。 具体产品形态——聊天机器人也好、每秒百万 QPS 实时 API 与广告服务器也罢——反而是次要的。"
当然，agent 这条路目前说起来更'性感'一些。" Ryan Donovan（14:17）追问：在 agent 化场景中，决策层具体如何运作？ Frank 的回答是：当上下文或任务需要某种预测或推荐时，就应该调用这个决策层。" 目前我们的接口和集成能力还不够通用，但我认为可以做到。" 关于 Chat 作为人机交互形态，他并不确定这是否只是一种短期风潮。 Ryan 则认为对话是人类自然的沟通方式，"人类之间用语言交流，为什么不让机器也这样做？"
Frank 认可这一点，并回顾了 GPT 诞生的背景：当年不少圈内人对大模型的态度是"我们也能做，只是不觉得有意思"——直到有人真正把它做出来了。
Frank Portman（17:38）指出了当前两个已验证经济价值的 agent 应用场景：编程与口袋里的 LLM 个人助手。前者毫无争议，"我每天都在用，经济价值显而易见"；后者虽然动机尚不完全清晰，但随着能力提升将越来越有市场。他也坦言，这两个场景目前并不需要大量的"决策"行为——编程场景虽然偶尔需要"我决定写入这段代码并等待审批"，但整体仍偏向执行而非决策。
AI 代理的决策边界：高频场景下的工程取舍
"硬决策"难题：AI 能决定营销预算吗？
Frank Portman 认为，当前的 AI 代理在执行明确指令（如"打开日历"）时表现尚可，但面对真正需要判断力的场景——比如"今天我应该在营销上花多少钱"——就力不从心了。这种"硬决策"需要模型在极短时间内预测最优行动，而不仅仅是续写下一段文字。
Ryan Donovan 补充了一个更根本的担忧：过度依赖 AI 辅助决策，是否会让人逐渐丧失自主判断能力？Portman 坦承，他在内部也经常讨论这个问题——当 AI 承担了越来越多 agenda coding（日程编排）类的工作后，团队在"深度思考"方面的能力似乎在退化。
Portman 用了一个类比：就像现代人已经不会使用六分仪导航城市一样，一旦习惯了对工具的依赖，重新捡起来会非常困难。
广告系统：每秒百万级查询的技术现实
当话题转向 Frank Portman 所在团队的实际业务——每秒处理数百万次广告请求——场景陡然切换。在一次请求中，系统需要快速判断：用户当前在哪个出版商的页面、正在观看什么节目、有哪些广告位可用、是否展示广告、展示哪条创意、对应哪个广告投放计划。
Portman 指出了一个常被忽视的挑战：延迟。以广告投放为例，一次请求携带的上下文信息其实非常少——本质上只是一行数据记录。在预训练知识有限、上下文极简的情况下，模型如何预测最优展示策略？这本质上是一个期望值（Expected Value）预测问题，而非简单的序列续写。
他还提到一个有趣的观察：通用大模型能长篇大论地告诉你麦当劳和汉堡王的相似度，高于麦当劳和某汽车品牌的相似度——但这种"世界模型"知识对个性化推荐而言几乎没有实际价值，更多是展示性的" parlor tricks"。
推理优化：先规模、后利润
在高频推理场景下，Portman 承认团队仍然秉持"先抢占市场、再优化利润"的策略。只要架构上没有明显无法弥补的缺陷，宁可牺牲一点效率也要保持迭代速度。但当规模达到一定量级，效率问题会直接威胁商业可行性。
两大核心优化方向： 预计算（Pre-compute）：将尽可能多的计算结果提前落地为嵌入向量查寻表（embedding lookup tables），而非每次请求实时生成。以内存开销换取宝贵的推理延迟预算。
批处理（Batching）：Portman 强调，大量代码路径在处理一条请求和处理两三百条请求的速度差异并不大，关键在于在系统各层级构建批处理和队列机制。这与常见的"一来一回"同步响应模式截然不同，需要刻意的工程投入。
查询缓存：不要存储完整响应
Frank 解释了他们对 lookup tables 的处理策略：团队会缓存热门功能的特征请求，让这些数据更容易被快速访问。但完整响应并不缓存——因为每次出价请求多少都有些不同，尽管有时近乎相同。
他提到一个有趣的思路：可以考虑缓存近乎相同的响应来加速模型输出，随着模型越来越复杂，这条路也许值得探索。
备份出价：延迟超限时的保底策略
广告拍卖场景中存在大量可玩的启发式规则。比如设置一个"备份出价"——它不如主模型好，但在可接受范围内。当延迟预算超限时，直接抛出备份出价，因为此时期望价值"大于零"总比什么都不做更好。
Ryan 认为这种备份链条可以构建得非常精巧。
规则引擎的维护之痛
Ryan 抛出一个关键问题：意图预测模型相比一堆 if 语句，到底能带来多少收益？
Frank 的回答很直接：拆解任何模型，本质上都可以用 XOR 等基本逻辑门实现，但到某个临界点，规则的数量和维护成本会让人宁愿去训练一个模型。他说：
对于机器学习团队，我们更擅长训练模型，而不是维护一堆启发式规则。
整个行业其实仍然重度依赖规则。但 Frank 的公司有一个"后发优势"——没有"前 LLM 时代"的技术债。他在内部常说的一句话是："我们能不能直接解决正确的问题？" 有时候无法直接解决目标问题，就得用代理指标加启发式规则。这些规则有时写得相当深思熟虑，并非简单的 if-else。团队愿意花时间用正确的方式解决问题，如果客观条件允许的话。
扩展边界：广告之外的三条路
Ryan 问如果不看广告场景，还有哪些用例？
Frank 给出了三个方向：
- 营销技术（Martech）：面向现有客户的精细化运营——邮件、短信、个性化产品推荐。用户并不排斥这类互动，因为"我已经给这家公司付过钱了，他们告诉我新款鞋子上市，我觉得挺酷的"。
- 欺诈与风控：这是另一个自然延伸的场景。
- 个性化与预测的长尾需求：各类定制化预测任务构成的广阔市场。
模型架构：基础模型 + 按需微调
Yobi 的模型策略是：先训练一个基础 foundation 模型，然后在每个目标维度上做轻量微调。目标维度目前通常是广告系列（campaign），有时也细化到广告主或客户级别。
Frank 认为，经济上可行的关键在于：利用海量数据完成预训练的规模效应，再用相对轻量的微调流程适配新 campaign 或新数据。"用很少的数据就能微调出好效果"——这正是他对 foundation model 的定义。
世界模型：没有显式使用
Ryan 追问是否使用了世界模型。Frank 明确回答：没有显式使用。他提到世界模型的语境是：大家常说的"不要用 LLM 处理事实"，LLM 不是事实机器——虽然有时候它确实能凭空"召唤"出正确答案，这就是 LLM 带有的某种"世界模型"味道。但 Yobi 并没有在这个方向上做专项实现。
隐私优先的机器学习：Yobi CTO 眼中的行业未来
在播客接近尾声的"未来展望"环节，Frank Portman 并没有聊产品路线图或商业化计划，而是分享了真正驱动他和团队的技术愿景：隐私保护机器学习推荐系统，他认为这个领域"有趣但尚处萌芽阶段"。
从学术到工业：两条技术路径
Portman 指出，隐私计算目前有两条主要的技术演进路径：
- 差分隐私（Differential Privacy）：一种用数学语言定义隐私的方法。核心思想是"k-匿名性"——假设攻击者想从数据集中精准定位某个用户（如 Ryan Donovan），即使付出最大努力查询和过滤，也只能将范围缩小到约 25 人的 pool，从而无法唯一确认个体身份。Portman 也坦言，这一方法在数据分析查询场景表现尚可，但"就我所知，目前还不太适用于模型训练本身"。
- 同态机器学习（Homomorphic Machine Learning）：这才是让 Portman 真正兴奋的方向。同态加密允许在不"看到"原始数据的前提下，直接对加密状态下的数据进行模型训练——即"只操作符号，从不接触明文"。Portman 称其"非常学术，但极其酷"，这也是他希望 Yobi 未来能在学术界做出贡献的方向。
为什么隐私计算对 Yobi 如此关键
Portman 解释了他们面临的独特挑战：Yobi 没有类似社交网络那样围绕统一邮箱 ID 构建的"封闭生态"，而是依赖客户将敏感的消费者数据托付给平台。这种信任不能靠话术，只能靠安全技术 + 算法隐私两手硬。
他表示，团队的目标不是简单引入现有方案，而是真正深入这一领域，甚至发表相关学术论文。
本期嘉宾
Frank Portman，Yobi CTO，播客嘉宾
评论