模型之外的企业 AI：Ahmed Bashir 谈共享记忆、系统评测与行动信任

一、嘉宾背景

企业 AI 如何将演示能力转化为实际投资回报，是 Eye on AI 主持人 Craig S. Smith 与 DevRev 嘉宾 Ahmed Bashir 这场对话的主线。讨论涉及数据如何进入模型、企业权限如何保留、智能体应当怎样评测，以及分析结果距离业务执行还有多远。提供的嘉宾资料没有说明 Bashir 在 DevRev 的具体职务，他在访谈中介绍的工程经历和产品工作，为理解这些观点提供了背景。

Bashir 回忆，自己曾学习数据库内部机制，包括 System R、缓冲子系统、转换层和查询优化。这段经历影响了他对数据库技术的重视，也解释了他为何反复强调，数据库积累的结构化处理能力在模型时代仍有价值。他还自述在 Apple 工作约十二年半至十三年，参与了推出 iMessage 和 iCloud 的创始团队，并独自承担 iCloud 备份与恢复功能的后端工程工作。这些履历来自他在节目中的讲述，未经访谈之外的独立核验。

后来，Bashir 参与 DevRev 的创业工作，主张将模型层与记忆层结合，并将团队建设共享记忆的过程描述为持续多年的投入。他对企业 AI 基础设施的重视，与这段职业经历和产品工作相连。访谈中的架构判断也因此带有明确的厂商立场：它们解释了产品为何如此设计，但本身不构成对产品效果的独立证明。

二、本期主要内容

Bashir 从“再数字化”谈起。CD 中的音乐已经数字化，但要适应便携播放、随机播放和播放列表，仍然需要重新组织数字内容及其使用方式。他借此说明，数据采用数字格式，并不意味着它已经适合新的用途。在他的叙述中，云应用、API、微服务，以及将业务数据复制到分析环境，都是类似的变化。面向 AI，数据同样需要一种新的表示方式，使信息能够被索引、连接、关联和排除，进而支持搜索、回答与行动。

他将企业 AI 架构分为三层：现有业务数据系统、推理模型，以及包含语义、编排和治理的“共享记忆”层。这一层的职责超出了保存聊天记录，需要连接跨工具、跨部门的信息，理解员工、客户、产品和工作之间的业务关系。按照 Bashir 的描述，连接必须支持双向流动，因为系统在回答之后可能还要写回数据；汇集信息时，也必须保留原系统的身份与权限。他以单个工具可能存在七套权限系统为例，说明接入既有软件的复杂程度，而非声称所有工具都有同样配置。

Computer 是这套架构的产品实现。Bashir 将其介绍为面向团队的对话式产品：对话背后有可见目录，用户可以查看记录、列表、仪表盘和引用。团队成员能够共同参与对话、使用画布，也可以提交 PDF，生成演示文稿、电子表格与网站。按他的介绍，这些生成物可以进入目录并分享。产品由此尝试将对话纳入持续的团队工作，但这些能力在本集中主要来自嘉宾介绍，不能据此逐项确认部署效果。

Enterprise Bench 回应的则是如何判断企业 AI 的能力。Bashir 质疑“采用领先模型就拥有领先企业 AI”的说法，并将其视为推动这项基准的动机之一。他区分任务复杂度与企业复杂度：业务问题本身未必需要高难度推理，却可能依赖分散在不同工具、版本、权限和角色中的信息。评测因此需要覆盖模型周围的工作条件，检验系统能否在生成答案之前，取得并正确组织所需材料。

三、核心观点：推理、例子与边界

Bashir 的核心判断是，评估企业 AI，必须从模型扩展到完整系统。按照他的介绍，Enterprise Bench 不会预先把数据整理成平面文件交给系统，而是要求系统自行寻找、验证、连接并理解信息。它评测的是整个智能体运行框架，包括数据管理和模型交互。原因在于，检索一旦漏掉关键记录，后续推理即使成立，也可能只是对不完整材料的解释。模型本身的成绩，无法代替对信息获取过程的检验。

他用 CPU 与 RAM 的分工解释这一点：提高处理器性能，不能总是弥补内存不足。这个类比说明了组件之间的替代边界，但并非企业 AI 性能的数学证明。模型升级和数据架构建设因此需要分别评估；它既不能证明某一种共享记忆产品是唯一方案，也不意味着更强的模型对所有任务都不再重要。

