工作坊环境与资源准备

本次研讨会旨在通过实际代码操作，深入体验不同顶级大语言模型之间的差异。讲师指出，环境变量的配置是访问 Microsoft Foundry 项目上部署的多个模型的关键。由于资源有限，环境变量文件中包含了多种可能的配置选项。如果在使用特定模型时遇到 429（速率限制超出）错误，参与者可以切换注释掉其他可用的模型配置。讲师提到：“I only got found out very recently that this workshop was accepted, so I tried to get as much resources as I could in the small period of time.” 为了确保顺利运行，讲师安排了同事 Cedric 在旁协助解决技术问题。对于本地环境，若已安装 Python 和 UV，只需克隆仓库并运行 uv sync；若无本地环境，可直接使用 GitHub Codespace 提供的浏览器版 VS Code。讲师现场统计发现，几乎所有人都使用 Python，这为后续的代码演示奠定了基础。

核心目标：从基准测试转向场景化评估

工作坊的核心目标是让参与者获得对不同顶级模型差异的直观感受，并学习如何针对特定场景优化 AI 应用。讲师强调，虽然基准测试（Benchmarks）和安全评分能提供模型质量的近似概念，但真正的模型能力只有在特定应用场景中才能得到验证。由于 AI 应用的使用方式多种多样，单一的基准测试无法完全预测模型在用户具体场景中的表现。此外，考虑到地缘政治风险（如美国政府可能切断对某些模型的访问），AI 工程师必须具备模型切换和优化的能力。因此，本次研讨会提供了丰富的场景示例、评估和优化方法，旨在帮助工程师建立多模型备选方案（Optionality），确保应用的鲁棒性。

对比模型阵容与基础代码结构

本次工作坊重点对比的四款部署在 Microsoft Foundry 上的顶级模型包括：GPT-5.5（讲师日常使用的标准模型）、Kimi K2.6（近期发布且表现优异的新模型）、DeepSeek V4 Flash 以及 Mistral Large 3。为了演示模型切换的便捷性，代码仓库中的示例文件默认将 model 变量设置为 GPT-3.5 作为基线。讲师解释：“That's kind of our baseline... But then if we want to try a different model, we can just uncomment that line and that will be the model that gets used.” 这种设计允许用户通过简单的代码修改，即可将 OpenAI Python SDK 的连接指向 Foundry URL 并使用相应的环境变量密钥。这种结构化的代码组织方式，使得在不同模型间进行快速切换和对比变得极其简单。

基础测试案例：LLM 计数任务演示

为了直观展示模型能力，讲师首先进行了一项基础的“字母计数”测试。提示词要求 LLM 计算句子 “The elderly gentleman eagerly entered the elevator. Count carefully.” 中字母 'E'（不区分大小写）出现的次数。讲师指出，尽管 LLM 并非为数学计算设计，但 GPT-3.5 在类似任务中表现出乎意料地好。他提到：“My colleagues have been running a lot of finance benchmarks on it lately and they're like, 'Oh my god,' like it does so much math in its head.” 通过运行 uv run examples 执行该脚本，参与者可以看到模型返回的原始输出。这一基础测试旨在揭示不同模型在处理精确指令时的细微差别，为后续更复杂的场景评估提供起点。讲师强调，这种“经典”的计数任务是检验模型遵循指令准确性的有效手段。

基础逻辑与提示工程对模型表现的修正

在基础的计数任务中，不同大语言模型的表现呈现出显著差异。当使用 GPT-3.5 作为基准时，其能够准确完成任务并得出正确结果。随后切换至 Kimi，Kimi 同样展现了强大的计数能力，得分为 13。然而，当测试对象变为 DeepSeek V4 Flash 时，结果出现了明显下滑，该模型仅得分为 6。这一数据表明 DeepSeek V4 Flash 遗漏了七个关键的 'E'，直接反映出其与前述两个模型在基础逻辑处理能力上的差距。最后测试的 Mistral 得分为 8，虽然优于 DeepSeek V4 Flash，但仍存在不足。

