生成式 AI 的投资回报远超预期？Snowflake 调研全球 1900 位企业与 IT 专业人士后发现平均 ROI 高达 41%！点击下载完整报告
每个人都在努力提高大语言模型的精准度。但真正的挑战并非精度，而是上下文理解能力。在 BUILD 2025 大会上，Hex 合作伙伴工程负责人 Armin Efendic 探讨了为什么传统的方法，如评估套件或合成问题集往往不够有效，以及成功的 AI 系统是如何通过随着时间推移逐步积累上下文来构建的。
由 Snowflake Cortex 提供支持的 Hex，启用了一个新的对话式分析模型，每次交互都让模型变得更聪明。通过 Hex 的 Notebook Agent 与 Threads 功能，业务用户可直接定义核心问题，而数据团队则将这些问题精炼、审计并转化为持久且值得信赖的工作流。
在这个模型中，测试用例不再由数据团队闭门设计，而是由业务需求驱动并在数据工作流中自动实施，最终形成一个具有生命力的上下文系统，而非一成不变的提示词或测试集，它能随着组织共同演进。
准确率不是终点
Armin 开场就把矛头对准了一个常见做法：把业务用户会问的问题合成成一批样例，甚至进一步转成 SQL 查询，然后把这些喂给 LLM，用类似单元测试的方式去衡量它的准确率、稳定性与一致性。他不否认“准确性是顶层关注”，但他强调，把 LLM 当作传统软件组件来做单元测试，本身就是一个不合适的范式。
原因在于，当你把业务问题硬转换为一组 SQL，并据此去构建样例与评估集时，你很难覆盖真实业务中不断变化的语义、不断扩张的问题空间，以及不同用户在不同语境下对同一指标的不同问法。更重要的是，即使你做出了一个看似通过率很高的测试集，也依然回答不了企业最在意的那件事：当它在真实环境中生成了一个结论，你如何知道它不是在胡编？你又如何知道它到底做了什么才得到这个结论？
因此，Armin 把正确性从结果层拉回到系统层：你需要的不是一个靠样例证明自己正确的聊天机器人，而是一套可审计的系统，它能够随着时间变得灵活、可塑，能够让业务用户在使用中不断收敛可回答的问题类型，也能够让系统拥有被“硬化”的路径：哪些能力可以放开，哪些问题必须收紧，哪些定义需要固化，哪些数据应该进入上下文、哪些不应该。
在他看来，真正有效的路线是：从一套能运行、能被观察的系统出发，让系统在使用中暴露问题、沉淀模式，再反过来加固上下文。这种思路听起来不如直接做评估来得爽快，但它更接近企业系统的真实生长方式。
对话式分析如何变成“可审计的系统”
为了把“可审计”讲得具体，Armin 用 Hex 的产品演示展示了对话式分析在真实系统中应该是什么形态。演示从一个非常典型的业务问题开始：假设我是营销经理，我想让系统分析销售机会的“首次触达来源”（first touch source），并做营销归因视角的拆解。这里一个很关键的动作，是他先在系统里配置模型提供方：通过密钥对（key pair）连接到 Snowflake 实例，使用 Snowflake Cortex 内托管的 Claude，并强调这是一个“walled garden”的私有网络环境。这样做的直接意义是：模型驻留在数据所在的环境里，数据可以传递给模型，同时也能让 IT 团队对数据出入边界更放心。
进入线程后，Hex 并不是立刻吐出一句“结论”，而是在后台进行一系列用户不可见但决定可信度的步骤：它会先围绕可访问的元数据“思考”，查看平台上已有的 Hex 项目、仪表板或资产，判断是否存在可复用的内容；它会拉取来自数据仓库的表描述、列描述等元数据，并强调这些可以自动导入、不需要复杂配置；如果企业已经有 dbt 元数据，也可以进一步带入；随后它形成一个“漏斗式”的收敛过程：从广义元数据到相关表、再到更具体的模型信息与底层数据，最后才开始把 SQL 单元格、可能的 Python 单元格、图表与可视化逐步组织起来，用以回答最初的问题。
这也解释了他在演示里专门强调的一个点：这种模式一开始会“慢”，但这是刻意设计的。因为此时系统面对的是生产数据仓库，它需要把大量上下文带进来，需要推理与迭代，而这类深度思考天然会以时间为代价。换来的收益是：它可以生成更细致、接近数据科学家或嵌入式数据分析师水平的分析过程。Armin 也提到，未来会有更偏“快速、短促回答”的迭代版本，可能更多依赖语义模型，而不是每次都在全量上下文里深挖。但在这个阶段，他们优先解决的是“在没有分析师介入的情况下，业务用户也能得到一份扎实的分析报告”。
当线程生成结果后，界面里不仅有图表，还能继续做探索：拖拽维度与度量、查看底层表格数据、检查异常、做更深的切片。这时“可信度焦虑”就会自然出现：这么多信息暴露给业务用户，我怎么知道它没有幻觉？我该不该信这些 SQL？我如何让它更确定？Armin 的回答不是“相信模型”，而是把系统的底座亮出来：在 Hex 里，每一个线程、每一个项目，背后都由笔记本支撑。把线程保存为项目后，你可以在笔记本里看到完整对话以 Markdown 的形式呈现；更重要的是，你能看到它实际运行的 SQL、过滤条件、连接逻辑、图表生成过程，以及它如何一步步构建出整份报告。对于负责准确性与治理的数据团队来说，这种“把对话落到可审计的笔记本”非常关键——它让系统从一开始就具备被审核、被追责、被修正的可能。
在此基础上，Armin 进一步展示了一个更现实的协作场景：业务用户提出问题后，不一定要立刻去找数据团队提工单，而是先在对话线程里得到初步洞察；如果需要更深入的分析（比如进一步做季节性拆解），技术用户可以把笔记本智能体（notebook agent）限定在这个项目范围内，和智能体一起继续规划、推理、生成图表，并在生成的“待处理变更”中逐条审核、决定保留哪些结果。分析由此变成一种可协作、可迭代、可沉淀的工作流，而不是一次性、不可解释的问答。
从一次性对话到可复用资产
如果到这里为止，Hex 展示的是“可观察性”，那么 Armin 在后半段想讲的，是上下文如何变成系统能力，如何从一次性对话沉淀为可复用资产。
他先展示了一个从笔记本走向应用（app builder）的路径：当某些分析内容需要“持久化”，例如营销与销售负责人希望随时看到季节性分析或关键指标，而不是每次回来重新提问，那么就可以把笔记本中已经生成的图表、文本等资产拖拽到应用构建器里，做成一个仪表板、报告或更像 BI 的交互界面。这里的核心并不是“又做了一个 BI”，而是强调：即便呈现形态变成 BI 风格，背后依然由笔记本驱动，仍然保留 SQL、Python、Snowpark 等灵活性；同时，笔记本与应用这两种范式始终连接，资产是可回溯的。换句话说，展示层可以更友好，但底层逻辑并不会因此变成不可审计的黑箱。
紧接着他抛出了“连接胶水”的问题：当我们有线程、有笔记本、有应用，如何让它们构成一个一致的策略？答案是语义模型——它是 Armin 所谓“上下文引擎”的关键组成部分。原因也很务实：企业里那些精心构建的报表与仪表板，通常包含大量转化逻辑、业务口径、SQL/Python 查询，这些恰恰是 LLM 最需要、也最容易误解的上下文。如果不能把这些上下文结构化，LLM 的确定性就无从谈起。
在演示里，语义模型有两条路：一是导入已有的 Snowflake semantic view。Hex 可以浏览生产仓库、发现可访问的语义视图，然后快速引入，例如引入一个 B2B sales model，让 enriched metadata 直接在 Hex 中可用。另一条路更贴近多数团队的起点：不是先有语义视图，而是先有一堆被业务反复使用的仪表板项目。Hex 的语义建模工作台里有一个“建模智能体”（modeling agent），它能理解 Hex 的语义建模能力，并且能针对某个具体项目（例如 sales and marketing dashboard）去阅读项目里包含的 SQL 单元格、DataFrame 操作、joins、函数与过滤条件，形成建模计划，做错误预防，推断表关系，把“项目里已经存在的业务逻辑”烘焙进语义模型中。
这一段其实回答了一个关键的企业问题：语义模型从哪来？它不一定需要从零凭空设计，它可以从企业已经在用的分析资产中被抽取、被规范、被版本化。建好之后，语义模型还能用一种“拖拽式”的方式被检查：你可以选择维度、度量，查看聚合、查看系统生成的 SQL，在发布之前把模型硬化到你满意的程度。
更进一步，Armin 也回应了“供应商锁定”的担忧。他明确表示，Hex 不希望用专有 YAML 把用户锁死，并提到两个方向：其一是和 Snowflake 等一起推动“开放语义交换”（Open Semantic Interchange），一个由约 18 家甚至更多公司组成的联盟，目标是让语义模型信息能在不同系统之间互换，以促进 LLM 采用并避免 vendor lock-in；其二是更近期开启“写回”能力，让在 Hex 中构建的语义模型可以写回到 semantic views 中，保证不同系统间“友好共存”。这些内容在分享里出现得很明确：终点不是锁定格式，而是让用户愿意因为体验与工作流而持续使用。
当语义模型准备好后，线程侧的使用方式也随之变化：你可以把对话线程限定为“只使用语义模型”，而不是访问整个生产数据仓库。Armin 强调，这会让系统随着时间更确定：当你不断硬化语义模型、补充上下文，它会越来越稳定、越来越可控。也正因此，他再次回到开场的观点：把精力放在构建上下文系统上，而不是试图用合成样例把原型聊天机器人测到“看起来准确”。
规模化审计与上下文飞轮
分享的最后一部分，Armin 把问题推到最现实的规模化挑战上：当系统从一个人试用扩展到五十、一百个用户时，你如何监控它？你如何知道 LLM 系统到底在做什么，业务用户到底拿它解决什么问题？这时，“可审计”就不能停留在某个线程或某个项目，而必须成为一套能覆盖全局的治理能力。
他提到 Hex 的“上下文工作室”（context studio），目前处于少数 Alpha 合作伙伴的 Alpha 阶段，但他之所以专门强调它，是因为它承载了上下文系统最关键的一环：理解使用行为，反过来指导上下文如何演进。
具体来说，你可以看到平台总体使用情况：用户更常用笔记本还是线程？创建了多少语义模型？也可以按对话量看用户分布，查看某个用户使用线程的频次、提问的类型。更重要的是，当你下钻到“问题类型”时，Armin 给出了一个很强的判断：这些真实问题才是你的单元测试。不是你在上线前试图一次性“破坏一切”并用评估集兜住，而是看清业务用户到底在问什么，再回去硬化你需要硬化的上下文与问题类型。
围绕“如何策划上下文”，他在分享里给出了三个层次的抓手。最直接的是规则文件（rules file）：你可以在里面定义 SQL 的数据质量防护、业务定义、偏好的 SQL 风格、杂项信息，以及希望系统使用的可视化方式，并且这些内容可以即时编辑、保存或导出。第二层是“经认可的数据”（endorsed data）：由数据团队或所谓“金层”背书的数据资产，可以在 Hex 的语境下被定义清楚，决定哪些数据可以喂给 LLM。第三层则是更成熟、也最关键的做法：语义项目（semantic projects）。随着审计能力增强，你不仅能看到语义模型被使用的次数，还能观察是否有多个语义模型被同时使用、是否需要在某些场景中合并；你也能判断哪些项目最常被引用，从而决定是否需要对下游数据做更多建模，或者是否需要补充列描述、表描述等元数据来改善上下文质量。
这些细节共同指向同一个结论：上下文不是一次性设计出来的，它是被真实使用不断“磨”出来的。你从稍微宽的范围起步，抽取一两个语义模型，让业务用户用起来；再通过审计看到真实问题与真实路径，回去修规则、补语义、加背书数据、完善元数据。如此循环，系统才会越来越确定、越来越可信。
这场分享最有价值的地方，在于它没有把“可信”简化为一个指标，也没有把“准确率”当作唯一的归宿。Armin 反复强调的其实是另一套思维：企业要的不是一个在评估集上表现漂亮的聊天机器人，而是一套能持续吸收上下文、可审计、可治理的系统。
从线程到笔记本的可观察性，从笔记本到应用的资产化，从项目到语义模型的上下文结构化，再到面向规模化使用的审计与上下文工作室——这些环节被串成一个整体，目的只有一个：让 LLM 在真实业务里变得更确定，并且在需求增长时仍然能保持可控与可信。
原视频地址：https://www.snowflake.com/en/build/americas/agenda/?login=ML
🔥【活动推荐】2 月 2 日-6 日，Snowflake Discover 重磅上线！这是一场免费、线上、可实时互动的技术活动，旨在帮助您全面提升数据与 AI 能力，深入了解如何更高效地管理、整合与分析数据。4 天时间 18 场技术干货分享，由来自亚太地区的一线技术专家亲自分享与讲解～
点击报名 Discover，更多 Snowflake 精彩活动请关注专区。
