أمازون تكشف عجز وكلاء الذكاء الاصطناعي أمام الإجراءات التشغيلية الطويلة

亚马逊揭示AI智能体难以应对冗长操作规程 亚马逊数据表明，由于工作文档过长及软件工具过载，任务成功率这一指标掩盖了AI智能体造成的严重操作违规。 乌迪塔·帕特尔（Udita Patel）指出，仅依据“任务成功率”来衡量AI智能体的表现是一种片面的指标，它掩盖了在亚马逊等业务环境中对既定操作规程的关键违背。本次演讲阐释了智能体的六种主要失败模式，包括状态丢失、分支崩溃、静默处置以及工具过载，并公布了亚马逊开源数据集的实证结果，证明上下文长度和规程复杂性是模型面临的核心障碍。最后，演讲为开发者提出了切实可行的建议，重点强调程序化流程工程设计、提供明确的人工升级介入与回滚途径，以及开展多维度、细粒度的反复评估。 亚马逊的大规模日常运营受到严格标准作业程序（SOP）的约束，以确保可审计性、合规性与决策追溯能力。 (0:03) 标准作业指南最初是面向具备常识直觉和背景知识的人类编写的，其本质并不适配软件模型或AI智能体。 (0:03) 仅依据“任务成功率”来评估智能体具有误导性且缺乏诊断价值；得出正确决策的过程可能掩盖了对工作流的严重违规行为。 (3:48) 能力不等于可靠性；智能体可能会通过绕过强制检查或验证流程，得出表面上正确的结果。 (3:48) 受上下文长度限制和注意力机制影响，状态丢失（State Loss）和分支崩溃（Branch Collapse）等关键失败模式会导致智能体准确率下滑。 (11:13)

توضح أوديتا باتيل، عالمة أبحاث تطبيقية أولى في أمازون، أن تقييم وكلاء الذكاء الاصطناعي في بيئات العمل الحساسة لا يمكن اختزاله في معدل نجاح القرار النهائي، محذرة من أن النماذج قد تخرق إجراءات التشغيل وتتجاوز الفحوصات الإلزامية رغم وصولها إلى نتائج تبدو صحيحة. أهمية إجراءات التشغيل ومبررات أتمتتها (0:03) تعتمد الشركات الكبرى مثل أمازون على إجراءات التشغيل القياسية (SOPs) لإدارة ملايين القرارات اليومية المتكررة، مثل التحقق من الطرود الواردة، ومكافحة احتيال البائعين، وإجراء الفحوصات الأمنية للشحن الجوي. تستهدف هذه الوثائق المفصلة ضمان الامتثال التنظيمي وقابلية التدقيق المستمر، وتحتوي على مسارات متسلسلة وشروط دقيقة وأدوات استرداد كُتبت أساساً لجمهور بشري يمتلك فهماً سياقياً مسبقاً. تدفع مؤسسات العمل نحو أتمتة هذه العمليات بالوكلاء لمواجهة الحجم الضخم، وتخفيض تكاليف التوظيف المستمر، وتجاوز التباين في الأداء البشري بين الورديات والأسواق، بالإضافة إلى تسريع معالجة طوابير الانتظار لتفادي الإضرار بتجربة العملاء. محدودية مقياس النجاح وفخ القدرة مقابل الموثوقية (3:48) تنتقد باتيل الاعتماد الحصري على مقياس «معدل نجاح المهمة»، معتبرة أنه مؤشر ضروري ولكنه غير كافٍ لافتقاره إلى القدرة التشخيصية. فالنماذج قد تتفاوت في إنهاء الخطوات الفرعية، حيث ينجز بعضها 40% والآخر 60%، في حين يخفي تقييم النتيجة النهائية فقط مسار الأداء الداخلي. وتشير المتحدثة إلى أن امتلاك الوكيل للقدرة لا يعني موثوقيته؛ إذ يمكن للوكيل أن يتوصل إلى المخرج المطلوب شكلياً عبر القفز فوق شروط حرجة، مثل تخطي فحص تباين كميات الطرود أو تجاهل عتبات الانحراف، وهو ما يمثل خطراً تشغيلياً جسيماً في البيئات التي تتطلب التزاماً صارماً بتسلسل الخطوات والتدقيق. أنماط فشل النماذج اللغوية في الإجراءات الطويلة (11:13) عند تحويل أدلة التشغيل التي تمتد لعشرات الصفحات (من 15 إلى 20 صفحة أو أكثر) إلى أشجار قرارات تفاعلية، تبرز ستة أنماط رئيسية لإخفاقات النماذج، تشمل أخطاء إجرائية وتنفيذية واستدلالية. يتمثل نمط «فقدان الحالة» في تراجع كفاءة الانتباه في بنية المحولات وضياع المتغيرات المذكورة في بدايات الدليل عند الوصول إلى خطوات متقدمة، بينما يقود تدفق النصوص الضخمة وظاهرة «الضياع في المنتصف» إلى «انهيار الفرع» والانحراف عن مسار الشجرة الشرطية. كما يؤدي الخلل في استيعاب التبعيات إلى «انعكاس الأسبقية» وخلط الترتيب بين المسارات المتوازية والإلزامية. تتفاقم المشكلات عند تعطل الأدوات نتيجة «التعويض المفقود»، حيث تعجز النماذج عن التراجع لغياب الآليات الصريحة التي يعوضها البشر بديهياً. وبدلاً من التوقف أو التصعيد، يقع الوكيل في «الحل الصامت» بتوليد مسارات وهمية وهلوسة، بالإضافة إلى «تعريف الأداة الغامض» الذي يتسبب في استدعاء أدوات وواجهات برمجة خاطئة عندما تتشابه مسميات آلاف الأدوات دون توصيف دقيق وحصري. نتائج تجارب أمازون ومؤشرات الأداء (17:59) أظهرت نتائج اختبارات أمازون، المبنية على مجموعة بيانات مفتوحة تضم نحو 12 إلى 13 دليلاً تشغيلياً في مجالات كدعم العملاء وفحص الطائرات، أن مستوى الصعوبة يرتبط بطبيعة الإجراء نفسه وليس بنوع الوكيل؛ إذ حققت نماذج الطليعة دقة كاملة بلغت 100% في مهام بسيطة، لكنها تراجعت إلى ما بين 40% و57% في مهام أخرى باستخدام النماذج المتقدمة نفسها. وكشفت النتائج أن زيادة عدد الأدوات المتاحة للنظام لا تؤدي فقط إلى بطء الاستجابة، بل تسبب تدهوراً مباشراً في دقة اتخاذ القرار، كما أثبتت التجارب أن الترقية إلى نماذج أحدث لا تحل العوائق التشغيلية تلقائياً. وعلى خلاف التوقعات، أظهرت النماذج قدرة جيدة على معالجة المنطق المعقد، بينما عانت بشكل حاد وفاضح من طول الوثائق واتساع السياق. توصيات هندسة الوكلاء ومعايير التقييم الإنتاجي (20:09) توصي باتيل بإعادة صياغة وهيكلة أدلة التشغيل لتلائم فهم الذكاء الاصطناعي بدلاً من إبقائها بصيغتها الموجهة للبشر، وتقليص حجم الأدوات وتوصيفها بدقة حصرية. ولضمان حماية بيئة الإنتاج، تقترح فصل القواعد الصارمة برمجياً ضمن طبقة تحكم خارجية، وإدراج خيار التصعيد البشري الصريح، وتحديد مسارات التعويض وتفعيل سجلات تتبع التنفيذ. كما تشدد في جانب التقييم على إجراء اختبارات عبر جولات تشغيل متعددة لرصد تذبذب الأداء، واستخدام تقارير تفصيلية مصنفة حسب نوع الخطأ والبُعد، وزيادة وتيرة القياس مع تعقيد النظام، مع اختبار الوكلاء على إجراءات غير مألوفة ورصد الانتهاكات الإجرائية بدقة. تخلص المحاضرة إلى أن التحدي الجوهري في أتمتة الإجراءات لا يكمن في سرعة بناء الوكلاء بل في منهجيات قياس موثوقيتهم؛ حيث تظل النماذج المتقدمة معرضة للانهيار أمام طول السياق وتضخم الأدوات ما لم يُعد تصميم مسارات العمل بنيةً وتقييماً لتلائم خصائص الذكاء الاصطناعي.