面对这种模型间的性能波动，提示工程（Prompt Engineering）成为提升输出质量的关键手段。通过引入思维链（Chain of Thought），例如要求模型“将句子拆分为单词、逐词计数并展示推理过程”，可以显著改善结果。在 Mistral 上的测试证实了这一点：经过简单的提示优化，Mistral 成功给出了正确答案。这一案例直观地展示了模型能力并非固定不变，而是高度依赖于输入提示的结构与引导方式。通过强制模型展示中间步骤，能够有效弥补其在直接推理上的短板。

RAG 场景下的幻觉控制与事实 grounding

检索增强生成（RAG）是评估模型是否严格遵循上下文的重要场景。在 RAG 应用中，核心要求是模型必须基于提供的参考资料回答问题，严禁利用自身训练数据中的权重生成虚构内容。测试中构建了一个关于“木蜂（carpenter bees）”的数据集，并询问其与“蜜蜂（honey bees）”筑巢方式的区别。由于资料中仅包含木蜂信息，理想的回答应明确指出无法提供蜜蜂的相关信息。这一测试旨在考察模型是否具备“承认无知”的能力，即能否区分信息来源是检索内容还是内部知识。

测试结果显示，GPT-5.5 和 Kimi 均表现出色。GPT-5.5 明确指出“数据集未提供关于蜜蜂筑巢细节的信息”，展现了优秀的 grounding 能力。DeepSeek 同样表现良好，声明提供的来源中不包含相关信息。然而，Mistral 出现了典型的幻觉问题：它直接利用内部权重回答了关于蜜蜂的信息，尽管这些信息并未包含在提供的资料中。这表明较小或较弱的模型更倾向于依赖其预训练数据而非检索到的上下文。为了纠正这一问题，测试者尝试通过提示工程强制模型引用来源，但即使在被要求“证明信息来自源文件”的情况下，Mistral 依然给出了错误的外部知识。这揭示了在 RAG 应用中，评估模型是否愿意承认未知以及产生幻觉的概率至关重要。

多模态图像识别中的细节辨析能力

随着模型向多模态发展，图像输入处理能力成为新的评估维度。测试使用了三张具有挑战性的本地图片：一张看似独角兽但实为原牛（aurochs）的图片、一张在哥斯达黎加拍摄的鳄鱼照片，以及一张包含极小字体的植物列表截图。这些图像旨在测试模型在视觉识别准确性、细微特征辨析及小文本读取方面的能力。例如，区分鳄鱼与短吻鳄（alligators）需要关注口鼻部的形状特征，而识别原牛则需要克服“独角兽”这一视觉误导。

测试首先要求模型判断第一张图片是否为独角兽，这是一个基础的真伪辨别任务。GPT-5.5 凭借其对相关知识的掌握（如维基百科内容），能够准确识别出这是原牛而非独角兽。这一环节展示了模型在结合视觉输入与内部知识库进行交叉验证时的有效性。虽然字幕片段在此处中断，但整体测试逻辑表明，多模态模型不仅需要“看到”图像，更需要准确解析其中的细微差别和文本信息。对于包含小字体的表格截图，模型能否正确读取并提取数据，将是衡量其 OCR（光学字符识别）与理解能力的重要指标。这一部分测试强调了在复杂现实场景中，模型对视觉细节的敏感度和准确性是区分优劣的关键标准。

多模态视觉识别能力的横向对比测试

本次测试首先对 GPT-5.5、Kimi 和 Mistral 在图像理解任务上的表现进行了评估。测试用例包含一张显示鳄鱼的图片以及一张含有植物价格表格的小截图，要求模型识别动物种类并找出最便宜的植物。GPT-5.5 展现了卓越的多模态能力，它不仅正确识别出图片中的动物为鳄鱼（crocodiles），还精准地从复杂的表格截图中找到了价格最低的植物。随后测试 Kimi，结果同样令人满意，Kimi 准确识别了动物并找出了最便宜的植物选项。这表明在基础视觉理解和文本提取方面，GPT-5.5 和 Kimi 均表现优异。

相比之下，Mistral 在多模态任务中暴露出明显短板。面对相同的鳄鱼图片，Mistral 未能识别出准确的物种名称（aurochs），甚至表现出困惑，将其误判为短吻鳄（alligators）。在价格查找任务中，Mistral 提取出的植物价格为 $2.30，而正确答案应为 58 cents。Mistral 无法准确回答此类图像相关问题，显示出其在视觉细节捕捉上的不足。