访谈中，Bashir 提供了两组比较结果：使用相同 Opus 家族模型时，Computer 相对 Claude Code 的准确率高 50%，token 使用量平均减少约 75%—80%。他明确将准确率的 50% 称为相对差值，而非提高五十个百分点。不过，相关段落没有给出绝对准确率、样本量、完整配置或统计不确定性。使用相同模型，让系统层面的差异值得研究，却不等于工具接入、数据准备、提示和停止策略等因素也已得到控制。这些厂商报告的结果构成了他论证架构价值的依据，尚不足以证明所有企业都能获得同样收益。

Bashir 也强调，分析与行动之间存在一道信任门槛。工单聚类、财务报告关联和失败交易分析，都可以用于展示系统能力；企业是否愿意据此修改 CRM、状态页或财务记录，则是另一层要求。结果进入业务系统后，必须符合相应的治理和语义要求，能否生成总结只是其中一环。Bashir 将这道门槛视为共享记忆需要解决的问题，但访谈没有提供逐项部署证据，完整建立共享记忆与实际效果之间的因果关系。他的诊断框架与产品成效，仍需分别判断。

他提出的分页检索假设，进一步说明了上下文构建的困难：如果有十万个账户，每次只能返回五十个，系统找到相关结果后，如何知道下一页没有更关键的信息？检索涉及多个系统时，还要判断每个来源是否都已充分覆盖。继续探索会消耗 token，过早停止则可能遗漏材料。找到相关记录，与确认回答所需的记录已经找全，是两项不同的要求。

因此，Bashir 主张先用数据库、CPU 和确定性查询构建上下文，再把材料交给模型推理。关系、索引、连接、排除、聚合和投影都有现成机制，可以减少模型反复探索数据的消耗。不过，确定性查询只能保证按既定规则执行，不能自动保证源数据完整、映射正确或查询范围恰当。评测范围也需要明确：他表示，访谈时基准只包含 L1 和 L2 任务。节目报告的成绩主要涉及搜索与回答，尚不能证明系统具备更高自主性的业务执行能力。

四、学习与应用

落实到企业项目，首先需要分别明确业务问题要求作出什么判断，以及判断需要哪些证据。沿用节目中的失败交易分析场景，团队应先确认账户、相关记录和材料分布在哪些系统，彼此如何连接，哪些身份有权访问，再讨论模型怎样综合分析原因。共享记忆和基准设计带来的实际要求，是检验系统寻找、验证和组织数据的能力，而不能只验收最终回答。分页检索尤其需要预先界定覆盖范围和停止依据；如果无法确认范围已被充分覆盖，结论就应限定在已经检查的材料之内。

采购或试点评估中，准确率、token 消耗与业务完成情况也应分别报告。节目中的同模型比较可以作为进一步核查的起点，但仍需补齐绝对基线、任务集、权限、工具配置和失败案例。较少的 token 消耗并不直接等于更高的投资回报，数据准备和运行维护的投入也必须计入。这样的比较需要成本，却有助于判断优势究竟来自什么配置、适用于哪些业务条件，避免将局部结果当作普遍承诺。

行动能力可以按照 Bashir 的自主性框架逐层验收：L1 是单域搜索，L2 是跨域关联和综合回答，L3 涉及单域行动，L4 则是完成一项工作的跨域端到端行动。他表示，访谈时基准只覆盖前两层，后两层尚待逐步加入，因此不能凭搜索与回答的成绩，直接授权更广泛的写回。按照他对分析与执行的区分，系统可以先提交更新建议，由业务负责人检查；是否扩大自主范围，应以相应行动本身的验证结果为依据。

连接器的验收也不能止于读取成功。Bashir 用州与城市字段的依赖关系说明，单个值看似合理，并不代表它在当前对象中合法。写回之前，需要检查身份权限、字段依赖、条件逻辑、允许值和合法状态转换。双向连接提供了执行通道，却不会自动满足这些要求。界面还应展示负责人、优先级、业务记录和可点击引用，使审阅者能够回到具体对象核查。Computer 的目录和画布体现了这一设计方向，但生成、分享产物与修改业务记录，仍需分别验收。

数据库与模型的分工，则应由任务要求决定。重复、精确且范围明确的连接和聚合，可以优先交给数据库处理，再由模型综合解释。Bashir 所说的数据库并不限于传统数据库，还包括适合交易、分析、语义、向量和图模式匹配等用途的数据系统，实践中无需将全部需求塞进同一种结构。不过，查询可重复并不意味着材料可靠。原始来源、转换规则和访问条件仍需一并检查，才能让记忆层为推理提供可核查的上下文。

来源

• 原始节目：Why Enterprise AI Isn’t Delivering ROI | Ahmed Bashir, DevRev