亚马逊高级应用研究科学家乌迪塔·帕特尔指出，大语言模型代理在自动化执行企业复杂标准作业程序时表现出高度脆弱性，仅依赖最终任务成功率进行评估会掩盖严重的合规违规与中间流程偏差。 SOP自动化的动因与简单评估指标的陷阱 (3:48) 在亚马逊等大型企业中，仓库入库包裹核对、卖家账户身份与防欺诈筛查、航空货运易燃品安检等业务每天涉及数以百万计的重复决策。为确保可审计性并满足严格的监管合规要求，领域专家将决策标准、条件分支规则（if/else）与故障恢复机制固化为详尽的标准作业程序（SOP）。企业引入AI代理的核心动力在于应对海量业务规模、降低招聘与扩张成本、消除人类员工在不同班次和市场间的表现波动，并缓解排队积压以提升客户体验。 然而，评估代理系统时若仅采用“任务成功率”（即最终决策是否正确）这一单一指标，存在严重的诊断盲区。帕特尔以包裹检查流程为例说明，合规作业要求依次执行条码匹配、缺失数量差异计算、阈值偏离判定及升级分类、最终库位核对等环节。实验发现，代理可能在跳过关键安全核验或违反规定步骤的情况下，偶然得出看似正确的最终结论；此外，不同模型完成子步骤的比例可能存在显著差异（例如40%与60%）。这种“具备能力但不具可靠性”的现象，在对合规与审计要求极高的生产环境中构成了严重隐患。 大模型在长流程执行中的六类失效模式 (11:13) 当业务SOP长达15至20页甚至更长时，若将其抽象为包含API工具调用和文本决策节点的工作流决策树，前沿大模型会表现出六种典型的系统性失败模式，涵盖流程错误、工具执行错误以及推理与事实锚定缺陷： 其一为状态丢失（State Loss），因Transformer注意力机制随上下文增长而衰退，导致在流程早期（如第2步）定义的变量在后续（如第27步）被遗忘；其二为分支崩溃（Branch Collapse），受大模型“迷失在中间”现象影响，代理在面对庞杂条件树时偏离正确分支；其三为优先级倒置（Precedence Inversion），代理混淆了步骤之间的严格因果时序与并行逻辑；其四为补偿机制缺失（Missing Compensation），原SOP预设人类具备常识性的重试或回滚能力，但模型遭遇工具报错时缺乏显式的故障恢复逻辑；其五为静默解决（Silent Resolution），当遇到不确定性或无法识别路径时，代理未能及时报错或升级，而是通过生成虚假步骤或幻觉继续运行；其六为工具定义模糊（Ambiguous Tool Definition），在系统面对数以千计功能或命名相近的API时，不精确的工具描述极易引发误调用。 亚马逊开源基准测试揭示的实证规律 (17:59) 为推动行业评估，亚马逊在GitHub上开源了一套包含12至13个真实业务SOP的数据集，覆盖视频标注、客户支持、电子邮件审核及飞机检查等异质场景，并配套了模拟工具环境与基准真值数据。针对前沿模型在该基准上的测试，帕特尔总结了四项反直觉的实证发现： 首先，任务难度取决于流程本身的复杂度，而非模型内在能力。在结构简单的流程中，模型能够达到100%的准确率，但在高复杂度流程中，即便使用顶级前沿模型，准确率也会断崖式下跌至40%至57%。其次，工具过载会直接损害决策准确性，提供数千个候选API不仅延长响应延迟，还会显著恶化模型的推理与选择精度。再次，直接升级或迁移到更大参数的基座模型并不能自动解决操作失误。最后，前沿模型展现出了较强的复杂逻辑推理能力，但对文档与上下文长度表现出极高敏感性，超长上下文带来的性能衰减远超复杂逻辑本身。 面向生产环境的架构优化与评估原则 (20:09) 针对AI代理落地生产环境的工程挑战，帕特尔强调开发代理相对容易，而建立持续评估与优化体系才是核心。在架构设计上，团队不应直接沿用面向人类员工撰写的旧文档，而须将SOP重构为适合大模型解析的结构化指令；严格精简工具集合，为每个API编写边界清晰、相互排斥的功能定义；将确定性的业务铁律和硬性约束剥离出提示词，硬编码至外部确定性编排控制器中；同时在工作流中显式配置人工介入（Human-in-the-Loop）升级路径与故障回滚补偿机制，并开启全量执行链路追踪。 在评估方法层面，帕特尔建议摒弃单一汇总评分，推行多轮重复运行以捕捉模型输出的方差；按错误类别和维度出具细粒度诊断报告；建立与具体业务领域绑定的专用度量体系，并随着系统复杂度增加提高评测频次；在未见过的全新流程场景下实施泛化压力测试；并重点监控和记录代理对关键合规路径的越权与违规行为。 帕特尔总结指出，自动化复杂企业流程的关键不在于盲目追逐更大参数的模型，而在于弥合人类经验文档与机器执行逻辑之间的鸿沟；通过将外部确定性控制架构与细粒度、多维度的诊断性评估相结合，企业才能真正防范代理在真实生产环境中的隐性违规风险。