"So, the Mistral isn't able to answer these kind of images."

多模态理解的局限性与语言依赖性分析

在多模态理解领域，提示词工程（Prompt Engineering）的作用非常有限。与纯文本任务不同，图像输入的理解能力主要取决于模型本身的视觉编码水平。除非在特定领域提供明确的图表阅读提示，否则很难通过优化指令来弥补模型对图像理解的先天不足。用户需要明确判断目标模型是否真正理解特定类型的输入图像，而非依赖技巧性提示。

此外，语言环境对多模态模型的性能有显著影响。测试者在使用英语时能正常进行动物识别，但当切换至西班牙语提问（如区分 caimanes 和 cocodrilos）时，模型表现崩溃。GPT-5.5 等主流大语言模型具有强烈的英语中心主义倾向，在跨语言任务中容易因词汇映射混淆（如区分佛罗里达的 caiman 与西班牙语的对应词）而给出错误答案。对于加州等双语环境的应用开发，语言切换可能导致模型性能大幅下降，需格外注意这一风险。

"It's fascinating to see that once we switch to Spanish, it fails at the task."

函数调用（Tool Calling）的基础原理与测试设计

在探讨完多模态能力后，测试转向了函数调用（Function Calling），也称为工具调用。这是构建 AI Agent 的核心基础，模型需在训练阶段学习如何根据用户输入和函数定义来生成调用指令。测试采用 JSON Schema 格式定义工具，例如创建一个名为 create_calendar_event 的函数，包含标题、描述和参数等元数据。这些定义连同用户自然语言请求一起发送给 LLM，由模型决定是否需要调用工具以及如何填充参数。

测试场景设定为一个日历助手任务。用户请求在明天下午 1:30 通过 Microsoft Teams 虚拟会议安排一次 "Platform Team Sync"，参会者包括用户本人、Sarah（来自 Ange）、Marcus 和 Priya。系统提示词明确告知模型当前日期为 6月29日星期一，并要求其使用可用工具处理请求。这种低层级的调用测试旨在观察模型是否能准确解析自然语言中的实体信息，并严格遵循函数定义的参数约束进行调用。

"Tool calling is in fact the basis of like all agents."

各模型在函数调用任务中的表现差异

测试结果显示，不同模型在处理结构化参数时存在显著差异。GPT-5.5 整体表现良好，正确调用了 create_calendar_event 函数并填充了大部分参数。然而，它在参会者列表中错误地将用户本人（"me"）添加为与会者，尽管这并非用户的本意。Kimi 同样调用了正确的函数，但在参数约束 adherence（遵循度）上存在瑕疵：它将地点描述为 "virtual {parentheses} Microsoft Teams"，引入了非预期的括号字符；同时它也错误地将用户添加为参会者。DeepSeek 的表现类似，同样未能严格遵守参数约束。

这些错误揭示了当前模型在复杂指令遵循上的模糊性。当模型调用参数出错时，往往意味着提示词描述中存在歧义或约束不够明确。测试者指出，需要回溯优化函数定义的描述部分，以更清晰地界定参数边界。Mistral 在此环节的表现同样受到关注，但其具体输出细节在片段中未完全展开。总体而言，函数调用测试强调了精确的参数定义和清晰的指令约束对于提升模型工具使用准确率的重要性。

"If it called it with the wrong arguments, that means there's ambiguity."

循环工具调用中的效率差异测试

在构建智能体（Agent）的过程中，工具调用的循环机制是核心环节。与单次调用不同，智能体需要在达成目标前持续进行工具交互。为了评估模型在此场景下的表现，测试设定了一个包含多步计算的数学应用题（如计算含税总价），并强制要求模型不得在内部进行心算。这一测试旨在揭示不同大语言模型在处理复杂逻辑时，是倾向于将多个步骤合并为单次高效调用，还是拆分为多次低效请求。

测试结果显示了显著的效率分化。GPT-5.5 展现了极高的优化能力，它成功将所有计算步骤整合为一个长表达式，仅通过 1 次工具调用即得出最终结果。这种并行处理能力大幅减少了网络请求次数，提升了响应速度。相比之下，DeepSeek 虽然答案正确，但采用了分步执行策略，进行了 4 次工具调用。由于每次调用都涉及独立的网络请求，这种模式在延迟和资源消耗上远不如单次批量处理高效。Kimi 的表现通常与 GPT-5.5 相当，但在某些情况下会出现异常的自我检查循环。例如，Kimi 可能在首次尝试正确后，仍额外发起多次调用以“复核”结果。正如演讲者所言：

"Kimi most of the time works quite well, but Kimmy does sometimes get into weird loops when it's kind of like double-checking itself."

这种冗余调用不仅浪费资源，也反映了模型在置信度判断上的不稳定性。因此，工具调用的数量直接决定了智能体的执行效率。在评估模型时，除了关注最终答案的正确性，必须量化其达成目标所需的交互轮次和调用次数。

多模型并行工具调用效率对比

在Agent框架中，工具调用的循环机制（Harness）存在细微差异，这直接影响了不同模型执行任务的效率。以Kimi为例，它并未采用并行调用策略，而是依次进行了搜索航班、搜索酒店等操作。由于缺乏并行处理能力，Kimi不仅多花费了时间，还额外增加了两次检查预算的调用，导致总工具调用次数比预期更多。Kimi没有进行并行化，这使得其在处理需要多步骤协同的任务时显得不够高效。相比之下，DeepSeek虽然同样未进行并行化操作，但其仅使用了4次工具调用便完成了任务，表现相对合理且高效。这一对比揭示了评估Agent的核心难点在于多维度的观察。正如演讲者所言："Agents are the hardest to evaluate because there's so much going on along the way." 我们需要同时关注模型是否调用了正确的工具、调用过程是否高效，以及是否能够并行处理多个独立任务。

评估框架的多样性与基础字符串检查

在构建大语言模型应用时，选择合适的评估（Evals）框架至关重要。目前大多数可观测性提供商如 LangFuse、LangSmith、LangChain 和 Arize 都内置了评估框架。对于 Foundry，作者提供了 Azure AI Evaluation SDK、OpenAI.evals 等工具；JavaScript 开发者则可以使用 DeepEval 和 Prompt foo。虽然存在多种复杂框架，但在处理简单的字符串匹配时，并不一定需要引入复杂的评估工具。作者指出：“If you're looking for it to do a specific... Yeah.” 这种基础检查适用于明确的目标验证，但在实际生产中，往往无法仅靠基本方法满足需求。因此，当输出变得模糊或需要更精细的判断时，必须转向更高级的评估策略。

LLM 作为裁判（LLM as a Judge）的核心机制与实现

当基础字符串检查失效时，使用 LLM 作为裁判（LLM as a Judge）成为解决模糊输出的关键手段。这种方法要求将 LLM 置于“裁判模式”，明确指示其评估任务，并输出结构化的结果。作者强调：“you need to give it, you know, put the LLM in judge mode and say... does this pass or fail?” 为了获得可靠的判断，除了输入查询和响应外，还必须提供上下文（Context），特别是对于工具调用等复杂场景，需提供完整的工具定义和追踪记录。作者通过代码示例展示了如何构建这一过程：指定 GPT-5 为裁判模型，要求其输出包含“通过/失败”状态及理由（Reason）的 JSON 数据。这种全信息输入方式有助于裁判更准确地推理，从而区分是应用本身的问题还是评估标准的问题。

性能瓶颈、预计算策略与人类校准的重要性

尽管 LLM as a Judge 提供了更细致的评估，但其计算成本高昂且速度缓慢。每次评估实际上涉及两次 LLM 调用：一次生成应用响应，另一次由裁判模型进行评估。若使用多个评估器（如五个不同的 LLM 作为裁判），调用次数将成倍增加。作者指出：“every single eval case is actually two LLM calls... that's what is tricky about evals.” 因此，在生产环境中（如 RAG 系统通常需测试 200-800 个用例），无法在每次 CI/CD 提交时实时运行所有评估。为缓解这一问题，推荐采用预计算策略（Pre-running）：提前获取问题和答案的上下文，使评估器独立于应用逻辑运行。此外，必须通过人类专家输入进行校准（Calibrate），确保 LLM 裁判的判断与领域专家的标注一致。作者特别推荐 Hamel.dev 的资源，并幽默地提到：“building an LLM as a judge it's hard.”