## Background 该内容由频道 Ai4 于 2026 年 8 月 20 日发布在 YouTube 平台，主讲人为亚马逊资深应用科学家（Senior Applied Scientist）Udita Patel。视频简介指出，现实中的企业标准作业程序（SOP）逻辑复杂且包含大量分支与回滚路径，现有 AI Agent 执行时长流程脆弱性显著，单纯衡量任务成功率存在巨大生产盲区；演讲系统介绍了 SOP 评测框架、六大错误分类学以及前沿模型在真实业务基准下的实证发现。 ## TL;DR 在亚马逊等大型企业中，海量高频决策高度依赖详尽的 SOP，但将其交给 AI Agent 执行时常因长流程和工具歧义出现脆弱性。演讲指出传统的“端到端任务成功率”极具欺骗性，容易掩盖“步骤错误但巧合得出正确结论”的高危隐患。亚马逊通过归纳流程控制与工具调用维度的六大失效模式，并开源多领域企业基准测试，揭示了 SOP 文本绝对长度对大模型的负面影响远超逻辑嵌套复杂度。针对生产落地，专家提出了 SOP 结构化重构、确定性规则代码外置、显式人工升级机制以及多轮次方差度量等系统性实践指南。 ## Atmosphere & style 演讲整体呈现出严谨扎实、克制务实的工业界工程叙事风格。主讲人 Udita Patel 语气冷静自信、条理清晰，摒弃了对 AI 能力的盲目乐观与概念炒作，以顶级大厂一线生产实践为底色直击 Agent 落地的脆弱性痛点。从真实仓储 SOP 切片展示到实证评测数据的层层拆解，整场分享充满对高危合规场景的敬畏感，为听众带来高度清醒且具实操指导价值的架构与评测洞见。 ## Key takeaways - [00:03](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=3s) 大型企业日常依赖海量且重复的高频业务决策（如仓储入库、欺诈筛查和危险品检查），这些操作被固化为长篇复杂的标准作业程序（SOP）以确保合规性与全链路可审计性。 - [02:57](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=177s) 将 SOP 工作流交由 AI Agent 自动化的核心驱动力在于业务规模扩展、运营成本控制、消除不同人员间的决策偏差以及降低审核响应延迟。 - [05:54](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=354s) 直接将长篇复杂 SOP 作为 Prompt 塞给大语言模型的朴素方法极其脆弱，无法有效应对真实场景中的多系统异构集成与异常回滚需求。 - [08:51](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=531s) 单纯依赖端到端“任务成功率”评估 Agent 具有极大危险性，它不仅缺乏工程诊断能力，还会掩盖“过程完全错误但巧合蒙对结果”的致命生产合规隐患。 - [11:13](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=673s) 长上下文注意力衰减会导致 Agent 在长流程中遗忘早期参数并捏造假设，产生“状态丢失”；同时在多重嵌套条件中易发生“分支坍塌”走入错误路由。 - [11:13](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=673s) Agent 在复杂工作流中容易颠倒串并行时序依赖（前序倒置），遇到执行阻碍时缺乏逆向补偿机制，甚至会隐蔽地产生幻觉强行推进（静默解决）。 - [11:13](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=673s) 当面对数千个相似 API 的庞大工具库时，工具 Schema 描述模糊会导致 Agent 发生误调用，工具膨胀会直接导致推理准确率断崖式下跌而不仅是增加延迟。 - [17:22](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1042s) 实证研究表明任务难度是 SOP 本身的固有属性，且 SOP 文档的“绝对长度”对大模型造成的负面影响远大于“逻辑嵌套复杂度”，直接迁移到更大模型并不能自动解决问题。 - [20:09](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1209s) 构建高可靠企业级 SOP Agent 需要将面向人类编写的 SOP 重构为结构化文本，大幅精简并明确工具描述，同时将确定性计算与业务规则剥离到大模型外部用代码硬约束。 - [20:09](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1209s) 生产级评测必须摒弃单次运行与单一得分，需通过多轮独立测试捕获决策方差，分阶段度量各生命周期指标，并设置灾难性合规红线硬拦截。 ## Detailed walkthrough ### [00:03](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=3s) 企业复杂业务与标准作业程序（SOP）的现实背景 在大型企业中，日常运营高度依赖海量且重复的高频业务决策。亚马逊资深应用科学家（Senior Applied Scientist）Udita Patel 指出，以亚马逊的全球运营体系为例，这类业务决策每天要发生数百万次。例如在仓储物流环节，当入库包裹送达仓库时，系统和操作人员必须核验实物条形码与采购订单（Purchase Order）是否一致；在卖家管理中，需要对卖家账户进行反垃圾欺诈检查，并严格核验其实际身份与声明信息是否吻合；在航空货运交付场景下，操作员必须严格检查包裹中是否夹带易燃液体等危险品，以决定该包裹能否合规装机起运。 ```mermaid flowchart TD accTitle: 亚马逊典型业务决策工作流与SOP合规体系 subgraph Operations["高频业务场景 (日均数百万次决策)"] A["仓储包裹入库核验"] B["卖家账户与身份认证"] C["航空危险品合规筛查"] end subgraph SOP["标准作业程序 (SOP) 核心要求"] D["领域专家编写详细规程"] E["分支逻辑与阈值判定"] F["审计追踪与监管合规"] end Operations --> SOP ``` 这些错综复杂的业务并非随意执行，而是被沉淀为极其详尽的文档化流程，即标准作业程序（SOP, Standard Operating Procedures）。SOP 明确规定了在各个业务节点应做出的具体决策与操作标准，通常由具备深厚业务经验的领域专家（Domain Experts）和决策制定者编写，并由专门的流程负责人或一线员工严格执行。企业之所以不惜成本维护这些长达数页甚至数十页的繁琐文档，核心目的在于满足**监管合规要求**与**全链路可审计性（Auditability）**，确保每一笔决策的来龙去脉均有据可查、责任可溯。 - **日均决策规模**：在亚马逊等大型业务体系中，各类 SOP 决策每天的触发量达到数百万次级别。 - **SOP 核心特征**：包含清晰的条件分支（If-Else）、数值判定标准（Criteria/Thresholds）、系统工具集（CMS、复杂软件、检索工具）以及异常状态下的恢复与回滚路径（Rollback Paths）。 - **受众假设**：传统 SOP 预设阅读者为已具备领域常识的人类员工，许多隐含假设未在字面中完整展开。 --- ### [02:57](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=177s) 为什么需要用 AI Agent 自动化 SOP 工作流 将企业 SOP 工作流交给 AI Agent（智能体）执行正成为自动化演进的必然趋势。Patel 解释道，这类工作本质上就是“阅读文档、拆解多阶段子任务、调用外部工具做出裁决，并持久化存储执行痕迹”，这一逻辑与 AI Agent 的工作范式天然契合。在本次演讲中，“自动化智能体系统”被明确定义为：**能够解析输入数据、做出逻辑决策、调用工具执行动作并完整记录状态的闭环系统**。 企业推动 SOP 智能体化的核心驱动力包含四个维度： 1. **规模扩展（Scale）**：面对每日数百万甚至千万级的决策吞吐量，传统人工流程难以线性承载。 2. **成本控制（Cost）**：随着业务扩张，单纯增加人力编制会导致运营成本急剧攀升。 3. **决策一致性（Consistency）**：人类操作员在不同班次、不同员工个体以及不同国家市场之间容易出现执行偏差，自动化系统有望建立统一基线。 4. **响应延迟（Latency）**：人工审核容易产生队列积压，一旦决策滞后，将直接传导至物流和履约环节，损害终端客户体验。 --- ### [05:54](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=354s) 亚马逊仓储 SOP 实例与 Agent 架构挑战 为了让听众切身体会真实 SOP 的复杂程度，Patel 展示了亚马逊实际使用的“仓储入库包裹异常检查”SOP 文本切片。这一真实流程包含 8 个关键连续步骤及众多子步骤。 ```mermaid flowchart LR accTitle: 仓储入库SOP检查流程图 Step1["步骤 1: 条码比对<br>(实物 vs 订单)"] --> Step2["步骤 2: 数量差异核对<br>(少件 / 多件 / 一致)"] Step2 --> Step3["步骤 3: 缺陷分级规程<br>(计算差异比例是否 > 偏差阈值)"] Step3 --> Step4["步骤 4+: 仓位验证与工具上报<br>(触发回滚或入库)"] ``` 在入库核验中，首先必须确认卖家交付商品的条形码与系统采购单完全一致；随后进入数量差异核对环节，计算实收数量与预期数量的偏差；紧接着执行问题分流协议（Problem Triage Protocol），在此步骤中需要计算缺件或多件的比例是否跨过了预设的“缺陷偏差阈值”（Defect Deviation Threshold，例如 5% 容忍度）。后续还会涉及库存库位检查、调用特定内部软件更新状态等。 构建此类 Agent 的朴素方法通常是将 SOP 文本直接作为系统 Prompt，加入输入格式约束和基础 Guardrails。然而，真实 SOP 往往深度整合了多个异构系统与 API，且必须设计清晰的失败恢复路径（当某一步系统无响应或数据缺失时应如何处理）。如果仅仅把复杂文本塞给大语言模型（LLM），系统的执行表现将极其脆弱。 --- ### [08:51](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=531s) 评测盲区：为什么“任务成功率”不足以衡量 Agent 评估执行 SOP 的 AI Agent 时，业内通常依赖端到端的“任务成功率（Task Success Rate）”——即统计在所有测试样本中，Agent 最终给出的结论有多少是正确的。Patel 强调，这一指标在生产环境中**不仅是不充分的，更是极其危险的**： - **缺乏诊断能力（Lack of Diagnostics）**：当对比两个候选模型或架构时，一个可能在 40% 的子步骤上执行合规，另一个达到了 60%。但如果两者最终输出的正确率类似，单一指标根本无法指导工程团队该选用哪一个模型上线。 - **“过程错误但巧合得出正确结果”（Right Output for Wrong Reasons）**：这是生产中最致命的隐患。在实际测试中发现，当包裹缺失率为 6% 时（已超过 5% 的报警阈值），Agent 漏掉了阈值比对子步骤，直接跳步执行后续动作，最后给出的结论恰好与标准答案重合。这种因逻辑跳步或巧合蒙对的结果，会在生产高危场景中埋下巨大合规隐患。 - **能力不等于可靠性（Capability ≠ Reliability）**：大模型具备理解复杂指令的“能力”，但在长流程中展现出严重的“脆弱性（Brittleness）”，即在决策路径上存在不可控的随机抖动与不一致性。 --- ### [11:13](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=673s) 真实场景下 Agent 的六大失效模式分类学 结合亚马逊的落地经验，Patel 将 Agent 在长流程 SOP 自动化中的典型错误归纳为六大失效模式（Failure Modes），涵盖流程逻辑、工具调用与认知推理三大维度： ```mermaid flowchart TD accTitle: SOP Agent 六大失效模式分类 subgraph Procedural["流程控制类失效 (Procedural Errors)"] F1["1. 状态丢失 (State Loss)<br>长上下文注意力衰减，丢失早期参数"] F2["2. 分支坍塌 (Branch Collapse)<br>复杂决策树迷航，错入错误逻辑分支"] F3["3. 前序倒置 (Precedence Inversion)<br>依赖混淆，串行/并行执行顺序错乱"] end subgraph Execution["工具与恢复类失效 (Tool & Execution Errors)"] F4["4. 补偿缺失 (Missing Compensation)<br>单步失败后缺乏回滚机制，流程卡死"] F5["5. 静态静默推进 (Silent Resolution)<br>遇阻时不求助/不上报，臆造结果硬推"] F6["6. 模糊工具定义 (Ambiguous Tool Definition)<br>海量相似 API 描述不清导致误调用"] end ``` | 错误分类 | 失效模式 | 具体表现与产生机理 | |:--- |:--- |:--- | | **流程类** | **状态丢失**<br>*(State Loss)* | SOP 文档通常长达 15–20 页。文档第 2 步定义的某个关键变量，直到第 27 步才被使用。由于 Transformer 模型的注意力机制随上下文拉长而衰减，Agent 在执行后期遗忘了早期状态，转而依赖虚构假设。 | | **流程类** | **分支坍塌**<br>*(Branch Collapse)* | 真实业务 SOP 是复杂的决策树结构。在面临多重嵌套的 If-Else 条件时，受“迷失在中间（Lost in the Middle）”现象影响，Agent 无法在长文本中检索出细微的条件限制，导致决策路由走入错误分支。 | | **流程类** | **前序倒置**<br>*(Precedence Inversion)* | 复杂工作流混合了严格依赖的串行任务与可同时触发的并行任务。Agent 混淆了数据依赖关系，在必要前置步骤未完成前就抢先触发了后续动作，导致执行时序颠倒。 | | **工具类** | **补偿缺失**<br>*(Missing Compensation)* | 传统 SOP 编写时默认人类具有常识应变能力，往往不会显式写出“步骤 5 失败时如何回滚”。Agent 一旦在某一步遇阻，既不知道如何重试，也不知道如何执行逆向补偿，直接导致流程中断。 | | **工具类** | **静默解决/硬推**<br>*(Silent Resolution)* | 当遇到未知信息或无法判定的边界时，Agent 未能像人类员工那样“暂停、报错或向上级人工升级（Escalate）”，而是选择静默猜想、产生幻觉并强行向前推进，造成隐蔽的严重破坏。 | | **工具类** | **工具定义模糊**<br>*(Ambiguous Tool Definition)* | 当系统只有 4 个工具时 Agent 表现良好；但当扩展至包含数千个相似 API（命名相近、版本各异、参数重叠）的庞大工具库时，因 Tool Schema 描述不够互斥精确，模型极易调用错误工具。 | --- ### [17:22](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1042s) 亚马逊开源基准与前沿模型的实证发现 为了推动学术界与工业界对复杂 SOP Agent 的深入研究，亚马逊开源了包含 12 至 13 个真实企业级 SOP 的基准测试集（包含完整流程文本、模拟工具环境与评测基准数据），涵盖视频内容标注、客户服务、邮件分类以及飞机合规检查等跨领域业务。 在前沿大模型（Frontier Models）上的评测揭示了三项反直觉的关键实证结论： 1. **任务难度是 SOP 自身的固有属性，而非取决于 Agent**：不同业务 SOP 之间的表现差异极大。在某些简单 SOP 上，前沿模型能达到 100% 的准确率；但在高难度 SOP 上，即便是最强的旗舰模型，任务完成率也仅有 40% 到 57%。 2. **工具膨胀会直接导致决策精度断崖式下跌**：通常人们认为向 Agent 提供数千个工具主要会带来延迟（Latency）增加，但实验证明更严重的后果是**推理准确率显著下降**，模型在海量选项中极易发生误判。 3. **模型升级并非灵丹妙药（Model Migration is not trivial）**：直接无缝迁移到参数量更大或更新的模型，并不能自动解决长流程执行问题。深入分析发现：**SOP 文本的“绝对长度”对 LLM 造成的负面影响，远大于逻辑结构的“嵌套复杂度”**。模型能够较好地处理复杂的逻辑判断，但在超长上下文面前却表现脆弱。 --- ### [20:09](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1209s) 生产级 SOP Agent 的构建与评测最佳实践 针对上述挑战，Patel 为构建高可靠企业级 SOP Agent 提供了系统性的落地指导方案： ```mermaid flowchart TD accTitle: 生产级 SOP Agent 构建与评测方法论 subgraph BuildPhase["构建阶段 (Architecture & Engineering)"] B1["SOP 结构化重构<br>(面向 AI 重新组织清晰文档)"] B2["工具集精简与精准描述<br>(严格保持 Tool Schema 互斥)"] B3["确定性规则外置化<br>(脱离 LLM，用确定性代码硬约束)"] B4["显式升级与回滚设计<br>(注入 Escalate 机制与补偿路径)"] end subgraph EvalPhase["评测阶段 (Evaluation & Guardrails)"] E1["多轮次重复测试<br>(捕获 Agent 方差与输出抖动)"] E2["细分维度与阶段评测<br>(摒弃单一得分，按生命周期度量)"] E3["未见 SOP 泛化测试<br>(保留独立盲测集，防过拟合)"] E4["灾难性违规硬拦截<br>(监控不可接受的底线合规红线)"] end BuildPhase --> EvalPhase ``` - **SOP 结构化改写**：将原本写给人类看的高隐式文本，重写为模块化、结构清晰、面向机器阅读的 SOP 格式。 - **工具治理**：大幅精简 Agent 单次可见的工具数量，彻底重写 API 描述以确保语义互斥，防止工具调用歧义。 - **规则硬编码（Code Outside the Model）**：将严格的业务规则、计算公式和状态转移约束置于模型外部，用确定性代码控制，避免交由 LLM 自由发挥。 - **显式升级与补偿机制**：在 Agent 架构中将“转人工/向上升级（Escalation）”作为一等公民工具显式暴露，并严格定义每一步的失败恢复路径与执行追踪日志（Execution Traces）。 - **多轮次方差评测**：拒绝单次运行跑分，必须通过多轮独立重复运行度量 Agent 的决策抖动（Jitter）。 - **多维度度量体系**：严禁使用单一指标概括 Agent 表现，必须根据业务领域划分步骤正确率、工具匹配度、逻辑合规性等细分维度，并重点防范合规红线与“灾难性违规（Catastrophic Violations）”。 ## Notable quotes > [00:03](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=3s) 这类业务决策每天要发生数百万次。例如在仓储物流环节，当入库包裹送达仓库时，系统和操作人员必须核验实物条形码与采购订单是否一致 — Udita Patel > [00:03](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=3s) 企业之所以不惜成本维护这些长达数页甚至数十页的繁琐文档，核心目的在于满足监管合规要求与全链路可审计性，确保每一笔决策的来龙去脉均有据可查、责任可溯 — Udita Patel > [02:57](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=177s) 自动化智能体系统被明确定义为：能够解析输入数据、做出逻辑决策、调用工具执行动作并完整记录状态的闭环系统 — Udita Patel > [05:54](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=354s) 如果仅仅把复杂文本塞给大语言模型，系统的执行表现将极其脆弱 — Udita Patel > [08:51](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=531s) 这一指标在生产环境中不仅是不充分的，更是极其危险的 — Udita Patel > [08:51](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=531s) 大模型具备理解复杂指令的能力，但在长流程中展现出严重的脆弱性，即在决策路径上存在不可控的随机抖动与不一致性 — Udita Patel > [11:13](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=673s) 当遇到未知信息或无法判定的边界时，Agent 未能像人类员工那样暂停、报错或向上级人工升级，而是选择静默猜想、产生幻觉并强行向前推进，造成隐蔽的严重破坏 — Udita Patel > [17:22](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1042s) 任务难度是 SOP 自身的固有属性，而非取决于 Agent — Udita Patel > [17:22](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1042s) 通常人们认为向 Agent 提供数千个工具主要会带来延迟增加，但实验证明更严重的后果是推理准确率显著下降，模型在海量选项中极易发生误判 — Udita Patel > [17:22](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1042s) SOP 文本的‘绝对长度’对 LLM 造成的负面影响，远大于逻辑结构的‘嵌套复杂度’。模型能够较好地处理复杂的逻辑判断，但在超长上下文面前却表现脆弱 — Udita Patel > [20:09](https://www.youtube.com/watch?v=5uO3r0Z76Ew&t=1209s) 严禁使用单一指标概括 Agent 表现，必须根据业务领域划分步骤正确率、工具匹配度、逻辑合规性等细分维度，并重点防范合规红线与灾难性违规 — Udita Patel ## Mentioned Udita Patel, Amazon, Ai4, SOP, AI Agent, LLM, Transformer, Purchase Order, Problem Triage Protocol, Defect Deviation Threshold ## Video description Udita Patel - Senior Applied Scientist, Amazon Real world standard operating procedures are complex, involving branching logic, long sequential steps, ordering constraints, rollback paths and ambiguous tool definitions. Current AI agents are surprisingly brittle when executing them and measuring them with task success rate is insufficient. As agents move from copilots to autonomous operators, this is a blind spot with real production consequences. This talk introduces an evaluation framework with comprehensive error taxonomy followed by empirical findings from evaluating frontier models across multiple domains. Attendees will leave with understanding of what makes real world AI agents challenging and practical approaches for building and evaluating these AI agents in real world. [Source](https://www.youtube.com/watch?v=5uO3r0Z76Ew)

[0:03] Udita Patel: 这类业务决策每天要发生数百万次。例如在仓储物流环节，当入库包裹送达仓库时，系统和操作人员必须核验实物条形码与采购订单是否一致 [0:03] Udita Patel: 企业之所以不惜成本维护这些长达数页甚至数十页的繁琐文档，核心目的在于满足监管合规要求与全链路可审计性，确保每一笔决策的来龙去脉均有据可查、责任可溯 [2:57] Udita Patel: 自动化智能体系统被明确定义为：能够解析输入数据、做出逻辑决策、调用工具执行动作并完整记录状态的闭环系统 [5:54] Udita Patel: 如果仅仅把复杂文本塞给大语言模型，系统的执行表现将极其脆弱 [8:51] Udita Patel: 这一指标在生产环境中不仅是不充分的，更是极其危险的 [8:51] Udita Patel: 大模型具备理解复杂指令的能力，但在长流程中展现出严重的脆弱性，即在决策路径上存在不可控的随机抖动与不一致性 [11:13] Udita Patel: 当遇到未知信息或无法判定的边界时，Agent 未能像人类员工那样暂停、报错或向上级人工升级，而是选择静默猜想、产生幻觉并强行向前推进，造成隐蔽的严重破坏 [17:22] Udita Patel: 任务难度是 SOP 自身的固有属性，而非取决于 Agent [17:22] Udita Patel: 通常人们认为向 Agent 提供数千个工具主要会带来延迟增加，但实验证明更严重的后果是推理准确率显著下降，模型在海量选项中极易发生误判 [17:22] Udita Patel: SOP 文本的‘绝对长度’对 LLM 造成的负面影响，远大于逻辑结构的‘嵌套复杂度’。模型能够较好地处理复杂的逻辑判断，但在超长上下文面前却表现脆弱 [20:09] Udita Patel: 严禁使用单一指标概括 Agent 表现，必须根据业务领域划分步骤正确率、工具匹配度、逻辑合规性等细分维度，并重点防范合规红线与灾难性违规