微软新工具 Assert：基于规范的评估生成

针对构建高质量裁判评估器的复杂性，Microsoft Research 发布了新工具 Assert。该工具旨在帮助用户基于规范（Spec）编写裁判评估器。用户只需定义代理的行为规范和预期结果，Assert 即可辅助生成相应的评估逻辑。这一工具的出现简化了以往需要深入理解最佳实践、跟随专家学习（如 Hamel 的课程）才能构建有效评估器的过程。虽然具体技术细节在片段中未完全展开，但其核心目标是降低构建可靠 LLM 裁判的门槛。作者提到：“Assert helps you write the judges based off of the spec.” 这标志着评估领域正朝着更标准化、自动化方向发展，但仍需结合人类校准和预计算策略以平衡效率与准确性。

Assert 框架：从 YAML 规范到自动化测试集生成

Assert 是一个旨在帮助开发者构建评估器（Evaluators）和测试集的框架，其核心理念是通过研究驱动的方法自动化生成评判标准。用户只需描述期望的行为、工作原理及支持的用户类型，系统便会基于此生成大量测试用例。具体而言，它会将用户的初步构想转化为实际的评判指标（Judging Rubrics），这一过程在旅行规划器案例中已得到验证。开发者需要编写一个 YAML 文件来定义评估上下文，尽管作者坦言对 YAML 的情感复杂，但承认其在特定场景下优于其他格式。YAML 文件用于描述上下文、选用的评判模型以及关注的维度，例如预算压力（充裕、紧张或隐形）。这种设计支持分层评估（Stratification），用户既可以预先设定层级，也可以让系统自动生成。此外，框架还包含辅助编写 YAML 的 Agent Skill，以降低手动配置门槛。

旅行规划器评估案例：行为分类与模型对比结果

在具体的执行层面，Assert 确保对 LangChain 旅行规划器的每一次工具调用进行追踪，以便进行全面评估。系统运行后会生成详细的结果报告，首先识别出不同的行为类别，如预算不可行、直飞偏好规则违反或必需工具未使用。随后生成具体的测试场景，例如“Scenario 65: Red eye before the installer walked through the coach with six parent text one weekend to see Alma”，这些由 LLM 生成的标题旨在模拟真实用户行为，解决生产前评估数据匮乏的痛点。在对比测试中，系统对 DeepSeek、Kimi 和 GPT-5.5（字幕误识别为 GBd 5.5）进行了评估，数值越低代表表现越好。结果显示 GPT-5.5 在该场景下的违规次数最少，得分最佳。作者对此感到惊讶，因为 Kimi 通常表现优异且被认为与该模型持平，但在本次特定场景中 GPT-5.5 胜出。这证明了构建自定义评估器对于准确衡量 Agent 性能的重要性，而非依赖默认的连贯性或流畅性指标。

DSPy：基于遗传算法的提示词自动优化

针对切换模型时需手动调整提示词的痛点，作者引入了 DSPy 作为最终解决方案。DSPy 的核心理念是将程序约束声明为代码，而非硬编码提示词。开发者定义输入输出结构及约束条件（Spec），DSPy 则负责生成满足这些约束的提示词。其背后采用了名为 Jepa（遗传算法） 的技术，通过迭代评估寻找最佳提示词组合。这种方式要求重写代码逻辑：不再在代码中直接嵌入 Prompt，而是将 Spec 作为输入，让 DSPy 输出优化后的提示词。作者强调这是一种范式转变，开发者通过检查约束条件并观察算法生成的迭代过程，能够自动化地找到适配特定模型的最佳提示策略。尽管需要重构代码以适应这种声明式编程模式，但它解决了在不同模型间迁移时提示词工程的高昂成本和不确定性问题。

DSPy 自动提示词优化与模型独立性

在构建自动化工作流时，DSPy（Declarative Self-improving Python） 提供了一种将提示词工程转化为代码优化的新范式。其核心逻辑是通过定义严格的约束条件（Constraints）和检查机制，让系统自动迭代寻找最优提示词。具体流程包括设定输入规范、配置验证测试，随后运行 Jepa 优化器（注：原文发音或拼写可能指代特定优化算法，此处忠实记录），该优化器会在解空间中进行“爬山”式搜索（Hill Climbing），直到找到满足所有约束条件的提示词。这一过程需要指定学生模型（Student Model）和反思模型（Reflection Model），虽然耗时，但能确保输出质量。

"So, you need to set up your spec and then set up like checks, tests to see... And that way Dspy can keep iterating, hill climbing until it finds a prompt that satisfies those constraints."

这种方法的实际效果显著。在一个具体案例中，优化过程耗时约 6 分钟，最终生成的系统提示词专门针对 Mistral 模型进行了适配。由于 Mistral 是此前调试难度较大的模型，这一成果证明了该方法的鲁棒性。关键在于利用这种自动化手段实现“模型独立性”。正如 Dropbox 和 Shopify 等公司所实践的那样，通过 DSPy 结合优化器找到最佳提示词后，企业可以从昂贵的大模型迁移到更小、更便宜的本地或云端小模型上部署。这不仅降低了成本，还保留了同等水平的输出结果，极大地提升了技术栈的灵活性。

Anthropic 模型特性与 RAG 引用机制

除了主流开源模型，Anthropic（Claude） 在 API 调用和特定功能上具有独特性。由于 Anthropic 使用不同的 Messages API，开发者需要调整代码结构才能接入，这通常是其在演示中被暂时搁置的原因。然而，Anthropic 在 检索增强生成（RAG） 场景中展现出显著优势：其模型原生支持结构化引用（Citations）。

在使用 Anthropic 时，开发者可以将源文档以特定结构化格式输入（如指定文本内容），并启用引用功能。模型经过专门训练，会在返回的文本块中嵌入 citation 标记。这种机制允许程序化地提取引用信息，前端应用可以直接将这些引用链接到原始文档。对于需要高可信度和溯源能力的 RAG 系统而言，这种内置的引用能力比后处理提取要可靠得多。这展示了不同模型在 API 设计和功能侧重上的差异，开发者应根据具体需求（如是否需要原生引用支持）来选择模型。

本地部署支持与资源管理建议

为了降低实验门槛，相关代码库已扩展支持 Llama 本地模型部署。对于希望尝试开源模型的开发者，只需将示例代码中的模型名称指向本地的 Llama 服务器地址即可。由于大多数本地推理框架（如 Ollama、vLLM）通常兼容 OpenAI 风格的 API，因此原有的代码逻辑无需大幅修改即可运行。这为开发者提供了在本地环境验证不同模型性能的可能性。

"I do need to rotate the keys that I put in that .env because... I won't be able to keep those keys up for much longer."

最后，关于资源管理，作者提醒用户代码库中的环境变量密钥（API Keys）需要定期轮换。出于安全考虑，这些临时密钥不会长期保留在公开仓库中。开发者应自行配置合法的 API 凭证或本地模型路径进行实验。鼓励用户通过实际 tinkering（折腾/调试）不同模型来深入理解其差异，因为只有通过亲手尝试 Mistral、Kimi、DeepSeek 等模型的不同表现，才能真正掌握如何根据任务特性优化输出和评估结果。

结论

本次对比证实，GPT-5.5在逻辑准确性、多模态细节辨析及Agent工具调用效率上表现最优，尤其在单次调用的并行处理能力与幻觉控制方面优势显著。Kimi K2.6在基础任务中表现优异，但在多步Agent循环中存在冗余自我检查导致的效率损耗。DeepSeek V4 Flash在基础逻辑上存在明显短板，但在Agent执行中展现了合理的调用次数。Mistral Large 3在RAG场景下幻觉严重，多模态识别与OCR能力不足，且对非英语提示词敏感。

评估方面，LLM作为裁判虽精准但成本高，需结合预计算与人类校准；Assert框架通过YAML规范简化了评估器构建。DSPy利用遗传算法实现了提示词的自动化优化，有效解决了模型切换时的适配难题并支持向低成本小模型的迁移。