[0:03] أوديتا باتيل: تتضمن وثائق التشغيل القياسية خطوات متسلسلة، وقواعد شرطية دقيقة ("إذا / وإلا")، ومعايير اتخاذ القرار، وأدوات برمجية، ومسارات استعادة وتعويض عند حدوث أخطاء. [0:03] أوديتا باتيل: كُتبت هذه الوثائق في الأصل لجمهور بشري يمتلك بالفعل فهماً عميقاً وخلفية مسبقة عن سياق العمل. [3:48] أوديتا باتيل: ضروري ولكنه غير كافٍ إطلاقاً [3:48] أوديتا باتيل: القدرة لا تعني الموثوقية [11:13] أوديتا باتيل: فقدان الحالة (State Loss): يحدث عندما تُذكر قيمة أو معلومة في مستهل الدليل (كالخطوة الثانية) ويُطلب استخدامها لاحقاً في الخطوة السابعة والعشرين [11:13] أوديتا باتيل: انهيار الفرع (Branch Collapse): فشل الوكيل في تتبع الشجرة المتشعبة للقرارات والشرطيات، والانحراف نحو مسار غير مناسب [17:59] أوديتا باتيل: الصعوبة خاصية للإجراء وليست للوكيل [17:59] أوديتا باتيل: تزويد الوكيل بعدد هائل من الأدوات (مثل الاختيار من بين آلاف الأدوات) لا يزيد زمن الاستجابة فقط كما يُعتقد، بل يدهور دقة الأداء واتخاذ القرار بشكل مباشر. [17:59] أوديتا باتيل: الترقية إلى نموذج أحدث وأكبر لا تضمن حل المشكلات التشغيلية تلقائياً. [17:59] أوديتا باتيل: أظهرت النماذج قدرة جيدة وغير متوقعة على معالجة المنطق المعقد، بينما عانت بشكل حاد وفاضح من "طول الوثيقة والسياق".

[0:03] مرحباً بالجميع. أنا [0:05] عالم أول في أمازون. [0:07] سأتحدث اليوم عن تقييم [0:09] وكلاء الذكاء [0:10] الاصطناعي في عمليات [0:11] الأتمتة الواقعية. [0:14] >> تحياتي. [0:17] >> قبل أن نبدأ، دعوني [0:19] أتحدث عن سير العمليات [0:22] التشغيلية في أي شركة. [0:23] عادةً ما تكون هذه [0:25] قرارات تُتخذ بكميات [0:27] كبيرة لأي عملية [0:29] تجارية. في أمازون، [0:33] على سبيل المثال، قد [0:34] يكون هذا فحص الطرود [0:36] في المستودع. عند وصول [0:39] طرد وارد، نتحقق مما [0:40] إذا كان مطابقاً لطلب [0:42] الشراء أم لا. مثال آخر [0:48] هو التحقق من حساب [0:50] البائع، حيث نتحقق مما [0:52] إذا كان البائع ليس [0:54] مُرسلاً للرسائل [0:55] المزعجة، ثم نتحقق من [0:57] تطابق هويته مع ما [0:59] يدّعيه. مثال آخر هو [1:06] فحص الطرود عند [1:07] تسليمها جواً، [1:08] والتحقق مما إذا كانت [1:10] تحتوي على أي سوائل [1:12] قابلة للاشتعال. لنقرر [1:14] ما إذا كان يجب شحنها [1:15] أم لا، وما إلى ذلك من [1:17] القرارات. هذه كلها [1:19] أمثلة على عمليات [1:21] تجارية معقدة في [1:22] أمازون، حيث نتخذ [1:24] قرارات بشأنها يومياً [1:26] ، وأحياناً ملايين [1:28] المرات في اليوم. إذن، [1:34] الجزء المهم في كل هذه [1:36] الأمثلة هو أنها [1:38] إجراءات موثقة، أي [1:40] أنها تُنفذ باستمرار [1:42] ولها وثيقة مكتوبة [1:43] تُعرف بإجراءات [1:52] التشغيل القياسية، [1:54] والتي تحدد القرارات [1:58] التجارية الواجب [1:59] اتخاذها. ويتم تنفيذها [2:02] من قبل متخصصين مؤهلين [2:04] ، يُعرفون بخبراء [2:06] المجال. وكما ترون، [2:11] فإن من يكتبون هذه [2:17] الوثائق المعقدة [2:19] والطويلة والمفصلة هم [2:20] أصحاب القرار، [2:22] وبالتالي يتحملون [2:23] مسؤولية نتائجها. أما [2:27] من يتبعون هذه الوثائق [2:29] ، فقد يكونون أصحاب [2:30] العمليات أو موظفين [2:32] مُعينين خصيصًا لهذا [2:34] الغرض. فلماذا توجد [2:38] هذه الوثائق أصلاً؟ [2:40] ولماذا لا تُنفذ بشكل [2:42] روتيني؟ لأننا نريد [2:44] ضمان إمكانية التدقيق [2:45] ، ونريد الامتثال [2:47] للوائح التنظيمية. [2:48] نحتاج إلى تتبع ما تم [2:50] تنفيذه من خلال اتباع [2:52] هذه الإجراءات وكيفية [2:53] اتخاذ القرارات. فكيف [2:57] تبدو هذه الوثائق؟ [3:01] تتضمن خطوات وقواعد [3:03] شرطية، مثل "إذا" و " [3:05] وإلا"، وخيارات [3:07] للاختيار من بينها. [3:09] سيكون لديهم بعض [3:10] المعايير التي يجب [3:11] تطبيقها عند اتخاذ هذه [3:13] القرارات. سيكون لديهم [3:15] أدوات وأنظمة. نحن [3:17] جميعًا ندرك ذلك جيدًا [3:19] في عالم الوكلاء، حيث [3:20] يمكن أن تكون هذه [3:21] الأدوات عبارة عن [3:22] منصات إدارة مركزية، [3:24] أو برامج معقدة، أو [3:25] مجرد أدوات استرجاع [3:27] بسيطة. ثم سيكون لدينا [3:28] مسارات استعادة، وهي [3:30] ما يجب تجنبه، أو ما [3:31] يجب فعله في حالة فشل [3:33] شيء ما. لذا، فإن [3:35] الخاصية المميزة هنا [3:37] هي أن إجراءات التشغيل [3:39] القياسية مكتوبة [3:40] لقارئ لديه بالفعل [3:42] معرفة بالمجال الذي [3:43] يعمل عليه. فلماذا تتم [3:48] أتمتة سير العمل هذه [3:49] باستخدام الوكلاء، أو [3:51] بالأحرى، لماذا هي [3:53] مرشحة للأتمتة من خلال [3:55] الوكلاء؟ يتعلق الأمر [3:58] بعدة أمور، أولها هو [4:00] الحجم، فمن الواضح [4:02] أننا نتخذ هذه [4:03] القرارات لملايين [4:04] الأشياء في اليوم [4:06] أحيانًا. ثانيًا، [4:09] التكلفة، لأنه مع [4:10] توسعنا، قد نحتاج إلى [4:12] توظيف المزيد من [4:14] الأشخاص أو القيام [4:15] بمزيد من العمل على [4:19] نفس الشيء. ثالثًا، [4:24] الاتساق، والذي يمكن [4:26] أن يختلف بين الورديات [4:28] ، وبين الأشخاص، وبين [4:30] الأسواق. لذا، نسعى [4:31] على الأقل إلى تحقيق [4:33] الاتساق مع هذه [4:34] الأنظمة الآلية. أما [4:36] السبب الرابع فهو زمن [4:38] الاستجابة، والذي [4:39] يتعلق بالسرعة. فإذا [4:41] لم تُتخذ جميع هذه [4:42] القرارات في الوقت [4:43] المناسب، فإنها [4:45] تتراكم في قائمة [4:46] الانتظار، وفي [4:47] النهاية ستؤثر على [4:49] تجربة العملاء، [4:51] وسيواجهون نوعًا من [4:52] التأخير. لذلك، وبسبب [4:54] كل هذه الأسباب، تُعد [4:56] هذه الأنظمة مرشحة [4:57] جيدة لبناء أنظمة آلية [4:59] لها. وبطبيعة الحال، [5:03] تتطور هذه الإجراءات [5:08] لتصبح أنظمة آلية بشكل [5:10] طبيعي، لأنها تتعلق [5:13] بقراءة مستند، [5:14] وتقسيمه إلى مهام [5:16] متعددة، ثم اتخاذ قرار [5:18] محدد، ثم حفظ كل ما حدث [5:22] أثناء اتخاذ تلك [5:24] القرارات. وهذا يشبه [5:26] إلى حد كبير طريقة عمل [5:27] النظام الآلي، أليس [5:29] كذلك؟ ولهذا السبب [5:30] تُعد هذه الأنظمة [5:32] مرشحة جيدة. في حديثي [5:34] هنا، عندما أستخدم [5:36] كلمة "نظام آلي"، فإنني [5:38] أعني نظامًا يُحلل [5:40] البيانات، ويتخذ [5:42] القرارات، وينفذ [5:44] الإجراءات، ثم يخزن كل [5:46] ذلك. إنه تعريف بسيط [5:48] لما يجب أن يكون عليه [5:50] النظام الآلي. بينما [5:54] أتحدث عن هذه [5:55] الإجراءات، دعونا [5:57] نلقي نظرة على [5:59] الإجراءات المتبعة في [6:01] أمازون. هذا الإجراء [6:03] التشغيلي القياسي (SOP) [6:05] خاص بفحص الطرود في [6:09] المستودع. وللأشخاص في [6:12] الخلف، إذا لم تتمكنوا [6:14] من قراءته، فسأقرأه [6:16] لكم. الخطوة الأولى هي [6:18] التحقق مما إذا كان [6:19] الرمز الشريطي [6:20] للمنتجات المستلمة [6:21] مطابقًا للرمز [6:22] الشريطي للمنتجات [6:23] المطلوبة. هذا يعني أن [6:26] البائع يرسل منتجاته [6:28] إلى مستودع أمازون. [6:32] بعد التحقق من الرمز [6:33] الشريطي، نتحقق من [6:35] تباين الكمية. هل هي [6:37] نفس عدد الوحدات [6:38] المطلوبة؟ هل هي أقل؟ [6:40] هل هي أكثر؟ وهكذا. [6:43] الخطوة التالية هي [6:45] بروتوكول تصنيف [6:46] المشكلة. نتحقق مما [6:48] إذا كانت الكمية أقل [6:50] أم أكثر. في هذه الخطوة [6:56] ، هناك أمر محدد يجب [6:58] التحقق منه، وهو ما [7:00] إذا كان التباين أقل [7:02] أو أكثر من عتبة معينة [7:04] تُسمى الانحراف. هذه [7:07] كلها مصطلحات خاصة [7:09] بأمازون، لكن تابع معي [7:11] . حسنًا، نتحقق من ذلك، [7:13] ثم ننتقل إلى خطوات [7:15] أخرى مثل التحقق من [7:17] الموقع وغيره. هذا [7:19] مجرد مقتطف من إجراءات [7:21] تشغيل قياسية (SOP) [7:22] طويلة جدًا تُتبع في [7:24] أمازون. كما رأينا، [7:31] هذه نسخة نصية معقدة [7:32] من إجراءات التشغيل [7:34] القياسية. يحتاج أي [7:38] وكيل يُبنى لهذه [7:39] الإجراءات إلى [7:40] استخلاص بعض [7:41] المعلومات منها. على [7:44] سبيل المثال، هناك [7:46] ثماني خطوات متسلسلة [7:48] في هذه الإجراءات، [7:50] رأينا بعضها أو خطوات [7:52] فرعية، ثم هناك فروع [7:54] شرطية لاتخاذ قرارات [7:56] مثل "إذا حدث كذا، [7:57] فافعل كذا". بعد ذلك، [8:00] يُحدد حد أدنى، وهو [8:02] بمثابة شريط يجب [8:04] تجاوزه لتنفيذ [8:05] إجراءات معينة. بالطبع [8:08] ، ستكون هناك أدوات [8:10] متاحة، لأنه عند إتمام [8:12] هذه العملية، يتم دمج [8:14] العديد من أنظمة [8:15] البرمجيات خلالها، [8:17] سواء كان ذلك يدويًا [8:19] أو تلقائيًا. حسنًا، [8:22] ثم يجب أن يكون هناك [8:24] مسار استعادة، أي ماذا [8:26] نفعل إذا فشلت خطوة ما [8:28] وتوقفنا مؤقتًا؟ [8:32] لنفترض أننا أنشأنا [8:33] وكيلًا، ولن أتحدث عن [8:35] كيفية إنشائه؛ عادةً [8:37] ما يتطلب الإصدار [8:38] البسيط وضع هذا النص [8:40] كموجه، وهيكلته [8:41] بطريقة ما، ووضع بعض [8:43] الضوابط، ثم إنشاء [8:45] الوكيل. وبالطبع، هناك [8:47] العديد من بنى الوكلاء [8:48] لإنشاء هذا. ولكن بعد [8:51] إنشائه، سترغب على [8:52] الأرجح في تقييمه [8:54] باستخدام نوع من [8:55] المقاييس. وأبسط هذه [8:57] المقاييس هو: من بين [8:59] جميع القرارات التي [9:01] اتخذها، لنقل لجميع [9:02] الحزم، كم منها كان [9:04] صحيحًا؟ إنه مقياس [9:06] ضروري، ولكنه غير كافٍ [9:08] . لذا ننتقل إلى السبب [9:11] الأول، وهو عدم وجود [9:12] تشخيص لهذا. لذا، [9:14] عندما نبني مشروعًا [9:16] علميًا متكاملًا، [9:18] يكون العديد من [9:20] العملاء مرشحين له، ثم [9:22] يُكمل أحدهم الإجراء [9:24] بنسبة 40%من خطواته [9:26] الفرعية، بينما يُكمل [9:28] آخر 60%. ولكن إذا [9:31] اقتصرنا على حساب عدد [9:33] القرارات الصحيحة، [9:34] فلن نتمكن من تحديد [9:36] العملاء الأنسب [9:40] للإنتاج النهائي. لهذا [9:42] السبب، لا تكفي هذه [9:44] المقاييس، ومن المثير [9:46] للدهشة أن بعض العملاء [9:48] قد يُحققون نتائج [9:50] صحيحة، لكنهم يتبعون [9:51] العملية بشكل خاطئ، [9:53] وهو أخطر وضع في مثل [9:55] هذه العمليات ذات [9:57] النتائج الحاسمة. [10:01] ثالثًا، القدرة لا [10:03] تعني الموثوقية، [10:04] ولهذا استخدمتُ كلمة " [10:06] هش" في عنواني، أي أن [10:08] العملاء لا يُخطئون، [10:10] بل يُظهرون عدم اتساق [10:12] في اتخاذ القرارات، [10:14] وهذا ما يجب تقييمه. [10:20] هذا مثال سريع على [10:21] كيفية فشل العملاء. [10:23] ففي مثال حزمة [10:24] المستودع نفسه، نرى [10:26] أنه نفّذ الخطوتين [10:28] الأوليين بشكل صحيح. [10:29] يُحدد النظام أن 6%من [10:32] العناصر مفقودة. لكنه [10:35] لم يُكمل المرحلة [10:37] اللاحقة، وهي التحقق [10:39] مما إذا كانت العتبة [10:41] المحددة بين 5%و 6%أكبر [10:44] من 5%. كان من المفترض [10:46] أن يحدث شيء آخر، لكنه [10:48] تخطّى تلك الخطوة [10:49] الصغيرة، ثم تابع [10:50] العملية، وتوصل إلى [10:52] إجابة، والمثير [10:53] للدهشة أنها كانت [10:55] الإجابة الصحيحة، لكن [10:57] العملية لم تُتبع بشكل [10:58] صحيح. هذه هي أنواع [11:00] المشاكل التي لا نرغب [11:02] بحدوثها. الآن، سأعرض [11:05] لكم مخططًا توضيحيًا [11:07] بسيطًا لتتمكنوا من [11:09] تخيل الإجراءات التي [11:10] ترغبون في أتمتتها [11:12] باستخدام وكلائكم. [11:13] لنلقِ نظرة على هذا [11:15] المخطط. النقاط [11:18] السوداء الممتلئة [11:19] تمثل وكيلًا يقوم [11:21] باستدعاء أداة أو [11:22] إجراء كجزء من تلك [11:24] العملية. أما النقاط [11:26] الفارغة فتمثل الوكيل [11:28] الذي يتخذ قرارًا بشأن [11:29] ما يجب فعله من خلال [11:31] قراءة الإجراء النصي. [11:34] وهناك بعض الفروع [11:35] الأخرى غير الظاهرة في [11:37] هذا المخطط، وهي أشبه [11:41] بأشجار القرار هنا. [11:45] إذن، ما الذي يمكن أن [11:47] يحدث هنا؟ هذه [11:48] الإجراءات التشغيلية [11:49] القياسية (SOPs) عبارة عن [11:51] وثائق طويلة جدًا. قد [11:52] تصل إلى 15 أو 20 صفحة، [11:54] وأحيانًا أكثر. تُذكر [11:56] قيمة في بداية الوثيقة [11:58] ، ولكن يتم استخدامها [12:01] في الخطوة 27. يضل [12:02] النظام طريقه هناك. [12:04] أحيانًا يحتاج إلى [12:06] الانتقال إلى حالة [12:07] مختلفة، ولكن إذا لم [12:09] يفعل، فقد يعمل بشكل [12:11] غير صحيح. أيضًا، يجب [12:13] أن يعرف النظام أنه [12:14] بمجرد فشله، لا يعرف [12:16] إلى أين يتجه، لذلك [12:17] يستمر في التقدم، ولكن [12:19] ربما يكون المسار [12:20] الصحيح هو الرجوع [12:22] للخلف. الاحتمال [12:24] التالي هو أنه يفترض [12:26] أشياءً. قد تكون هذه [12:28] أخطاءً بسيطة جدًا، [12:30] مثل الهلوسة. الاحتمال [12:34] السادس هو أنه يستخدم [12:36] الأداة الخاطئة، [12:37] والتي تبدو مشابهة لما [12:39] كان ينبغي استخدامه، [12:41] ولكنه اختارها بشكل [12:45] خاطئ. سنستعرض كل هذه [12:47] الاحتمالات بسرعة. [12:49] أولها هو فقدان الحالة [12:51] . يحدث هذا عندما يُذكر [12:53] شيء ما في الخطوة [12:54] الثانية، ثم يُحتاج [12:56] إليه في الخطوة 27. [12:58] لنفترض، على سبيل [12:59] المثال، أن نماذج [13:02] اللغة الكبيرة هي [13:04] نماذج تحويلية، مما [13:06] يعني أن آلية الانتباه [13:07] فيها تتدهور كلما طال [13:09] السياق. لذا، يحدث هذا [13:12] ، فنرى القيمة تُفقد [13:14] في مكان ما، ويفترض [13:16] النموذج أشياءً. أما [13:19] الوضع الثاني فهو [13:20] انهيار الفرع، وكما [13:22] ترون، كان هذا فرع [13:24] قرار. ويبدو هنا كسهم [13:27] صغير، لكن في الواقع، [13:29] إذا رسمنا هذا المخطط [13:31] لأمر إجرائي، قرار عمل [13:34] إجرائي نرغب في أتمتته [13:36] ، فقد يبدو معقدًا [13:38] للغاية، أشبه بشجرة. [13:41] لذا، أي شيء لا يسير في [13:47] الفرع الصحيح قد يكون [13:49] خطأً آخر. والسبب هو [13:53] نفسه السابق: فقدان [13:54] السياق الطويل في [13:55] المنتصف، وهي ظاهرة [13:57] تحدث عندما تتعامل [13:58] نماذج اللغة الكبيرة [14:00] مع كمية كبيرة من [14:01] البيانات النصية، فلا [14:03] تستطيع تحديد [14:04] المعلومات الصغيرة [14:05] المخفية فيها. أما [14:09] الثالث فهو انعكاس [14:12] الأسبقية، وهو مصطلح [14:14] تقني يعني ببساطة خروج [14:16] العملية عن ترتيبها. [14:18] بالطبع، هناك تسلسل [14:19] هنا، كما ذكرتُ سابقًا [14:21] ، مع هذا الترتيب [14:23] العددي. لكن في معظم [14:25] الأحيان، أثناء بناء [14:27] هذه الأنظمة، نرغب في [14:29] التأكد من تنفيذ [14:31] المهام بالتوازي كلما [14:33] أمكن، ثم اتباع [14:34] التسلسل عند الضرورة، [14:36] وهذه الإجراءات هي [14:38] مزيج من الاثنين. لذا، [14:41] يحتاج النظام حقًا إلى [14:43] فهم مكان التبعية وأين [14:45] يمكنه استدعاء المهام [14:47] بالتوازي. هذه هي [14:49] أنواع الأخطاء التي قد [14:51] تحدث. أما الخطأ [14:57] التالي فهو التعويض [14:58] المفقود. هذا خطأ بالغ [15:00] الأهمية، فعندما يفشل [15:05] النظام في الخطوة [15:07] الخامسة، لا يعرف ماذا [15:09] يفعل لأن هذه الخطوة [15:10] غير مذكورة في الإجراء [15:12] . وهذا ينطبق على معظم [15:15] عمليات الأعمال [15:16] الموثقة في معظم [15:17] الشركات حاليًا، [15:19] لأننا لم نكن نكتب هذه [15:21] الإجراءات للأنظمة. [15:23] كنا نكتبها للبشر، لكن [15:25] الآن سيقرأها [15:26] ويؤتمتها وكيل. هذا [15:29] يُبرز سبب حاجتنا [15:30] لإعادة كتابتها أو [15:31] إعادة هيكلتها أو [15:33] التفكير فيها بشكل [15:34] مختلف تمامًا. حسنًا، [15:38] النقطة التالية هي [15:40] الحل الصامت. وهذا [15:43] أيضًا أمر نغفل عنه [15:45] أحيانًا عند تصميم [15:47] وكلائنا، وهو أنه إذا [15:49] لم يكن الوكيل يعرف [15:51] شيئًا، أو لم يعرف إلى [15:53] أين يتجه، فيجب أن [15:54] يكون قادرًا على [15:56] السؤال، أو التوقف [15:58] مؤقتًا، أو التصعيد، [16:00] أو إظهار خطأ، لا أعرف [16:02] ، لكن يجب أن يكون لديه [16:04] مسار يسمح له [16:05] باحتمالية الفشل، [16:07] تمامًا كما يفعل البشر [16:09] عند قيامهم بهذا العمل [16:11] . هذا نمط فشل آخر قد [16:14] نواجهه. وهذا أمر يجب [16:18] تضمينه في وكلائنا [16:19] بالطبع. حسنًا، نقطة [16:22] أخرى هي تعريف الأداة [16:24] الغامض. حسنًا، قد [16:26] يبدو الأمر بسيطًا [16:27] جدًا عند استخدام أربع [16:29] أدوات، ولكن ماذا لو [16:30] كان لديك 4000 أداة [16:32] لإجراء معين، وكانت [16:33] جميعها متشابهة جدًا، [16:35] ولكل منها إصدارات، [16:37] وأسماء طرق متشابهة، [16:39] وواجهات برمجة [16:40] تطبيقات متشابهة، وما [16:41] إلى ذلك؟ من المهم [16:42] جدًا أن تكون تعريفات [16:45] الأدوات حصرية. عندها [16:47] فقط يعرف النظام متى [16:48] يستخدم أي أداة، حتى [16:50] لو كانت الأسماء [16:51] متشابهة. لذا، فإن وصف [16:53] الأدوات التي يمكنه [16:54] الوصول إليها هو الأهم [16:56] ، وهو أيضًا أحد أهم [17:00] أسباب الفشل. هذه هي [17:05] أنواع الأخطاء الستة، [17:06] أو أنماط الفشل التي [17:08] أردت التحدث عنها [17:09] عادةً. ثلاثة منها [17:12] إجرائية، والباقي [17:14] للأدوات والتنفيذ، [17:16] وهناك أنواع أخرى [17:17] للاستدلال والتأسيس. [17:22] عندما نبني هذه [17:23] الأنظمة لهذه [17:24] الإجراءات في أمازون، [17:26] فإننا بالطبع ننظر إلى [17:28] أنماط الفشل هذه التي [17:30] عممتها للتبسيط، [17:32] ولكننا نتعمق أيضًا في [17:34] تفاصيل الإجراء نفسه، [17:36] ثم في بنية النظام [17:38] نفسه. هذا هيكل أساسي [17:40] جدًا لأنواع الأخطاء [17:41] التي قد ترغب في [17:43] إجرائها لوكيلك. ولكن [17:44] عليك بعد ذلك التفكير [17:46] مليًا في بنية الوكيل [17:48] والعملية التي تحاول [17:50] أتمتتها، لأنه ستكون [17:52] هناك أخطاء خاصة بكل [17:54] مجال تحتاج إلى تتبعها [17:56] . الآن، إليكم الجزء [17:59] العلني. لقد نشرنا 12 أو [18:02] 13 من هذه الإجراءات، [18:04] مع جميع نصوصها [18:06] وأدواتها المحاكاة [18:07] وكل شيء، بالإضافة إلى [18:10] البيانات المرجعية [18:12] لبعض هذه المهام، وهي [18:14] متاحة على كود GitHub [18:15] الخاص بنا. وهذا يشمل [18:19] مجالات متنوعة للغاية [18:21] ، من التعليق على [18:22] الفيديو إلى خدمة [18:24] العملاء ومحتوى [18:25] البريد الإلكتروني [18:27] وفحص الطائرات، [18:28] وغيرها الكثير. هذه [18:30] كلها إجراءات تشغيل [18:31] قياسية حقيقية [18:32] تستخدمها أمازون [18:35] لاتخاذ القرارات في [18:37] عملياتها. إليكم بعض [18:39] النتائج التي توصلنا [18:41] إليها عندما شغّلنا [18:43] وكلائنا على جميع هذه [18:44] المجالات التي عرضتها [18:46] لكم للتو. أولاً، [18:49] الصعوبة خاصيةٌ [18:50] للإجراء وليست للوكيل [18:53] ، وهذا يعني أن كفاءة [18:57] الوكيل تعتمد على مدى [18:59] تعقيد الإجراء. هنا [19:01] نرى أن بعض المشكلات [19:03] حُلت بنسبة 100%، بينما [19:05] حُلت مشكلات أخرى [19:07] بنسبة 40-57%، حتى مع [19:09] أحدث النماذج. ثانياً، [19:15] إذا زودنا وكلاءنا [19:17] بعدد كبير جدًا من [19:19] الأدوات لحل المشكلات [19:21] ، فإن الدقة تتراجع. قد [19:24] يظن المرء أن اختيار [19:27] أداة من بين 5000 أداة [19:28] سيستغرق وقتًا أطول، [19:30] وبالتالي يصبح زمن [19:31] الاستجابة مشكلة، لكن [19:33] هذا ليس صحيحًا. ما [19:35] يحدث فعليًا هو أن [19:36] الأداء يتراجع. ثالثاً [19:40] ، ترحيل النماذج ليس [19:45] بالبساطة التي يبدو [19:46] عليها. ليس الأمر أنك [19:48] ستنتقل إلى نموذج أفضل [19:50] ثم سيحل جميع مشكلاتك. [19:52] سؤال سريع: بين الطول [19:54] والتعقيد، أين يكون [19:56] أداء نماذج التعلم [19:58] الخطي (LLMs) أسوأ أو [20:00] أفضل؟ في الواقع، [20:01] يتعلق الأمر بالطول. [20:03] حسنًا، يمكنه التعامل [20:05] مع التعقيد بشكل جيد، [20:07] وهو أمرٌ فاجأنا. لذا، [20:09] في الختام، أودّ أن [20:10] أذكر بعض الأمور: [20:12] أثناء بناء وكيل، يجب [20:14] التفكير في تحويل [20:15] الإجراء إلى بنية [20:17] واضحة الآن بعد أن [20:18] أصبح قابلاً للقراءة [20:20] بواسطة الذكاء [20:21] الاصطناعي. ثانيًا، [20:23] قلّل عدد الأدوات. [20:25] ثالثًا، أعد كتابة وصف [20:27] هذه الأدوات. رابعًا، [20:29] طبّق هذه القواعد [20:30] واكتب التعليمات [20:31] البرمجية خارج [20:32] النموذج، وهي أمور [20:34] يمكنك التحكم بها [20:35] فعليًا. خامسًا، اجعل [20:37] التصعيد خيارًا [20:38] صريحًا في الوكيل كما [20:40] ذكرت، ثم حدّد مسارات [20:42] الاسترداد، ثم فعّل [20:44] تتبعات تنفيذ الملفات [20:46] التنفيذية بشكل صحيح. [20:49] مع أن البناء سهل، إلا [20:50] أن التقييم والتحسين [20:52] صعبان للغاية. لذا، [20:54] نقترح للقياس أن تقيس [20:56] عبر عمليات تشغيل [20:57] متكررة، وليس فقط [20:59] عملية تشغيل واحدة. [21:00] هناك الكثير من [21:01] التذبذب في الوكيل [21:03] تحديدًا. ثمّ، قدّم [21:05] تقارير حسب البُعد. لا [21:07] تستخدم مقياسًا [21:08] واحدًا لكل ما يفعله [21:10] وكيلك. واربط مجموعة [21:12] المقاييس بالمجال. [21:13] بالطبع، أنشئ مقاييس [21:15] جديدة، وزِد التكرار [21:17] حسب المرحلة. ابدأ [21:18] بالأساسيات ثم أضف [21:20] المزيد من التعقيد. [21:21] بعد ذلك، اختبر [21:23] الإجراءات غير [21:24] المألوفة. لا تُعطِ [21:25] جميع الأمثلة للوكيل [21:27] الذي تُنشئه، احتفظ [21:28] ببعضها للاختبار فقط. [21:30] وأخيرًا، هناك [21:31] انتهاكات جسيمة، يجب [21:33] عليك التحقق منها. هذا [21:36] كل شيء. شكرًا جزيلًا.