diff --git a/book-ar/chapter9.ar.md b/book-ar/chapter9.ar.md index 2172bf51e..7f8222534 100644 --- a/book-ar/chapter9.ar.md +++ b/book-ar/chapter9.ar.md @@ -87,18 +87,6 @@ ويقدّم التعلم من تجارب GAIA مثالًا واضحًا. يتضمن معيار GAIA[^gaia-2023] مسائل متعددة الخطوات تجمع بين البحث وقراءة الويب ومعالجة الملفات والحساب، بينما يوفّر AWorld[^aworld-2025] بيئة لتشغيل الوكلاء واستدعاء الأدوات وتسجيل المسارات. فالأول أشبه بورقة الاختبار، والثاني بقاعة الاختبار ونظام تسجيل نتائجه. وقد يكتفي نهج ساذج بتلخيص استراتيجية تشغيل ناجح وإدخالها مباشرة في الموجّه. أما التطبيق المنضبط فيبدأ بمدقق إجابات GAIA، أو بمدقق بيئي آخر، لتصنيف كل تشغيل إلى ناجح أو ناجح جزئيًا أو فاشل، ثم يقارن مسارات عدة من عائلة المهمة نفسها. تقترح المسارات الناجحة استراتيجيات مرشحة، وتكشف الإخفاقات ما ينبغي تجنبه، وتبيّن النجاحات الجزئية الجزء الذي نجح والجزء الذي بقي عالقًا. وقد يساعد التأمل اللغوي الذي اقترحته Reflexion[^reflexion-2023] على صياغة دروس مرشحة، لكنه ليس دليلًا في ذاته. ولا ينبغي إدخال درس في وثائق الخبرة المعتمدة إلا إذا وافق نتائج البيئة، وتكرر تأييده عبر مسارات عدة، وأظهر أثرًا إيجابيًا عند نقله إلى مهام جديدة. -> **التجربة 9-2 ★★: استخلاص مستندات المعرفة الخاصة بالخبرة من مسارات GAIA** -> -> **الهدف:** اختبار ما إذا كانت وثائق المعرفة عبر المسارات تنقل بشكل أفضل من ملخص نجاح واحد وتقليل النقل السلبي من النجاحات العرضية والخبرة غير الصحيحة. -> -> **البيانات والإجراءات:** تقوم `gaia-experience` أولاً بتخزين المسار الكامل و`environment_score` الخارجي لكل تشغيل، ثم تحويلها إلى الحد الأدنى من سجلات التعلم التي تحتوي على `task_family`، و`capabilities` المطلوبة، و`applies_when`، والاستراتيجيات الملحوظة، والأخطاء، والاستثناءات، ومعرفات مسار المصدر. يصنف مدقق النتائج عمليات التشغيل على أنها ناجحة أو ناجحة جزئيًا أو فاشلة. تقوم وحدة التعلم النمطية بمقارنة المسارات ضمن مجموعة المهام نفسها. قد يقترح LLM تعميمات مرشحة، لكن الإستراتيجية الموصى بها يجب أن تكون مدعومة بمسارين غير فاشلين على الأقل. تتضمن وثيقة Markdown الناتجة سيناريوهات قابلة للتطبيق، والاستراتيجيات الموصى بها، والمزالق الشائعة، والاستثناءات، والمصدر، وأحدث وقت للتحقق من الصحة. أثناء التقديم، يتم استرجاع هذه المستندات فقط؛ لا يتم إدراج المسارات الخام الطويلة مباشرة في السياق. -> -> **ثلاثة ضوابط:** الشرط الأول لا يستخدم أي خبرة تاريخية؛ يسترد الثاني ملخص المسار الأكثر تشابهًا مع المهمة الحالية؛ والثالث يسترد وثيقة معرفية مدعومة بمسارات متعددة. يجب أن تكون مجموعات التعلم والنقل منفصلة حتى لا تتسرب الإجابات على نفس سؤال GAIA إلى التقييم باعتباره "خبرة". -> -> **المقاييس والقبول:** قم بالإبلاغ عن معدل نجاح مهمة النقل، ومتوسط الأحرف أو الرموز المستردة، ومعدل النقل السلبي، وتحقق من أن كل استنتاج رسمي يستشهد بمسارات مصدره. إذا كانت المستندات عبر المسارات تؤدي فقط إلى تقصير السياق دون تحسين أداء المهام الجديدة، فإنها لا تثبت الخبرة المكتسبة. تفشل التجربة أيضًا إذا كان من الممكن ترقية نجاح عرضي مباشر إلى المعرفة الرسمية أو إذا لم يكن من الممكن تتبع الوثيقة إلى مساراتها الأصلية. -> -> التنفيذ المصاحب متاح في مشروع [`gaia-experience`](https://github.com/bojieli/ai-agent-book/tree/main/chapter8/gaia-experience). يتم تشغيل `demo_documents.py` دون اتصال بشكل افتراضي؛ مع `--extractor llm`، يمكن لـ LLM الحقيقي أن يقترح مرشحين ذوي خبرة عبر المسارات. - [^reflexion-2023]: شين، N.، وآخرون. *التأمل: وكلاء اللغة مع التعلم المعزز اللفظي.* أرخايف:2303.11366، 2023. [^gaia-2023]: ميالون، G.، وآخرون. *GAIA: معيار لمساعدي الذكاء الاصطناعي العام.* arXiv:2311.12983, 2023. @@ -113,13 +101,27 @@ وتعلّمُ الـ Prompt النظامي ليس هو هندسةَ المطالبات في الفصل الثاني. فذلك الفصل ناقش كيف تُنظَّم مطالبة جيدة؛ أما هذا القسم فيناقش أيَّ تغذية راجعة تكفي لتفعيل تعديل، وكيف يُطلَق مقترح التحديث بأمان. وينبغي أن يكون التعديل diff أدنى مقترنًا بمصدره، لا إعادةَ كتابة المطالبة كاملةً في كل مرة — وهذا بالضبط نمط «الـ diff الأدنى مع إمكانية التراجع» الذي سُمِّي في الفصل الأول. ويجب اختبار النسخة المرشَّحة في آنٍ واحد على **مجموعة الحدود التي أطلقت الإخفاق** وعلى **مجموعة احتفاظ تعمل أصلًا بصورة سليمة**: فالأولى ينبغي أن تتحسن، والثانية لا يجوز أن تتراجع. -#### المثال الأول: تحسين القواعد في المطالبات بناءً على مسارات الفشل +#### المثال الأول: تحويل حدّ التحويل إلى قواعد + +في سياسة نطاق telecom من τ²-bench، لا يحكم التحويل إلى موظف بشري سوى نصّين مبدئيين: لا تُحوِّل إلا إذا خرج الطلب عن نطاق أفعال الوكيل، وابذل وسعك في الحل قبل التحويل. حين شرّح الفصل السابع هذه البيئة لم يُظهر هذان السطران أي خلل؛ لكن شغِّل البيئة نفسها بنموذج أضعف فيبرز النقص فورًا — بعد أن تُعيد الأداة خطأً يعاود الوكيل المحاولة مرارًا، ثم ينهي الأمر بالتحويل إلى موظف بشري. بهذه الطريقة انتهت 19 مهمة من أصل 20 في مجموعة الاستخلاص. -استعان الفصل السابع بـ τ-bench/τ²-bench لبيان طريقة تقييم وكيل خدمة عملاء شركة طيران: يكشف المستخدم حاجاته تدريجيًا، ويفحص النظام حالةَ البيئة مثل الحجز، كما يفحص هل قُدِّمت المعلومات الضرورية في الحوار. كما شدّد عزوُ الإخفاق في ذلك الفصل على أنه لا يكفي تسجيل «إخفاق»، بل يجب العثور على **أول خطوة خاطئة**. +سلِّم هذه المسارات التسعة عشر الفاشلة إلى نموذج، ودعه يستنبط بنفسه بضع قواعد قابلة للتنفيذ تُضاف إلى نهاية السياسة، ثم أعد التشغيل على مجموعة مهام لم تشارك في الاستخلاص إطلاقًا: ترتفع نسبة النجاح من 12.3% إلى 19.3%، ولا تُفسَد ولا مهمة واحدة كانت تنجح من قبل. -والحالة المشكلة هنا هي: يستاء المستخدم من الاسترداد أو رسوم التغيير أو سياسة الأمتعة، فيستدعي الوكيلُ `transfer_to_human` من غير أن يراجع السياسة أو يشرح القاعدة أو يبحث عن بديل مسموح. والخلاف العادي حول السياسة لا يستوجب تحويلًا؛ **وإنما يجب التحويل حين يطلب المستخدم موظفًا بشريًا صراحةً، أو حين ينشأ خطر على السلامة أو على الأشخاص**. فالمشكلة إذن ليست أن «الوكيل غير مهذب بما يكفي»، بل أن المطالبة لم تكتب حدود التحويل كتابةً واضحة. +**ما يُعرَض على المستخلِص هو ما يحدد ما يستطيع استنباطه.** من المسارات التسعة عشر نفسها، يؤدي الاكتفاء بملخّصات الإخفاق ونصوص الأخطاء إلى «لا تواصل استدعاء أداة تعيد الخطأ نفسه مرارًا»؛ أما إضافة قائمة بالأدوات التي يملكها الوكيل وتلك التي يملكها المستخدم فتحوّل النتيجة إلى «فحص حالة الشبكة وشريحة SIM وإعدادات APN يخص جهاز المستخدم، وينبغي توجيه المستخدم لتنفيذه بنفسه بدل استدعائه مباشرة». الأول تسجيل لدرس، والثاني إدراك لموضع المسؤولية. + +**يتعامل النموذج مع السلوك الملاحَظ بوصفه السلوك الواجب.** جاء في قواعد النسخة الأولى بندان: «حوِّل إلى موظف بشري بعد ثلاثة استدعاءات فاشلة متتالية»، و«حوِّل إلى موظف بشري إن لم يقدّم المستخدم رقمه بعد طلبين» — وأكثر ما يتكرر في المسارات هو التحويل إلى البشر، فعدّه النموذج ملاذًا أخيرًا معقولًا. غير أن التحويل في هذا التقييم يُحكم عليه بالإخفاق حتمًا، فهذان البندان يكتبان الإخفاق في صلب اللائحة. لذلك لا يجوز نشر ناتج الاستخلاص مباشرة، بل عليه أن يمر بتحقق مستقل عمّا أنتجه. + +**ما يُصلَح غالبًا ما يكون شيئًا بالغ البساطة.** في الذراع الأساسي مسار نموذجي: يحتاج الوكيل إلى رقم هاتف المستخدم فيستدعي أداة الاستعلام، وقد وضع في المعامل عبارة «يُرجى تزويدي برقم هاتفك» — خمس مرات متتالية، وخمسة أخطاء، ثم التحويل. لقد استنتج فعلًا أن عليه سؤال المستخدم، إلا أنه وجّه هذه الجملة إلى الأداة. وبعد سريان القواعد صار يطلب الرقم أولًا داخل الحوار، ثم يستعلم بعد الحصول عليه؛ ولمّا رفضت طبقة الأدوات محاولته فحص حالة شريحة SIM، انتقل إلى توجيه المستخدم لإعادة تركيب الشريحة بنفسه، ونجحت المهمة. + +> **التجربة 9-2 ★★: استخلاص قواعد التحويل واستخدام الأدوات من مسارات τ²-bench الفاشلة** +> +> تُستعمل بيئة τ²-bench telecom من الفصل السابع كما هي. ومجموعة الاستخلاص ومجموعة النقل هما أصلًا مجموعتا مهام متباينتان في المستودع الأصلي، فلا تمس عملية الاستخلاص مجموعة النقل البتة. +> +> شغِّل أولًا مجموعة الاستخلاص بنموذج ضعيف واحفظ المسارات الفاشلة؛ ولتستنبط القواعدَ نموذجٌ لا إنسان، وتُضاف بعد توليدها إلى نهاية السياسة الأصلية؛ ثم قارن على مجموعة النقل بين السياسة الأصلية والنسختين المتطورتين. ولا يُستبدل بين الأذرع الثلاثة سوى ملف السياسة، ويبقى محاكي المستخدم ثابتًا. +> +> وإلى جانب نسبة النجاح ينبغي تسجيل ثلاثة مؤشرات سلوكية تقابل القواعد مباشرة: نسبة التحويل إلى البشر، وعدد المرات التي يتجاوز فيها الوكيل حدوده فيستدعي أداة من جانب المستخدم، وعدد الاستدعاءات الصادرة بمعامل ناقص. وقد انخفض المؤشران الأخيران نحو 80% في النسختين المتطورتين، وهو ما يبيّن أن ارتفاع نسبة النجاح ناتج عن إصلاح القواعد لأفعال بعينها. -ويتحول هذا التشخيص مباشرةً إلى قاعدة واحدة داخل المطالبة: راجع السياسة أولًا واشرحها، وتبيّن الهدف الذي يريد المستخدم حلّه فعلًا، واعرض بديلًا موافقًا للأنظمة؛ ولا تحوّل إلا عند طلب موظف بشري صراحةً، أو عند تجاوز الصلاحية أو تعلّق الأمر بالسلامة. +ويمكن نقل الأسلوب نفسه إلى مجالات أخرى. والحالة الإشكالية النمطية لوكيل خدمة عملاء طيران هي التالية: يعترض المستخدم على رسوم الاسترداد أو رسوم التغيير أو سياسة الأمتعة، فيستدعي الوكيل `transfer_to_human` من غير أن يراجع السياسة أو يشرح القاعدة أو يبحث عن بديل متوافق. والخلاف العادي حول السياسات لا يستدعي التحويل؛ **ولا يصير التحويل واجبًا إلا بطلب صريح لموظف بشري، أو عند نشوء موقف يتصل بالسلامة**. ويشير التشخيص مجددًا إلى حدّ تحويل لم يُنص عليه صراحة، ويظل الإصلاح هو تحويله إلى قاعدة واحدة صغرى موثّقة المصدر. > **التجربة 9-3 ★★: تحسين المطالبة النظامية لخدمة عملاء الطيران انطلاقًا من المسارات الفاشلة** > diff --git a/book-en/chapter9.md b/book-en/chapter9.md index 173481b8b..8b4fd90ab 100644 --- a/book-en/chapter9.md +++ b/book-en/chapter9.md @@ -83,18 +83,6 @@ A complete knowledge-distillation pipeline can be divided into five steps. First GAIA experience learning provides an intuitive example. GAIA[^gaia-2023] contains multistep problems that combine search, web reading, file processing, and computation, while AWorld[^aworld-2025] provides the environment for running Agents, invoking those tools, and recording trajectories: the former is like the exam, and the latter is the exam room and laboratory record system. A simplistic approach generates a strategy summary and immediately vectorizes it after one successful run. A stricter implementation first uses a GAIA answer verifier or another environmental verifier to label runs as successful, partially successful, or failed, and then compares multiple paths within the same task family. Successful trajectories contribute candidate strategies, failures contribute exclusionary knowledge, and partial successes reveal which segment worked and which still failed. The natural-language reflection proposed by Reflexion[^reflexion-2023] can help generate candidate lessons, but reflection itself is not evidence. Only content consistent with environmental outcomes, supported across trajectories, and showing positive transfer on new tasks should enter formal experience documents. -> **Experiment 9-2 ★★: Distill Experience Knowledge Documents from GAIA Trajectories** -> -> **Objective:** Test whether cross-trajectory knowledge documents transfer better than a summary of a single success and reduce negative transfer from accidental successes and incorrect experience. -> -> **Data and procedure:** `gaia-experience` first stores the full trajectory and external `environment_score` for each run, then converts them into minimal learning records containing `task_family`, required `capabilities`, `applies_when`, observed strategies, errors, exceptions, and source trajectory IDs. An outcome verifier classifies runs as successful, partially successful, or failed. The learning module compares paths within the same task family. An LLM may propose candidate generalizations, but a recommended strategy must be supported by at least two non-failed trajectories. The resulting Markdown document includes applicable scenarios, recommended strategies, common pitfalls, exceptions, provenance, and the latest validation time. During application, only these documents are retrieved; lengthy raw trajectories are not inserted directly into the context. -> -> **Three controls:** The first condition uses no historical experience; the second retrieves the one trajectory summary most similar to the current task; the third retrieves a knowledge document supported by multiple trajectories. The learning and transfer sets must be disjoint so that answers to the same GAIA question do not leak into evaluation as “experience.” -> -> **Metrics and acceptance:** Report transfer-task success rate, average retrieved characters or Tokens, and negative-transfer rate, and verify that every formal conclusion cites its source trajectories. If cross-trajectory documents merely shorten the context without improving new-task performance, they do not demonstrate learned experience. The experiment also fails if one accidental success can be promoted directly to formal knowledge or if a document cannot be traced to its original trajectories. -> -> The accompanying implementation is available at [`gaia-experience`](../chapter9/gaia-experience/). `demo_documents.py` runs offline by default; with `--extractor llm`, a real LLM can propose cross-trajectory experience candidates. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy calls this practice **System Prompt Learning**[^karpathy-system- System prompt learning is not the same thing as the prompt engineering of Chapter 2. Chapter 2 discusses how to organize a good Prompt; this section discusses what feedback is sufficient to trigger a change, and how an update proposal is released safely. A change should be a minimal diff with provenance, not a full rewrite of the Prompt on every pass—precisely the minimal-diff-plus-rollback pattern named in Chapter 1. A candidate version must be tested both on the **boundary set that triggered the failure** and on a **retention set that already works**: the former must improve, the latter must not regress. -#### Example 1: Optimizing Rules in Prompts from Failure Trajectories +#### Example 1: Turning the Escalation Boundary into Rules + +In the telecom policy of τ²-bench, escalation to a human agent is governed by only two statements of principle: escalate only when the request falls outside the Agent's scope of action, and try your best to resolve the issue before escalating. When Chapter 7 dissected this environment the two lines revealed no problem; run the same environment with a weaker model and the deficiency surfaces at once—after a tool returns an error the Agent retries repeatedly and ends by escalating to a human, which is how 19 of the 20 tasks in the derivation set finished. -Chapter 7 used τ-bench/τ²-bench to illustrate how an airline customer-service Agent is evaluated: the user reveals requirements step by step, and the system checks both environment state such as the booking record and whether the conversation supplied the necessary information. That chapter's failure attribution also stressed that recording "failure" is not enough; one must locate the **first erroneous step**. +Hand those 19 failed trajectories to a model and let it induce, on its own, a handful of executable rules to append to the end of the policy; then rerun on a set of tasks that took no part in the derivation. The pass rate rises from 12.3% to 19.3%, and not one task that had passed before is broken. -The bad case here is this: the user is unhappy about a refund, a change fee, or a baggage policy, and the Agent calls `transfer_to_human` without looking up the policy, explaining the rule, or looking for a permitted alternative. An ordinary policy dispute does not require a transfer; **a transfer is mandatory only when the user explicitly asks for a human or a safety/personal-risk situation arises**. The problem, therefore, is not that "the Agent is not polite enough" but that the Prompt never spelled out the transfer boundary. +**What the deriver is given determines what it can induce.** From the same 19 trajectories, supplying only failure summaries and error text yields "do not keep calling a tool that repeatedly returns the same error"; adding an inventory of which tools belong to the Agent and which to the user turns the result into "network status, SIM card, and APN checks belong to the user's device and should be performed by the user under guidance rather than called directly." The first records a lesson; the second grasps where responsibility lies. + +**A model treats observed behavior as the behavior that ought to occur.** Two of the first-version rules read "escalate to a human after three consecutive failed calls" and "escalate to a human if the user does not supply a number after two requests"—escalation is what appears most often in the trajectories, so the model took it for a reasonable fallback. But in this evaluation escalation always counts as failure, so those two rules write failure into the specification. Derived artifacts therefore cannot be released directly; they must pass verification independent of whatever produced them. + +**What gets repaired is often something extremely plain.** One typical baseline trajectory: the Agent needs the user's phone number, so it calls the lookup tool with "Please provide your phone number" filled into the parameter—five times in a row, five errors, then escalation. It had already worked out that it should ask the user; it merely addressed the sentence to the tool. Once the rules took effect it first made the request in the conversation, obtained the number, and then queried; later, when an attempt to check SIM card status was refused at the tool layer, it switched to guiding the user through reseating the SIM card, and the task passed. + +> **Experiment 9-2 ★★: Deriving Escalation and Tool-Use Rules from τ²-bench Failure Trajectories** +> +> Reuse the τ²-bench telecom environment from Chapter 7. The derivation set and the transfer set are two disjoint task sets in the upstream repository to begin with, so the derivation process never touches the transfer set. +> +> First run the derivation set with a weak model and keep the failed trajectories; have the rules induced by a model rather than written by hand, and append them to the end of the original policy; then compare the original policy against the two evolved versions on the transfer set. Only the policy file differs across the three arms; the user simulator is held fixed. +> +> Besides the pass rate, record three behavioral metrics that correspond directly to the rules: the escalation rate, the number of times the Agent oversteps and calls a user-side tool, and the number of calls issued with a missing parameter. Both of the latter fall by roughly 80% in the evolved versions, which shows that the gain in pass rate comes from rules repairing specific actions. -This diagnosis translates directly into one rule in the prompt: first look up and explain the policy, identify the goal the user actually wants to reach, and offer a compliant alternative; transfer only when a human is explicitly requested, or when the request exceeds the Agent's authority or involves safety. +The same approach transfers to other domains. A typical bad case for an airline customer-service Agent is this: the user objects to a refund fee, a change fee, or a baggage policy, and the Agent calls `transfer_to_human` without looking up the policy, explaining the rule, or seeking a compliant alternative. An ordinary policy dispute needs no escalation; **only an explicit request for a human, or a situation involving safety, makes escalation mandatory**. The diagnosis again points to an escalation boundary that was never made explicit, and the fix is again to turn it into a single minimal rule with a recorded source. > **Experiment 9-3 ★★: Optimizing an Airline Customer-Service System Prompt from Failure Trajectories** > diff --git a/book-es/chapter9.es.md b/book-es/chapter9.es.md index 2f8635cbe..73eabcbde 100644 --- a/book-es/chapter9.es.md +++ b/book-es/chapter9.es.md @@ -83,18 +83,6 @@ Un flujo completo de destilación de conocimiento se puede dividir en cinco paso El aprendizaje de experiencia en GAIA proporciona un ejemplo intuitivo. GAIA[^gaia-2023] contiene problemas de múltiples pasos que requieren búsqueda integrada, lectura de páginas web, procesamiento de archivos y cálculos, mientras que AWorld[^aworld-2025] proporciona el entorno de ejecución para ejecutar Agentes, invocar estas herramientas y guardar trayectorias; el primero es como el examen y el segundo como el aula y el sistema de registro experimental. El enfoque antiguo consistía en generar un resumen de estrategia inmediatamente tras el éxito de una tarea e ingresarlo vectorizado en la base de datos; una implementación más rigurosa utiliza primero la verificación de respuestas de GAIA u otros verificadores de entorno para marcar éxitos, éxitos parciales y fracasos, comparando luego múltiples rutas de la misma familia de tareas. Las trayectorias exitosas aportan estrategias candidatas, las fallidas aportan conocimiento de exclusión y las parcialmente exitosas ayudan a identificar "qué tramo fue efectivo y cuál sigue presentando problemas". La reflexión en lenguaje natural propuesta por Reflexion[^reflexion-2023] puede participar en la generación de lecciones candidatas, pero la reflexión en sí no es evidencia: solo aquello que coincide con los resultados ambientales, cuenta con respaldo entre trayectorias y muestra una transferencia positiva en nuevas tareas debe ingresar a los documentos formales de experiencia. -> **Experimento 9-2 ★★: Extraer documentos de conocimiento de experiencia a partir de trayectorias de GAIA** -> -> **Objetivo del experimento**: Verificar si los "documentos de conocimiento entre trayectorias" son más fáciles de transferir que "recordar el resumen de un solo éxito", reduciendo la transferencia negativa provocada por éxitos casuales y experiencias erróneas. -> -> **Datos y proceso**: `gaia-experience` guarda primero la trayectoria completa y el `environment_score` externo de cada ejecución, convirtiéndolos luego en un registro de aprendizaje mínimo: `task_family`, `capabilities` requeridas, `applies_when`, estrategias observadas, errores, excepciones e ID de trayectorias de origen. El verificador de resultados clasifica las ejecuciones en éxito, éxito parcial y fracaso; el módulo de aprendizaje compara las rutas dentro de la misma familia de tareas; el LLM puede proponer inducciones candidatas, pero una estrategia recomendada debe contar al menos con el respaldo de dos trayectorias no fallidas. Los documentos Markdown finales incluyen escenarios aplicables, estrategias recomendadas, errores comunes, condiciones de excepción, fuentes y fecha de última verificación. La fase de aplicación solo recupera estos documentos, sin introducir trayectorias originales extensas directamente en el contexto. -> -> **Tres grupos de contraste**: El primer grupo no utiliza experiencia histórica; el segundo recupera el resumen de la trayectoria más similar a la tarea actual; el tercer grupo recupera documentos de conocimiento respaldados conjuntamente por múltiples trayectorias. Los conjuntos de aprendizaje y de transferencia deben ser estrictamente disjuntos para evitar filtrar las respuestas de una misma pregunta de GAIA como "experiencia" a la evaluación. -> -> **Indicadores y aceptación**: Se reportan simultáneamente la tasa de éxito en tareas de transferencia, el promedio de caracteres o tokens recuperados y la tasa de transferencia negativa, comprobando si cada conclusión formal enumera sus trayectorias de origen. Si los documentos entre trayectorias solo acortan el contexto sin mejorar el rendimiento en nuevas tareas, no se demuestra que el sistema haya aprendido de la experiencia; si un éxito fortuito se promociona a conocimiento formal o si los documentos no se pueden rastrear hasta la trayectoria original, la prueba no se considera superada. -> -> La implementación correspondiente se encuentra en [`gaia-experience`](../chapter9/gaia-experience/). `demo_documents.py` se ejecuta por defecto sin conexión; utilizando `--extractor llm` un LLM real puede proponer candidatos de experiencia entre trayectorias. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy llama a esta práctica **aprendizaje del prompt de sistema** (Sy El aprendizaje del prompt de sistema no es lo mismo que la ingeniería de prompts del capítulo 2. Aquel capítulo trata de cómo organizar un buen Prompt; esta sección trata de qué realimentación basta para desencadenar un cambio y de cómo publicar con seguridad una propuesta de actualización. El cambio debe ser un diff mínimo con procedencia, no una reescritura completa del Prompt en cada pasada: es justamente el patrón «diff mínimo + reversible» que se nombró en el capítulo 1. La versión candidata debe probarse a la vez sobre el **conjunto frontera que provocó el fallo** y sobre un **conjunto de retención que ya funciona**: el primero ha de mejorar y el segundo no puede empeorar. -#### Ejemplo 1: Optimización de reglas en el prompt basada en trayectorias de falla +#### Ejemplo 1: convertir el límite de escalado en reglas + +En la política del dominio telecom de τ²-bench, la derivación a un agente humano se rige por solo dos enunciados de principio: derivar únicamente cuando la solicitud exceda el ámbito de acción del Agent, y esforzarse al máximo por resolver antes de derivar. Cuando el capítulo 7 diseccionó este entorno, esas dos líneas no revelaron problema alguno; ejecútelo con un modelo más débil y la carencia aflora de inmediato: tras un error de herramienta el Agent reintenta una y otra vez y termina derivando a un humano. Así concluyeron 19 de las 20 tareas del conjunto de extracción. -El capítulo 7 usó τ-bench/τ²-bench para explicar cómo se evalúa un Agente de atención al cliente de una aerolínea: el usuario revela sus necesidades poco a poco y el sistema comprueba tanto el estado del entorno —la reserva, por ejemplo— como si la conversación aportó la información necesaria. La atribución de fallos de aquel capítulo insistía además en que no basta con registrar «fallo»: hay que encontrar el **primer paso erróneo**. +Entregue esas 19 trayectorias fallidas a un modelo y deje que induzca por sí mismo unas cuantas reglas ejecutables para añadirlas al final de la política; después vuelva a ejecutar sobre un conjunto de tareas que no participó en la extracción. La tasa de éxito sube del 12,3% al 19,3%, y ninguna de las tareas que antes pasaban queda rota. -El caso problemático aquí es este: el usuario se queja del reembolso, de la tasa de cambio o de la política de equipaje, y el Agente llama a `transfer_to_human` sin consultar la política, sin explicar la norma y sin buscar una alternativa permitida. Una disputa ordinaria sobre políticas no exige transferencia; **la transferencia solo es obligatoria cuando el usuario pide explícitamente un agente humano o cuando aparece un riesgo de seguridad o para las personas**. El problema, por tanto, no es que «el Agente no sea bastante cortés», sino que el Prompt nunca dejó escrita la frontera de la transferencia. +**Lo que se le muestra al extractor determina lo que puede inducir.** A partir de las mismas 19 trayectorias, suministrar solo los resúmenes de fallo y los textos de error produce «no sigas llamando a una herramienta que devuelve el mismo error una y otra vez»; añadir un inventario de qué herramientas corresponden al Agent y cuáles al usuario convierte el resultado en «comprobar el estado de la red, la SIM o el APN pertenece al dispositivo del usuario y debe realizarlo el propio usuario con nuestra guía, no llamarse directamente». Lo primero registra una lección; lo segundo comprende dónde reside la responsabilidad. + +**El modelo toma el comportamiento observado por el comportamiento debido.** Dos de las reglas de la primera versión decían «derivar a un humano tras tres llamadas fallidas consecutivas» y «derivar a un humano si el usuario no facilita el número tras dos peticiones»: lo que más aparece en las trayectorias es precisamente la derivación, de modo que el modelo la tomó por un recurso de último término razonable. Pero en esta evaluación la derivación se juzga siempre como fracaso, así que esas dos reglas escriben el fracaso dentro de la propia norma. Por eso el producto de la extracción no puede publicarse tal cual: debe pasar una verificación independiente de aquello que lo generó. + +**Lo que se repara suele ser algo sumamente llano.** En la línea base hay una trayectoria característica: el Agent necesita el número de teléfono del usuario, así que llama a la herramienta de consulta con «Por favor, facilíteme su número de teléfono» escrito en el parámetro; cinco veces seguidas, cinco errores, y después la derivación. Ya había deducido que debía preguntar al usuario; simplemente dirigió esa frase a la herramienta. Una vez en vigor las reglas, primero formula la petición en la conversación, obtiene el número y solo entonces consulta; más tarde, cuando la capa de herramientas rechaza su intento de comprobar el estado de la SIM, pasa a guiar al usuario para que reinserte la tarjeta, y la tarea se supera. + +> **Experimento 9-2 ★★: Extraer reglas de escalado y uso de herramientas de las trayectorias fallidas de τ²-bench** +> +> Se reutiliza el entorno τ²-bench telecom del capítulo 7. El conjunto de extracción y el de transferencia son ya de partida dos conjuntos de tareas disjuntos en el repositorio original, de modo que el proceso de extracción nunca toca el conjunto de transferencia. +> +> Ejecute primero el conjunto de extracción con un modelo débil y conserve las trayectorias fallidas; las reglas las induce un modelo, no una persona, y una vez generadas se añaden al final de la política original; después compare en el conjunto de transferencia la política original con las dos versiones evolucionadas. Entre los tres brazos solo se sustituye el archivo de política; el simulador de usuario permanece fijo. +> +> Además de la tasa de éxito hay que registrar tres indicadores de conducta que se corresponden directamente con las reglas: la proporción de derivaciones a un humano, el número de veces que el Agent se extralimita y llama a una herramienta del lado del usuario, y el número de llamadas emitidas sin un parámetro obligatorio. Ambos indicadores últimos caen alrededor de un 80% en las versiones evolucionadas, lo que muestra que la mejora de la tasa de éxito procede de que las reglas repararon acciones concretas. -Este diagnóstico se convierte directamente en una regla del prompt: primero consultar y explicar la política, identificar el objetivo que el usuario quiere resolver realmente y ofrecer una alternativa conforme a la normativa; transferir solo si se pide explícitamente un humano, o si la petición excede la autoridad del Agente o afecta a la seguridad. +El mismo procedimiento se traslada a otros dominios. Un caso problemático típico de un Agent de atención al cliente de aerolínea es este: el usuario objeta una tasa de devolución, una tasa de cambio o la política de equipaje, y el Agent llama a `transfer_to_human` sin consultar la política, sin explicar la regla y sin buscar una alternativa admisible. Una disputa corriente sobre políticas no requiere derivación; **solo la hacen obligatoria una petición explícita de atención humana o una situación relacionada con la seguridad**. El diagnóstico vuelve a señalar un límite de escalado que nunca se explicitó, y la corrección vuelve a consistir en convertirlo en una única regla mínima con su procedencia registrada. > **Experimento 9-3 ★★: Optimizar el Prompt de sistema de atención al cliente aérea a partir de trayectorias fallidas** > diff --git a/book-he/chapter9.he.md b/book-he/chapter9.he.md index 7d361d8fd..8f25c207a 100644 --- a/book-he/chapter9.he.md +++ b/book-he/chapter9.he.md @@ -83,18 +83,6 @@ למידת ניסיון ב‑GAIA מספקת דוגמה אינטואיטיבית. ‏GAIA‏[^gaia-2023] מכיל בעיות רב‑שלביות המשלבות חיפוש, קריאת דפי אינטרנט, עיבוד קבצים וחישוב, ואילו AWorld‏[^aworld-2025] מספק את הסביבה להרצת סוכנים, להפעלת אותם כלים ולתיעוד מסלולים: הראשון הוא כמו הבחינה, והשני הוא חדר הבחינות ומערכת רישום המעבדה. גישה פשטנית מייצרת סיכום אסטרטגיה ומווקטרת אותו מיד לאחר הרצה מוצלחת אחת. מימוש קפדני יותר משתמש תחילה במאמת תשובות של GAIA או במאמת סביבתי אחר כדי לתייג הרצות כמוצלחות, מוצלחות חלקית או נכשלות, ואז משווה מספר נתיבים בתוך אותה משפחת משימות. מסלולים מוצלחים תורמים אסטרטגיות מועמדות, כישלונות תורמים ידע שולל, והצלחות חלקיות חושפות איזה מקטע עבד ואיזה עדיין נכשל. הרפלקסיה בשפה טבעית שהוצעה ב‑Reflexion‏[^reflexion-2023] יכולה לסייע בייצור לקחים מועמדים, אך הרפלקסיה עצמה אינה ראיה. רק תוכן העקבי עם התוצאות הסביבתיות, הנתמך על פני מסלולים ומראה העברה חיובית במשימות חדשות, ראוי להיכנס למסמכי ניסיון פורמליים. -> **ניסוי 9‑2 ★★: זיקוק מסמכי ידע ניסיוני ממסלולי GAIA** -> -> **מטרה:** לבדוק האם מסמכי ידע חוצי‑מסלולים עוברים טוב יותר מסיכום של הצלחה בודדת ומפחיתים העברה שלילית מהצלחות מקריות ומניסיון שגוי. -> -> **נתונים ונוהל:** `gaia-experience` שומר תחילה את המסלול המלא ואת ה‑`environment_score` החיצוני עבור כל הרצה, ואז ממיר אותם לרשומות למידה מינימליות המכילות `task_family`, ‏`capabilities` נדרשות, ‏`applies_when`, אסטרטגיות שנצפו, שגיאות, חריגים ומזהי מסלול מקור. מאמת תוצאה מסווג הרצות כמוצלחות, מוצלחות חלקית או נכשלות. מודול הלמידה משווה נתיבים בתוך אותה משפחת משימות. ‏LLM רשאי להציע הכללות מועמדות, אך אסטרטגיה מומלצת חייבת להיתמך בשני מסלולים שאינם כושלים לכל הפחות. מסמך ה‑Markdown המתקבל כולל תרחישי תחולה, אסטרטגיות מומלצות, מכשולים נפוצים, חריגים, מקורות ומועד האימות האחרון. בעת היישום מאוחזרים רק מסמכים אלה; מסלולים גולמיים ארוכים אינם מוזרקים ישירות להקשר. -> -> **שלוש קבוצות ביקורת:** התנאי הראשון אינו משתמש בניסיון היסטורי כלל; השני מאחזר את סיכום המסלול היחיד הדומה ביותר למשימה הנוכחית; השלישי מאחזר מסמך ידע הנתמך במסלולים מרובים. מערכי הלמידה וההעברה חייבים להיות זרים זה לזה, כך שתשובות לאותה שאלת GAIA לא ידלפו להערכה בתור "ניסיון". -> -> **מדדים וקבלה:** דווחו על שיעור ההצלחה במשימות ההעברה, על ממוצע התווים או הטוקנים שאוחזרו ועל שיעור ההעברה השלילית, וּודאו שכל מסקנה פורמלית מצטטת את מסלולי המקור שלה. אם מסמכים חוצי‑מסלולים רק מקצרים את ההקשר מבלי לשפר ביצועים במשימות חדשות, אין הם מדגימים ניסיון נלמד. הניסוי נכשל גם אם הצלחה מקרית אחת יכולה להיות מקודמת ישירות לידע פורמלי או אם לא ניתן לעקוב ממסמך אל מסלוליו המקוריים. -> -> המימוש הנלווה זמין בכתובת [`gaia-experience`](../chapter9/gaia-experience/). ‏`demo_documents.py` רץ במצב לא‑מקוון כברירת מחדל; עם `--extractor llm` יכול LLM אמיתי להציע מועמדי ניסיון חוצי‑מסלולים. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ למידת Prompt מערכתי אינה אותו דבר כמו הנדסת ה‑Prompt של פרק 2. פרק 2 עסק בשאלה כיצד לארגן Prompt טוב; הסעיף הזה עוסק בשאלה איזו משוב מספיק כדי להצדיק שינוי, וכיצד משחררים הצעת עדכון בבטחה. השינוי צריך להיות diff מינימלי עם מקור, ולא כתיבה מחדש של כל ה‑Prompt בכל סבב — זו בדיוק תבנית "diff מינימלי + ניתן לחזרה" שקיבלה את שמה בפרק 1. את הגרסה המועמדת חובה לבדוק בו־זמנית על **מערך הגבול שהפעיל את הכשל** ועל **מערך שימור שכבר עובד**: הראשון חייב להשתפר, השני אינו רשאי להידרדר. -#### דוגמה 1: אופטימיזציית כללים ב‑Prompt מתוך מסלולי כישלון +#### דוגמה 1: הפיכת גבול ההסלמה לכללים + +במדיניות תחום ה‑telecom של τ²-bench, ההעברה לנציג אנושי מוסדרת בשני משפטי עיקרון בלבד: העבר רק כאשר הבקשה חורגת מטווח הפעולה של ה‑Agent, ולפני ההעברה עשה כמיטב יכולתך לפתור. כאשר פרק 7 ניתח את הסביבה הזו, שתי השורות לא הסגירו כל פגם; הריצו את אותה סביבה עם מודל חלש יותר, והחיסרון צף מיד — לאחר שכלי מחזיר שגיאה ה‑Agent מנסה שוב ושוב, ולבסוף חותם את העניין בהעברה לאדם. כך הסתיימו 19 מתוך 20 המשימות שבמערך ההפקה. -פרק 7 השתמש ב‑τ-bench/τ²-bench כדי להסביר כיצד מעריכים סוכן שירות לקוחות של חברת תעופה: המשתמש חושף את דרישותיו בהדרגה, והמערכת בודקת גם את מצב הסביבה, כגון ההזמנה, וגם אם המידע הנחוץ נמסר בשיחה. ייחוס הכשלים באותו פרק גם הדגיש שאין להסתפק ברישום "כישלון", אלא יש לאתר את **הצעד השגוי הראשון**. +מסרו את 19 המסלולים הכושלים האלה למודל, והניחו לו להסיק בעצמו כמה כללים בני ביצוע שיצורפו לסוף המדיניות; לאחר מכן הריצו מחדש על מערך משימות שלא נטל כל חלק בהפקה. שיעור המעבר עולה מ‑12.3% ל‑19.3%, ואף לא משימה אחת שעברה קודם נשברת. -המקרה הבעייתי כאן הוא זה: המשתמש אינו מרוצה מהחזר, מדמי שינוי או ממדיניות הכבודה, והסוכן קורא ל‑`transfer_to_human` בלי לבדוק את המדיניות, בלי להסביר את הכלל ובלי לחפש חלופה מותרת. מחלוקת מדיניות רגילה אינה מחייבת העברה; **העברה מתחייבת רק כאשר המשתמש מבקש במפורש נציג אנושי או כאשר עולה סיכון בטיחותי או סיכון לגוף**. לפיכך הבעיה אינה ש"הסוכן אינו מנומס דיו", אלא שה‑Prompt לא כתב עד הסוף את גבול ההעברה. +**מה שמראים למפיק קובע מה הוא מסוגל להסיק.** מאותם 19 מסלולים, אספקת תקצירי הכישלון וטקסטי השגיאה בלבד מניבה "אל תמשיך לקרוא לכלי שמחזיר שוב ושוב את אותה שגיאה"; הוספת רשימת הכלים שברשות ה‑Agent ואלה שברשות המשתמש משנה את התוצאה ל"בדיקת מצב הרשת, כרטיס ה‑SIM וה‑APN שייכת למכשיר המשתמש, ויש להנחות את המשתמש לבצעה בעצמו במקום לקרוא לה ישירות". הראשונה מתעדת לקח, השנייה מבינה היכן נמצאת האחריות. + +**המודל מתייחס להתנהגות הנצפית כאל ההתנהגות הראויה.** שניים מכללי הגרסה הראשונה גרסו "לאחר שלוש קריאות כושלות ברצף העבר לאדם" ו"אם המשתמש לא מסר מספר לאחר שתי בקשות העבר לאדם" — מה שמופיע במסלולים בתדירות הגבוהה ביותר הוא בדיוק ההעברה לאדם, ולכן ראה בה המודל מוצא אחרון סביר. אלא שבמערך ההערכה הזה העברה לאדם נחשבת בהכרח לכישלון, ושני הכללים הללו כותבים את הכישלון לתוך התקנון עצמו. משום כך אין לשחרר את תוצר ההפקה ישירות; עליו לעבור אימות בלתי תלוי במה שהוליד אותו. + +**מה שמתוקן הוא לרוב דבר פשוט להפליא.** בזרוע הבסיס יש מסלול אופייני: ה‑Agent זקוק למספר הטלפון של המשתמש, ולכן קורא לכלי החיפוש כשבפרמטר כתוב "אנא מסור את מספר הטלפון שלך" — חמש פעמים ברצף, חמש שגיאות, ואז העברה. הוא כבר הסיק שעליו לשאול את המשתמש; אלא שאת המשפט הזה הפנה אל הכלי. משנכנסו הכללים לתוקף, הוא מבקש תחילה בתוך השיחה, מקבל את המספר ורק אז מבצע את החיפוש; בהמשך, כאשר שכבת הכלים דוחה את ניסיונו לבדוק את מצב כרטיס ה‑SIM, הוא עובר להנחות את המשתמש להוציא ולהכניס מחדש את הכרטיס, והמשימה עוברת. + +> **ניסוי 9‑2 ★★: הפקת כללי הסלמה ושימוש בכלים ממסלולים כושלים של τ²-bench** +> +> נעשה שימוש חוזר בסביבת τ²-bench telecom מפרק 7. מערך ההפקה ומערך ההעברה הם ממילא שני מערכי משימות זרים זה לזה במאגר המקור, ולכן תהליך ההפקה אינו נוגע כלל במערך ההעברה. +> +> תחילה הריצו את מערך ההפקה במודל חלש ושמרו את המסלולים הכושלים; את הכללים יסיק מודל ולא אדם, ולאחר יצירתם יצורפו לסוף המדיניות המקורית; לאחר מכן השוו על מערך ההעברה את המדיניות המקורית לשתי הגרסאות שהתפתחו. בין שלוש הזרועות מוחלף רק קובץ המדיניות, וסימולטור המשתמש נשמר קבוע. +> +> מלבד שיעור המעבר יש לתעד שלושה מדדי התנהגות התואמים ישירות לכללים: שיעור ההעברות לאדם, מספר הפעמים שה‑Agent חורג מסמכותו וקורא לכלי בצד המשתמש, ומספר הקריאות שנשלחו בלי פרמטר נדרש. שני המדדים האחרונים יורדים בגרסאות שהתפתחו בכ‑80%, מה שמראה שהעלייה בשיעור המעבר נובעת מכך שהכללים תיקנו פעולות קונקרטיות. -האבחנה הזו הופכת ישירות לכלל אחד בתוך ה‑Prompt: תחילה לאתר את המדיניות ולהסביר אותה, לזהות את המטרה שהמשתמש באמת רוצה להשיג ולהציע חלופה תואמת נהלים; להעביר רק כאשר מתבקש במפורש נציג אנושי, או כאשר הבקשה חורגת מהסמכות או נוגעת לבטיחות. +אותה גישה ניתנת להעברה לתחומים אחרים. מקרה כשל אופייני עבור Agent שירות לקוחות של חברת תעופה הוא זה: המשתמש מלין על דמי ביטול, דמי שינוי או מדיניות כבודה, וה‑Agent קורא ל‑`transfer_to_human` בלי לבדוק את המדיניות, בלי להסביר את הכלל ובלי לחפש חלופה תואמת. מחלוקת מדיניות רגילה אינה מצריכה העברה; **רק בקשה מפורשת לנציג אנושי, או מצב הכרוך בבטיחות, הופכים את ההעברה למחויבת**. האבחנה מצביעה שוב על גבול הסלמה שמעולם לא נוסח במפורש, והתיקון הוא שוב להפוך אותו לכלל מינימלי יחיד עם מקור מתועד. > **ניסוי 9‑3 ★★: אופטימיזציה של Prompt מערכתי בשירות לקוחות תעופתי מתוך מסלולים כושלים** > diff --git a/book-hu/chapter9.md b/book-hu/chapter9.md index ca1a2a5db..3c6ec7046 100644 --- a/book-hu/chapter9.md +++ b/book-hu/chapter9.md @@ -83,18 +83,6 @@ Egy teljes tudásdesztillációs csővezeték öt lépésre bontható. Először A GAIA tapasztalati tanulása szemléletes példát nyújt. A GAIA[^gaia-2023] többlépéses problémákat tartalmaz, amelyek keresést, webes olvasást, fájlfeldolgozást és számítást kombinálnak, míg az AWorld[^aworld-2025] biztosítja a környezetet az ágensek futtatásához, az eszközök meghívásához és a trajektóriák rögzítéséhez: az előbbi olyan, mint a vizsga, az utóbbi a vizsgaterem és a laboratóriumi jegyzőkönyvi rendszer. Egy leegyszerűsítő megközelítés egy sikeres futtatás után azonnal generál egy stratégia-összefoglalót és vektorizálja. Egy szigorúbb implementáció először egy GAIA válasz-ellenőrzővel vagy más környezeti ellenőrzővel címkézi a futtatásokat sikeres, részben sikeres vagy sikertelen kategóriákba, majd összehasonlítja a több útvonalat ugyanazon feladatcsaládon belül. A sikeres trajektóriák jelölt stratégiákat szolgáltatnak, a sikertelenek kizárási tudást, a részben sikeresek pedig felfedik, mely szegmens működött és melyik bukott még meg. A Reflexion[^reflexion-2023] által javasolt természetes nyelvű reflexió segíthet a jelölt tanulságok generálásában, de maga a reflexió nem bizonyíték. Csak a környezeti eredményekkel konzisztens, trajektóriákon át alátámasztott és új feladatokon pozitív átvitelt mutató tartalom kerülhet a formális tapasztalati dokumentumokba. -> **9-2. ★★ kísérlet: Tapasztalati tudásdokumentumok desztillálása GAIA trajektóriákból** -> -> **Cél:** Annak tesztelése, hogy a trajektóriákon átívelő tudásdokumentumok jobban átvihetők-e, mint egyetlen siker összefoglalása, és csökkentik-e a véletlen sikerekből és hibás tapasztalatokból származó negatív transzfert. -> -> **Adatok és eljárás:** A `gaia-experience` először minden futtatáshoz eltárolja a teljes trajektóriát és a külső `environment_score` értéket, majd minimális tanulási rekordokká alakítja őket, amelyek tartalmazzák a `task_family`, a szükséges `capabilities`, az `applies_when`, a megfigyelt stratégiák, a hibák, a kivételek és a forrás trajektória-azonosítók adatait. Egy eredmény-ellenőrző sikeres, részben sikeres vagy sikertelen kategóriákba sorolja a futtatásokat. A tanulási modul összehasonlítja az útvonalakat ugyanazon feladatcsaládon belül. Egy LLM javasolhat jelölt általánosításokat, de egy ajánlott stratégiát legalább két nem sikertelen trajektóriának kell alátámasztania. Az eredményül kapott Markdown dokumentum tartalmazza az alkalmazható forgatókönyveket, az ajánlott stratégiákat, a gyakori buktatókat, a kivételeket, a származást és a legutóbbi érvényesítési időpontot. Alkalmazáskor csak ezek a dokumentumok kerülnek lekérésre; a hosszú nyers trajektóriák nem kerülnek közvetlenül a kontextusba. -> -> **Három kontroll:** Az első feltétel nem használ történeti tapasztalatot; a második az aktuális feladathoz legjobban hasonlító egyetlen trajektória-összefoglalást kérdezi le; a harmadik egy több trajektória által alátámasztott tudásdokumentumot kérdez le. A tanulási és átviteli készleteknek diszjunktaknak kell lenniük, hogy ugyanazon GAIA kérdésre adott válaszok ne szivárogjanak be „tapasztalatként" a kiértékelésbe. -> -> **Mérőszámok és elfogadás:** Jelentsük az átviteli feladatok sikerarányát, az átlagosan lekérdezett karakterek vagy tokenek számát, a negatív transzfer arányát, és ellenőrizzük, hogy minden formális következtetés hivatkozik a forrás trajektóriáira. Ha a trajektóriákon átívelő dokumentumok csak a kontextust rövidítik anélkül, hogy javítanák az új feladatok teljesítményét, nem bizonyítanak tanult tapasztalatot. A kísérlet akkor is sikertelen, ha egyetlen véletlen siker közvetlenül formális tudássá léptethető elő, vagy ha egy dokumentum nem vezethető vissza az eredeti trajektóriáihoz. -> -> A mellékelt implementáció a [`gaia-experience`](../chapter9/gaia-experience/) címen érhető el. A `demo_documents.py` alapértelmezésben offline fut; a `--extractor llm` kapcsolóval egy valódi LLM javasolhat trajektóriákon átívelő tapasztalati jelölteket. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy ezt a gyakorlatot **rendszerprompt-tanulásnak** (System Prompt A rendszerprompt-tanulás nem ugyanaz, mint a 2. fejezet promptmérnöksége. A 2. fejezet arról szólt, hogyan építsünk fel egy jó Promptot; ez a szakasz arról, milyen visszajelzés elég egy módosítás kiváltásához, és hogyan lehet a frissítési javaslatot biztonságosan kiadni. A módosítás legyen forrással ellátott minimális diff, ne pedig a Prompt teljes újraírása minden menetben – pontosan ez az 1. fejezetben elnevezett „minimális diff + visszaállíthatóság” minta. A jelölt változatot egyszerre kell tesztelni a **hibát kiváltó határhalmazon** és a **már működő megtartó halmazon**: az elsőnek javulnia kell, a másodiknak nem szabad romlania. -#### 1. példa: Szabályok optimálása a promptban a hiba trajektóriák alapján +#### 1. példa: az átadási határ szabályba öntése + +A τ²-bench telecom házirendjében az emberi ügyintézőnek való átadásról mindössze két elvi mondat rendelkezik: csak akkor adj át, ha a kérés meghaladja az Agent cselekvési körét, és az átadás előtt tégy meg mindent a megoldásért. A 7. fejezet boncolásakor ez a két sor nem árult el hibát; futtassuk ugyanazt a környezetet egy gyengébb modellel, és a hiányosság azonnal felszínre kerül — miután az eszköz hibát ad vissza, az Agent újra meg újra próbálkozik, végül emberi átadással zárja le a dolgot. A levezetési halmaz 20 feladatából 19 így ért véget. -A 7. fejezet a τ-bench/τ²-bench segítségével mutatta be, hogyan értékelünk egy légitársasági ügyfélszolgálati Agentet: a felhasználó lépésenként fedi fel az igényeit, a rendszer pedig egyszerre ellenőrzi a környezet állapotát (például a foglalást) és azt, hogy a párbeszédben elhangzott-e a szükséges információ. Ugyanannak a fejezetnek a hibaattribúciója azt is hangsúlyozta, hogy nem elég a „kudarcot” rögzíteni: meg kell találni az **első hibás lépést**. +Adjuk át ezt a 19 sikertelen trajectoryt egy modellnek, hagyjuk, hogy maga vezessen le néhány végrehajtható szabályt, és fűzzük azokat a házirend végére; azután futtassuk újra egy olyan feladathalmazon, amely a levezetésben nem vett részt. A sikerarány 12,3%-ról 19,3%-ra nő, és egyetlen korábban sikeres feladat sem romlik el. -A példa rossz esete a következő: a felhasználó elégedetlen a visszatérítéssel, az átfoglalási díjjal vagy a poggyászszabállyal, az Agent pedig meghívja a `transfer_to_human` függvényt anélkül, hogy utánanézne a szabálynak, elmagyarázná azt, vagy megengedett alternatívát keresne. A hétköznapi szabályvita nem igényel átadást; **átadás csak akkor kötelező, ha a felhasználó kifejezetten emberi ügyintézőt kér, vagy biztonsági, illetve személyi kockázat merül fel**. A gond tehát nem az, hogy „az Agent nem elég udvarias”, hanem az, hogy a Prompt nem írta le az átadás határát. +**Az dönti el, mit lehet levezetni, hogy mit mutatunk meg a levezetőnek.** Ugyanabból a 19 trajectoryból pusztán a hibaösszefoglalók és a hibaszövegek átadása azt hozza ki, hogy „ne hívj tovább olyan eszközt, amely újra és újra ugyanazt a hibát adja vissza”; ha kiegészítjük azzal, hogy az Agent és a felhasználó külön-külön mely eszközöket hívhatja, az eredmény erre változik: „a hálózati állapot, a SIM-kártya és az APN ellenőrzése a felhasználó készülékéhez tartozik, ezért nem közvetlenül kell hívni, hanem a felhasználót kell végigvezetni rajta”. Az első egy tanulságot rögzít, a második a felelősség helyét érti meg. + +**A modell a megfigyelt viselkedést a helyénvaló viselkedésnek veszi.** Az első változat szabályai közül kettő így szólt: „három egymást követő sikertelen hívás után add át embernek”, illetve „ha a felhasználó két kérés után sem adja meg a számot, add át embernek”. A trajectorykban éppen az emberi átadás jelenik meg a leggyakrabban, így a modell ésszerű végső megoldásnak vette. Ebben a kiértékelésben azonban az emberi átadás szükségszerűen kudarcnak minősül, vagyis ez a két szabály magába a szabályzatba írja bele a kudarcot. A levezetés terméke ezért nem adható ki közvetlenül: olyan ellenőrzésen kell átmennie, amely független attól, ami létrehozta. + +**Amit megjavítunk, gyakran rendkívül egyszerű hiba.** Az alapvonalon van egy jellegzetes trajectory: az Agentnek szüksége van a felhasználó telefonszámára, ezért meghívja a lekérdező eszközt, a paraméterbe pedig azt írja, hogy „Kérem, adja meg a telefonszámát” — ötször egymás után, öt hiba, majd átadás. Már kikövetkeztette, hogy a felhasználót kell megkérdeznie; csak éppen ezt a mondatot az eszköznek címezte. A szabályok életbe lépése után előbb a beszélgetésben kéri el a számot, megkapja, és csak azután kérdez le; később, amikor a SIM-kártya állapotának ellenőrzését az eszközréteg elutasítja, átvált arra, hogy a felhasználót vezesse végig a SIM-kártya újbóli behelyezésén, és a feladat sikerül. + +> **9-2. ★★ kísérlet: Átadási és eszközhasználati szabályok levezetése τ²-bench sikertelen trajectoryjaiból** +> +> A 7. fejezet τ²-bench telecom környezetét használjuk újra. A levezetési és az átviteli halmaz eleve két diszjunkt feladathalmaz a felsőbb tárolóban, így a levezetés folyamata soha nem érinti az átviteli halmazt. +> +> Először futtassuk a levezetési halmazt egy gyenge modellel, és őrizzük meg a sikertelen trajectorykat; a szabályokat ne ember írja, hanem modell vezesse le, és a létrejött szabályok az eredeti házirend végére kerüljenek; azután az átviteli halmazon vessük össze az eredeti házirendet a két kifejlődött változattal. A három kar között csak a házirendfájl cserélődik, a felhasználószimulátor változatlan marad. +> +> A sikerarányon kívül három, a szabályoknak közvetlenül megfelelő viselkedési mutatót kell rögzíteni: az emberi átadások arányát, azoknak az eseteknek a számát, amikor az Agent túllépi hatáskörét és felhasználóoldali eszközt hív, valamint a kötelező paraméter nélkül kiadott hívások számát. Az utóbbi kettő a kifejlődött változatokban nagyjából 80%-kal esik vissza, ami azt mutatja, hogy a sikerarány javulását a szabályok konkrét cselekvéseket javító hatása adja. -Ez a diagnózis közvetlenül egyetlen prompt-szabállyá alakul: előbb kérdezd le és magyarázd el a szabályt, ismerd fel, milyen célt akar a felhasználó valójában elérni, és kínálj szabálykövető alternatívát; átadni csak akkor szabad, ha kifejezetten embert kérnek, vagy ha a kérés meghaladja a jogosultságot, illetve biztonságot érint. +Ugyanez az eljárás más területekre is átvihető. Egy légitársasági ügyfélszolgálati Agent jellegzetes hibaesete a következő: a felhasználó kifogásolja a visszatérítési díjat, az átfoglalási díjat vagy a poggyászszabályzatot, az Agent pedig anélkül hívja meg a `transfer_to_human` függvényt, hogy utánanézne a szabályzatnak, elmagyarázná a szabályt vagy megengedett alternatívát keresne. Egy szokványos szabályzati vita nem igényel átadást; **kizárólag az teszi kötelezővé, ha a felhasználó kifejezetten embert kér, vagy ha biztonsággal összefüggő helyzet áll elő**. A diagnózis ismét egy soha ki nem mondott átadási határra mutat, a javítás pedig ismét abból áll, hogy ezt egyetlen, forrással ellátott minimális szabállyá tesszük. > **9-3. ★★ kísérlet: Légitársasági ügyfélszolgálati rendszer-Prompt optimalizálása sikertelen trajektóriákból** > diff --git a/book-id/chapter9.md b/book-id/chapter9.md index a110b90cb..96ad99446 100644 --- a/book-id/chapter9.md +++ b/book-id/chapter9.md @@ -83,19 +83,6 @@ Sebuah pipeline penyulingan pengetahuan (knowledge-distillation pipeline) yang l Pembelajaran pengalaman GAIA memberikan contoh intuitif. GAIA[^gaia-2023] berisi masalah multi-langkah yang menggabungkan pencarian, pembacaan web, pemrosesan file, dan komputasi, sementara AWorld[^aworld-2025] menyediakan lingkungan untuk menjalankan Agent, memanggil tool tersebut, dan merekam lintasan: yang pertama seperti ujian, dan yang terakhir adalah ruang ujian dan sistem catatan laboratorium. Pendekatan yang terlalu sederhana (simplistic) menghasilkan ringkasan strategi dan segera memvektorisasinya setelah satu operasi sukses (successful run). Implementasi yang lebih ketat (stricter implementation) pertama-tama menggunakan pemverifikasi jawaban GAIA atau pemverifikasi lingkungan lainnya untuk memberi label run sebagai sukses, sebagian sukses, atau gagal, dan kemudian membandingkan beberapa jalur di dalam kelompok tugas yang sama. Lintasan sukses menyumbangkan strategi kandidat, kegagalan menyumbangkan pengetahuan pengecualian (exclusionary knowledge), dan kesuksesan sebagian mengungkapkan segmen mana yang berhasil dan mana yang masih gagal. Refleksi bahasa alami yang diajukan oleh Reflexion[^reflexion-2023] dapat membantu menghasilkan pelajaran kandidat, tetapi refleksi itu sendiri bukanlah bukti. Hanya konten yang konsisten dengan hasil lingkungan, didukung di seluruh lintasan, dan menunjukkan transfer positif pada tugas-tugas baru yang harus dimasukkan ke dalam dokumen pengalaman formal. -> **Eksperimen 9-2 ★★: Menyaring Dokumen Pengetahuan Pengalaman dari Lintasan GAIA** -> -> **Tujuan:** Menguji apakah dokumen pengetahuan lintas-lintasan (cross-trajectory) ditransfer lebih baik daripada ringkasan satu keberhasilan dan mengurangi transfer negatif dari kesuksesan yang tak disengaja dan pengalaman yang salah. -> -> **Data dan prosedur:** `gaia-experience` pertama-tama menyimpan lintasan penuh (full trajectory) dan `environment_score` eksternal untuk setiap run, lalu mengubahnya menjadi rekaman pembelajaran minimal yang mengandung `task_family`, `capabilities` yang diperlukan, `applies_when`, strategi yang diamati, kesalahan, pengecualian, dan ID lintasan sumber (source trajectory IDs). Verifikator hasil (outcome verifier) mengklasifikasikan run sebagai sukses, sebagian sukses, atau gagal. Modul pembelajaran membandingkan jalur dalam kelompok tugas yang sama. Sebuah LLM mungkin mengusulkan kandidat generalisasi, tetapi strategi yang direkomendasikan harus didukung oleh setidaknya dua lintasan yang tidak gagal. Dokumen Markdown yang dihasilkan mencakup skenario yang berlaku, strategi yang direkomendasikan, kesalahan umum (common pitfalls), pengecualian, asal-usul (provenance), dan waktu validasi terbaru. Selama penerapan (application), hanya dokumen ini yang diambil (retrieved); lintasan mentah yang panjang tidak dimasukkan langsung ke dalam konteks. - -> -> **Tiga kontrol (Three controls):** Kondisi pertama tidak menggunakan pengalaman historis; yang kedua mengambil satu ringkasan trajektori (trajectory summary) yang paling mirip dengan tugas saat ini; yang ketiga mengambil dokumen pengetahuan (knowledge document) yang didukung oleh beberapa trajektori. Set pembelajaran (learning set) dan transfer (transfer set) harus terpisah sehingga jawaban atas pertanyaan GAIA yang sama tidak bocor ke dalam evaluasi sebagai "pengalaman." -> -> **Metrik dan penerimaan (Metrics and acceptance):** Laporkan tingkat keberhasilan transfer tugas (transfer-task success rate), rata-rata karakter atau Tokens yang diambil, dan tingkat transfer negatif (negative-transfer rate), serta verifikasi bahwa setiap kesimpulan formal mengutip sumber trajektorinya. Jika dokumen lintas-trajektori (cross-trajectory) hanya menyingkat konteks tanpa meningkatkan kinerja tugas baru, itu tidak menunjukkan pengalaman yang dipelajari. Eksperimen ini juga gagal jika satu keberhasilan kebetulan dapat secara langsung dipromosikan menjadi pengetahuan formal atau jika sebuah dokumen tidak dapat ditelusuri ke trajektori aslinya. -> -> Implementasi yang menyertainya tersedia di [`gaia-experience`](../chapter9/gaia-experience/). `demo_documents.py` berjalan secara offline secara default; dengan `--extractor llm`, sebuah LLM nyata dapat mengusulkan kandidat pengalaman lintas-trajektori. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -110,13 +97,27 @@ Andrej Karpathy menyebut praktik ini **system prompt learning**[^karpathy-system System prompt learning bukan hal yang sama dengan prompt engineering di Bab 2. Bab 2 membahas cara menyusun Prompt yang baik; bagian ini membahas umpan balik seperti apa yang cukup untuk memicu perubahan, dan bagaimana usulan pembaruan dirilis dengan aman. Perubahan haruslah diff minimal yang menyertakan asal-usulnya, bukan menyuruh model menulis ulang seluruh Prompt setiap kali—inilah pola "diff minimal + dapat di-rollback" yang dinamai di Bab 1. Versi kandidat wajib diuji sekaligus pada **himpunan batas yang memicu kegagalan** dan pada **himpunan retensi yang sudah berjalan benar**: yang pertama harus membaik, yang kedua tidak boleh memburuk. -#### Contoh 1: Mengoptimalkan Aturan dalam Prompt Berdasarkan Lintasan Kegagalan +#### Contoh 1: Membakukan batas eskalasi menjadi aturan -Bab 7 memakai τ-bench/τ²-bench untuk menjelaskan cara mengevaluasi Agent layanan pelanggan maskapai: pengguna menyingkap kebutuhannya setahap demi setahap, dan sistem memeriksa baik keadaan lingkungan seperti data pemesanan maupun apakah informasi yang diperlukan sudah diberikan di dalam percakapan. Atribusi kegagalan pada bab itu juga menekankan bahwa mencatat "gagal" saja tidak cukup; yang harus ditemukan adalah **langkah keliru yang pertama**. +Dalam kebijakan telecom pada τ²-bench, pengalihan ke petugas manusia hanya diatur oleh dua kalimat prinsip: alihkan hanya bila permintaan melampaui lingkup tindakan Agent, dan sebelum mengalihkan berupayalah sekuat tenaga menyelesaikannya. Ketika Bab 7 membedah lingkungan ini, kedua baris itu tidak menunjukkan masalah; jalankan lingkungan yang sama dengan model yang lebih lemah, dan kelemahannya langsung tersingkap — setelah tool mengembalikan galat, Agent mencoba lagi berulang kali dan akhirnya menutup perkara dengan mengalihkan ke manusia. Begitulah 19 dari 20 tugas pada himpunan penurunan berakhir. -Kasus bermasalah pada contoh ini: pengguna tidak puas terhadap pengembalian dana, biaya perubahan jadwal, atau kebijakan bagasi, lalu Agent memanggil `transfer_to_human` tanpa memeriksa kebijakan, tanpa menjelaskan aturan, dan tanpa mencari alternatif yang diizinkan. Perselisihan kebijakan biasa tidak memerlukan pengalihan; **pengalihan baru wajib ketika pengguna secara eksplisit meminta manusia atau muncul risiko keselamatan/keselamatan jiwa**. Jadi masalahnya bukan "Agent kurang sopan", melainkan Prompt tidak pernah menuliskan batas pengalihan dengan jelas. +Serahkan 19 trajectory gagal itu kepada sebuah model, biarkan ia sendiri menurunkan beberapa aturan yang dapat dijalankan, lalu tambahkan ke akhir kebijakan; kemudian jalankan ulang pada himpunan tugas yang sama sekali tidak terlibat dalam penurunan. Tingkat lulus naik dari 12,3% menjadi 19,3%, dan tak satu pun tugas yang semula lulus menjadi rusak. + +**Apa yang diperlihatkan kepada penurun menentukan apa yang dapat ia simpulkan.** Dari 19 trajectory yang sama, memberikan hanya ringkasan kegagalan dan teks galat menghasilkan "jangan terus memanggil tool yang berulang kali mengembalikan galat yang sama"; menambahkan daftar tool yang dapat dipanggil Agent dan yang dapat dipanggil pengguna mengubah hasilnya menjadi "pemeriksaan status jaringan, kartu SIM, dan APN adalah milik perangkat pengguna, sehingga harus dituntunkan kepada pengguna, bukan dipanggil langsung". Yang pertama mencatat pelajaran, yang kedua memahami di mana letak tanggung jawab. + +**Model memperlakukan perilaku yang teramati sebagai perilaku yang semestinya.** Dua di antara aturan versi pertama berbunyi "setelah tiga panggilan gagal berturut-turut, alihkan ke manusia" dan "jika pengguna tidak memberikan nomor setelah dua kali diminta, alihkan ke manusia" — yang paling sering muncul dalam trajectory memang pengalihan ke manusia, sehingga model menganggapnya jalan terakhir yang masuk akal. Padahal dalam evaluasi ini pengalihan ke manusia pasti dinilai gagal, jadi kedua aturan itu sama saja dengan menuliskan kegagalan ke dalam ketentuan. Karena itu hasil penurunan tidak boleh langsung dirilis; ia harus melewati verifikasi yang independen dari apa pun yang menghasilkannya. + +**Yang diperbaiki kerap kali hal yang teramat sederhana.** Pada lengan dasar ada satu trajectory yang khas: Agent memerlukan nomor telepon pengguna, lalu memanggil tool pencarian dengan parameter diisi "Mohon berikan nomor telepon Anda" — lima kali berturut-turut, lima kali galat, kemudian pengalihan. Ia sudah menyimpulkan bahwa ia harus bertanya kepada pengguna; hanya saja kalimat itu ditujukannya kepada tool. Setelah aturan berlaku, ia lebih dahulu mengajukan permintaan di dalam percakapan, memperoleh nomornya, baru kemudian melakukan pencarian; belakangan, ketika upayanya memeriksa status kartu SIM ditolak di lapisan tool, ia beralih menuntun pengguna memasang ulang kartu SIM, dan tugas pun lulus. + +> **Eksperimen 9-2 ★★: Menurunkan aturan eskalasi dan penggunaan tool dari trajectory gagal τ²-bench** +> +> Gunakan kembali lingkungan τ²-bench telecom dari Bab 7. Himpunan penurunan dan himpunan transfer memang sudah merupakan dua himpunan tugas yang saling lepas di repositori hulu, sehingga proses penurunan tidak pernah menyentuh himpunan transfer. +> +> Pertama jalankan himpunan penurunan dengan model lemah dan simpan trajectory yang gagal; aturan diturunkan oleh model, bukan ditulis manusia, dan setelah dihasilkan ditambahkan ke akhir kebijakan asli; kemudian pada himpunan transfer bandingkan kebijakan asli dengan dua versi hasil evolusi. Di antara ketiga lengan hanya berkas kebijakan yang diganti; simulator pengguna dijaga tetap. +> +> Selain tingkat lulus, perlu dicatat tiga indikator perilaku yang berpadanan langsung dengan aturan: proporsi pengalihan ke manusia, jumlah kali Agent melampaui wewenang dan memanggil tool sisi pengguna, serta jumlah panggilan yang dikirim tanpa parameter wajib. Kedua indikator terakhir turun sekitar 80% pada versi hasil evolusi, yang menunjukkan bahwa kenaikan tingkat lulus berasal dari aturan yang memperbaiki tindakan-tindakan konkret. -Diagnosis ini langsung berubah menjadi satu aturan dalam prompt: periksa dan jelaskan dulu kebijakannya, kenali tujuan yang sebenarnya ingin diselesaikan pengguna, lalu tawarkan alternatif yang sesuai ketentuan; alihkan hanya bila manusia diminta secara eksplisit, atau bila permintaan melampaui wewenang/menyangkut keselamatan. +Cara yang sama dapat dipindahkan ke ranah lain. Kasus bermasalah yang khas pada Agent layanan pelanggan maskapai adalah ini: pengguna mempersoalkan biaya pengembalian, biaya perubahan, atau ketentuan bagasi, sementara Agent memanggil `transfer_to_human` tanpa menelusuri kebijakan, tanpa menjelaskan ketentuan, dan tanpa mencari alternatif yang sesuai aturan. Perselisihan kebijakan biasa tidak memerlukan pengalihan; **hanya permintaan eksplisit akan petugas manusia, atau situasi yang menyangkut keselamatan, yang membuat pengalihan menjadi wajib**. Diagnosisnya kembali menunjuk pada batas eskalasi yang tak pernah dituliskan dengan jelas, dan perbaikannya kembali berupa mengubahnya menjadi satu aturan minimal yang bersumber jelas. > **Eksperimen 9-3 ★★: Mengoptimalkan Prompt sistem layanan pelanggan maskapai dari trajektori gagal** > diff --git a/book-ja/chapter9.ja.md b/book-ja/chapter9.ja.md index aca8a0f4e..3d9a7a688 100644 --- a/book-ja/chapter9.ja.md +++ b/book-ja/chapter9.ja.md @@ -83,18 +83,6 @@ GAIA の経験学習は直感的な例である。GAIA[^gaia-2023] は、検索、Webページの読解、ファイル処理、計算を組み合わせる必要がある多段階問題を収録する。一方、AWorld[^aworld-2025] は Agent を実行し、それらのツールを呼び出し、軌跡を保存する実行環境を提供する。前者が試験問題なら、後者は試験会場と実験記録システムに相当する。従来の方法は、タスクが一度成功するとすぐに戦略要約を生成し、ベクトル化してライブラリへ保存していた。より厳密な実装では、まず GAIA の正解検証または別の環境検証器によって成功、部分的成功、失敗を付与し、その後、同じタスク群の複数経路を比較する。成功軌跡は戦略候補を、失敗軌跡は排除的知識を提供し、部分的成功の軌跡は「どの部分が有効で、どの部分にまだ問題があるか」を識別する助けとなる。Reflexion[^reflexion-2023] が提案した自然言語による反省は教訓候補の生成に利用できるが、反省自体は証拠ではない。環境結果と一致し、軌跡横断的な支持を得て、新規タスクで正の転移を示した内容だけを正式な経験文書に組み込むべきである。 -> **実験 9-2 ★★：GAIA 軌跡から経験知識文書を抽出する** -> -> **実験目標**：「複数軌跡から作った知識文書」が「一度の成功を要約して記憶する方法」より転移しやすく、偶発的成功や誤った経験による負の転移を抑えられるかを検証する。 -> -> **データと手順**：`gaia-experience` は各実行の完全な軌跡と外部の `environment_score` を保存し、それを `task_family`、必要な `capabilities`、`applies_when`、観察された戦略、誤り、例外、出典軌跡 ID からなる最小の学習記録へ変換する。結果検証器は実行を成功、部分的成功、失敗に分類する。学習モジュールは同じタスク群の経路を比較する。LLM は帰納候補を提案できるが、推奨戦略には少なくとも2本の非失敗軌跡による支持が必要である。最終的な Markdown 文書には、適用場面、推奨戦略、一般的な誤り、例外条件、出典、直近の検証時刻を含める。適用時にはこれらの文書だけを検索し、長大な生の軌跡を直接コンテキストへ入れない。 -> -> **3つの対照群**：第1群は過去の経験を使わない。第2群は現在のタスクに最も似た単一軌跡の要約を検索する。第3群は複数軌跡に共同で支持された知識文書を検索する。学習セットと転移セットは重複させず、同じ GAIA 問題の答えが「経験」として評価へ漏れるのを防ぐ。 -> -> **指標と受け入れ基準**：転移タスクの成功率、平均検索文字数または Token 数、負の転移率を同時に報告し、各正式結論に出典軌跡が列挙されているかを確認する。複数軌跡の文書がコンテキストを短くしただけで新規タスクの性能を高めていなければ、経験を学習した証明にはならない。一度の偶発的成功を正式知識へ昇格できる場合や、文書を原軌跡まで追跡できない場合も不合格とする。 -> -> 関連実装は [`gaia-experience`](../chapter9/gaia-experience/) を参照されたい。`demo_documents.py` はデフォルトでオフライン実行され、`--extractor llm` を指定すると、実際の LLM が軌跡横断的な経験候補を提案できる。 - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy はこのやり方を**システムプロンプト学習**（Sys システムプロンプト学習は、第 2 章のプロンプトエンジニアリングとは別物です。第 2 章は良い Prompt をどう組み立てるかを論じました。本節が論じるのは、どのようなフィードバックがあれば修正を発動してよいのか、そして更新提案をどう安全にリリースするかです。修正は出所つきの最小 diff であるべきで、毎回モデルに Prompt 全体を書き直させるものではありません——これこそ第 1 章で名づけた「最小 diff ＋ ロールバック可能」のパターンです。検証待ちの版は、**失敗を引き起こした境界集合**と**正常に動いている保持集合**の双方で必ずテストします。前者は改善しなければならず、後者は劣化してはなりません。 -#### 例1：失敗軌跡に基づくプロンプト内のルール最適化 +#### 例1：転送境界のルール化 + +τ²-bench の telecom ポリシーにおいて、有人への転送について定められているのは二つの原則的な記述だけである。すなわち、要求が Agent の動作範囲を超える場合にのみ転送すること、転送の前にまず全力で解決を試みること。第 7 章でこの環境を解剖した際、この二行は問題を露呈しなかった。ところが能力の劣るモデルで走らせると欠陥はただちに表面化する——ツールがエラーを返すと Agent は繰り返し再試行し、最後は有人転送で幕を引く。抽出用タスク 20 件のうち 19 件がこの終わり方であった。 -第 7 章では τ-bench／τ²-bench を用いて、航空会社のカスタマーサービス Agent の評価方法を説明しました。ユーザーが要求を少しずつ明かし、システムは予約などの環境状態も、会話の中で必要な情報が示されたかどうかも検査します。同章の失敗帰属はさらに、「失敗した」と記録するだけでは足りず、**最初の誤ったステップ**を突き止めなければならないと強調しました。 +この 19 件の失敗トラジェクトリをモデルに渡し、実行可能なルールをいくつか自ら帰納させてポリシー末尾に追記する。そのうえで抽出に一切関与していないタスク群で再実行すると、通過率は 12.3% から 19.3% へ上がり、もともと通過していたタスクは一つも壊れなかった。 -本例の問題ケースはこうです。払い戻し、変更手数料、手荷物規定にユーザーが不満を述べたとき、Agent は規定を調べもせず、ルールを説明もせず、許容される代替案を探しもせずに `transfer_to_human` を呼び出してしまいます。通常の規定に関する争いに転送は不要です。**明確に人間を求められたとき、または安全・人身のリスクが生じたときにのみ転送が必要**なのです。したがって問題は「Agent の礼儀が足りない」ことではなく、Prompt が転送の境界を書き切っていないことにあります。 +**抽出器に何を見せるかが、何を帰納できるかを決める。** 同じ 19 件のトラジェクトリでも、失敗要約とエラーテキストだけを与えた場合に得られるのは「同じツールが繰り返しエラーを返すなら呼び続けるな」である。Agent とユーザーそれぞれが呼べるツールの一覧を補って与えると、帰納結果は「ネットワーク状態、SIM カード、APN などの確認はユーザー端末側に属し、直接呼ぶのではなくユーザーを誘導して実行させるべきである」に変わる。前者は教訓の記録であり、後者は責任の所在の理解である。 + +**モデルは観察された振る舞いを、あるべき振る舞いとして扱う。** 第一版のルールには「連続三回の呼び出し失敗で有人転送」「ユーザーが二度番号を出さなければ有人転送」の二条があった。トラジェクトリに最も頻繁に現れるのが有人転送であるため、モデルはそれを妥当な最終手段と見なしたのである。しかしこの評価では有人転送は必ず失敗と判定される。この二条は失敗を規範に書き込んだに等しい。ゆえに抽出物をそのまま公開してはならず、抽出したものとは独立した検証を経る必要がある。 + +**修復されるのは、きわめて素朴な欠陥であることが多い。** ベースラインに典型的なトラジェクトリがある。Agent はユーザーの電話番号を必要とし、照会ツールを呼び出すのだが、パラメータに「お電話番号をお知らせください」と書き込んでいた。五回続けて、五回ともエラー、そして有人転送。ユーザーに尋ねるべきだとすでに判断していながら、その一文をツールに向けて言っていたのである。ルールが効いたのちは、まず対話の中で依頼し、番号を得てから照会する。その後 SIM カード状態の確認をツール層に拒否されると、ユーザーを誘導して SIM カードを挿し直させる方に切り替え、タスクは通過した。 + +> **実験 9-2 ★★：τ²-bench の失敗トラジェクトリから転送とツール利用のルールを抽出する** +> +> 第 7 章の τ²-bench telecom 環境をそのまま用いる。抽出用セットと移行用セットは上流リポジトリにおいてもともと互いに素な二組であり、抽出の過程が移行用セットに触れることはない。 +> +> まず弱いモデルで抽出用セットを走らせ、失敗トラジェクトリを保存する。ルールは人手ではなくモデルに帰納させ、生成後に元のポリシー末尾へ追記する。そのうえで移行用セットにおいて、元の戦略と二つの進化版とを対照する。三つのアーム間で差し替えるのはポリシーファイルのみで、ユーザーシミュレータは固定したままとする。 +> +> 通過率のほかに、ルールと直接対応する三つの行動指標を記録する必要がある。有人転送の割合、Agent が越権してユーザー側ツールを呼んだ回数、パラメータを欠いたまま発せられた呼び出しの回数である。後の二つは進化版でいずれもおよそ八割低下しており、通過率の向上がルールによる具体的な動作の修復に由来することを示している。 -この診断はそのままプロンプト中の一条のルールになります。まず規定を照会して説明し、ユーザーが本当に解決したい目標を見極め、規程に沿った代替案を提示する。転送するのは、明確に人間を求められたとき、あるいは権限を超えるか安全に関わるときだけにする、というものです。 +同じやり方は他の領域にも移せる。航空カスタマーサービス Agent の典型的な問題事例はこうである。ユーザーが払い戻し手数料、変更手数料、あるいは手荷物規定に異議を唱えると、Agent はポリシーを照会せず、規則を説明せず、規定に沿った代替案も探さないまま `transfer_to_human` を呼ぶ。通常の規定上の争いに転送は要らない。**ユーザーが明示的に有人対応を求めた場合、または安全に関わる事態が生じた場合にのみ、転送は必須となる**。診断はやはり転送境界が明確化されていない点を指し、修正はやはりそれを出典付きの最小のルールへ落とし込むことである。 > **実験 9-3 ★★：失敗軌跡に基づいて航空カスタマーサービスのシステム Prompt を最適化する** > diff --git a/book-ko/chapter9.ko.md b/book-ko/chapter9.ko.md index 57059d6b5..8ff64a29d 100644 --- a/book-ko/chapter9.ko.md +++ b/book-ko/chapter9.ko.md @@ -83,18 +83,6 @@ GAIA 경험 학습은 직관적인 사례를 제공합니다. GAIA[^gaia-2023]에는 검색, 웹 읽기, 파일 처리, 계산을 결합한 다단계 문제가 있고, AWorld[^aworld-2025]는 에이전트를 실행하고 이러한 도구를 호출하고 궤적을 기록하는 환경을 제공합니다. 전자가 시험이라면 후자는 시험장과 실험 기록 시스템입니다. 단순한 방법은 한 번의 성공적인 실행 뒤에 전략 요약을 만들고 즉시 벡터화합니다. 더 엄격한 구현은 먼저 GAIA 정답 검증기나 다른 환경 검증기로 실행을 성공, 부분 성공, 실패로 라벨링한 다음 같은 업무군 안의 여러 경로를 비교합니다. 성공 궤적은 후보 전략을, 실패 궤적은 배제 지식을 제공하며 부분 성공은 어느 구간이 작동했고 어느 구간이 여전히 실패했는지 보여 줍니다. Reflexion[^reflexion-2023]이 제안한 자연어 성찰은 후보 교훈을 만드는 데 도움이 되지만 성찰 자체는 증거가 아닙니다. 환경 결과와 일치하고 여러 궤적에서 뒷받침되며 새로운 업무에 긍정적으로 전이되는 내용만 정식 경험 문서에 들어가야 합니다. -> **실험 9-2 ★★: GAIA 궤적에서 경험 지식 문서 증류** -> -> **목표:** 여러 궤적에 기반한 지식 문서가 하나의 성공 사례 요약보다 더 잘 전이되는지, 우연한 성공과 잘못된 경험이 일으키는 부정적 전이를 줄이는지 시험합니다. -> -> **데이터와 절차:** `gaia-experience`는 먼저 각 실행의 전체 궤적과 외부 `environment_score`를 저장한 다음, 이를 `task_family`, 필요한 `capabilities`, `applies_when`, 관찰된 전략, 오류, 예외, 출처 궤적 ID를 담은 최소 학습 기록으로 변환합니다. 결과 검증기는 실행을 성공, 부분 성공, 실패로 분류합니다. 학습 모듈은 같은 업무군 안의 경로를 비교합니다. LLM이 후보 일반화를 제안할 수 있지만 권장 전략은 실패하지 않은 궤적 두 개 이상에서 뒷받침되어야 합니다. 생성된 Markdown 문서에는 적용 가능한 상황, 권장 전략, 흔한 함정, 예외, 출처, 마지막 검증 시각이 들어갑니다. 적용할 때는 이 문서만 검색하고 긴 원시 궤적을 컨텍스트에 직접 넣지 않습니다. -> -> **세 가지 대조 조건:** 첫 번째 조건은 과거 경험을 사용하지 않습니다. 두 번째는 현재 업무와 가장 비슷한 단일 궤적 요약을 검색합니다. 세 번째는 여러 궤적이 뒷받침하는 지식 문서를 검색합니다. 같은 GAIA 문제의 답이 ‘경험’이라는 이름으로 평가에 유출되지 않도록 학습 집합과 전이 집합은 겹치지 않아야 합니다. -> -> **지표와 통과 기준:** 전이 업무 성공률, 검색한 평균 문자 수 또는 토큰 수, 부정적 전이율을 보고하고 모든 정식 결론이 출처 궤적을 인용하는지 확인합니다. 여러 궤적 기반 문서가 컨텍스트만 줄이고 새 업무의 성능은 높이지 못한다면 경험을 학습했다고 볼 수 없습니다. 한 번의 우연한 성공이 바로 정식 지식으로 승격될 수 있거나 문서를 원래 궤적으로 추적할 수 없어도 실험은 실패입니다. -> -> 부록 구현은 [`gaia-experience`](../chapter9/gaia-experience/)에서 확인할 수 있습니다. `demo_documents.py`는 기본적으로 오프라인에서 실행되며, `--extractor llm`을 사용하면 실제 LLM이 여러 궤적에 기반한 경험 후보를 제안할 수 있습니다. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy는 이런 방식을 **시스템 프롬프트 학습**(System Pro 시스템 프롬프트 학습은 2장의 프롬프트 엔지니어링과 같은 것이 아닙니다. 2장은 좋은 Prompt를 어떻게 구성하는지를 다뤘고, 이 절은 어떤 피드백이 있어야 수정을 촉발할 수 있는지, 그리고 업데이트 제안을 어떻게 안전하게 배포하는지를 다룹니다. 수정은 출처가 붙은 최소 diff여야 하며, 매번 모델이 Prompt 전체를 다시 쓰게 하는 것이 아닙니다. 이것이 바로 1장에서 이름 붙인 ‘최소 diff + 롤백 가능’ 패턴입니다. 검증 대기 버전은 **실패를 촉발한 경계 집합**과 **정상 작동 중인 보존 집합** 양쪽에서 반드시 테스트해야 하며, 앞쪽은 개선되어야 하고 뒤쪽은 퇴행해서는 안 됩니다. -#### 예시 1: 실패 궤적 기반 프롬프트 내 규칙 최적화 +#### 예시 1: 이관 경계의 규칙화 + +τ²-bench의 telecom 정책에서 상담원 이관에 관해 규정된 것은 두 문장의 원칙뿐이다. 요청이 Agent의 행동 범위를 벗어날 때만 이관하고, 이관 전에 먼저 최선을 다해 해결하라는 것이다. 제7장에서 이 환경을 해부할 때 이 두 줄은 아무 문제도 드러내지 않았다. 그러나 능력이 떨어지는 모델로 실행하면 결함은 곧바로 표면화된다. 도구가 오류를 반환하면 Agent는 반복해서 재시도하고 결국 상담원 이관으로 마무리하는데, 추출용 20개 과제 가운데 19개가 이렇게 끝났다. -7장에서는 τ-bench/τ²-bench로 항공사 고객 서비스 에이전트의 평가 방식을 설명했습니다. 사용자가 요구를 조금씩 드러내면, 시스템은 예약 같은 환경 상태도 검사하고 대화에서 필요한 정보가 제시되었는지도 검사합니다. 그 장의 실패 귀인은 또한 “실패”라고만 기록해서는 안 되며 **첫 번째 오류 단계**를 찾아내야 한다고 강조했습니다. +이 19개의 실패 궤적을 모델에 넘겨 실행 가능한 규칙 몇 조항을 스스로 귀납하게 하고, 그것을 정책 말미에 덧붙인다. 그런 다음 추출에 전혀 관여하지 않은 과제군에서 다시 실행하면, 통과율은 12.3%에서 19.3%로 오르고 원래 통과하던 과제는 하나도 망가지지 않는다. -이 예의 문제 사례는 이렇습니다. 사용자가 환불, 변경 수수료, 수하물 정책에 불만을 제기했을 때 에이전트가 정책을 조회하지도, 규칙을 설명하지도, 허용되는 대안을 찾아보지도 않고 `transfer_to_human`을 호출해 버립니다. 일반적인 정책 분쟁에는 이관이 필요하지 않습니다. **사용자가 명시적으로 상담원을 요구하거나 안전·신변 위험이 발생했을 때에만 이관이 필요합니다.** 따라서 문제는 “에이전트가 충분히 공손하지 않다”가 아니라 Prompt가 이관의 경계를 분명히 적어 두지 않았다는 데 있습니다. +**추출기에 무엇을 보여 주는가가 무엇을 귀납할 수 있는가를 결정한다.** 같은 19개의 궤적이라도 실패 요약과 오류 텍스트만 제공하면 얻어지는 것은 "같은 도구가 반복해서 오류를 반환하면 계속 호출하지 말라"이다. Agent와 사용자가 각각 호출할 수 있는 도구 목록을 함께 주면 귀납 결과는 "네트워크 상태, SIM 카드, APN 등의 확인은 사용자 기기 쪽에 속하므로 직접 호출하지 말고 사용자가 직접 수행하도록 안내해야 한다"로 바뀐다. 앞의 것은 교훈의 기록이고, 뒤의 것은 책임 소재의 이해다. + +**모델은 관찰된 행동을 마땅히 그래야 할 행동으로 받아들인다.** 첫 번째 판본의 규칙에는 "연속 세 번 호출에 실패하면 상담원에게 이관", "사용자가 두 번 번호를 주지 않으면 상담원에게 이관"이라는 두 조항이 있었다. 궤적에 가장 자주 등장하는 것이 바로 상담원 이관이었으므로 모델은 그것을 합당한 최후 수단으로 간주한 것이다. 그러나 이 평가에서 상담원 이관은 반드시 실패로 판정된다. 이 두 조항은 실패를 규범에 써 넣은 셈이다. 따라서 추출된 산물은 곧바로 배포할 수 없으며, 추출한 쪽과 독립된 검증을 거쳐야 한다. + +**수리되는 것은 지극히 소박한 결함인 경우가 많다.** 기준선에 전형적인 궤적이 하나 있다. Agent가 사용자의 전화번호를 필요로 하여 조회 도구를 호출하는데, 매개변수에 "전화번호를 알려 주십시오"를 채워 넣었다. 다섯 번 연속, 다섯 번 모두 오류, 그리고 상담원 이관. 사용자에게 물어야 한다는 것을 이미 판단해 놓고도 그 문장을 도구에게 말한 것이다. 규칙이 적용된 뒤에는 먼저 대화 안에서 요청하고, 번호를 받은 다음 조회했다. 이후 SIM 카드 상태 확인이 도구 계층에서 거부되자 사용자가 직접 SIM 카드를 뺐다 끼우도록 안내하는 쪽으로 바꾸었고, 과제는 통과했다. + +> **실험 9-2 ★★: τ²-bench 실패 궤적에서 이관·도구 사용 규칙 도출하기** +> +> 제7장의 τ²-bench telecom 환경을 그대로 사용한다. 추출용 세트와 이전용 세트는 상류 저장소에서 애초에 서로 겹치지 않는 두 벌이므로, 추출 과정이 이전용 세트에 닿는 일은 없다. +> +> 먼저 약한 모델로 추출용 세트를 실행해 실패 궤적을 저장한다. 규칙은 사람이 쓰지 않고 모델이 귀납하게 하며, 생성 후 원래 정책 말미에 덧붙인다. 그런 다음 이전용 세트에서 원래 정책과 두 진화 판본을 대조한다. 세 팔 사이에서 교체하는 것은 정책 파일뿐이고 사용자 시뮬레이터는 고정한다. +> +> 통과율 외에 규칙과 직접 대응하는 세 가지 행동 지표를 기록해야 한다. 상담원 이관 비율, Agent가 월권하여 사용자 쪽 도구를 호출한 횟수, 매개변수가 빠진 채 발신된 호출 횟수다. 뒤의 두 항목은 진화 판본에서 모두 약 80% 감소했는데, 이는 통과율 상승이 규칙이 구체적 동작을 고친 데서 왔음을 보여 준다. -이 진단은 곧바로 프롬프트의 규칙 한 줄이 됩니다. 먼저 정책을 조회해 설명하고, 사용자가 실제로 해결하려는 목표를 파악하며, 규정에 맞는 대안을 제시한다. 이관은 명시적으로 상담원을 요구받았을 때, 또는 권한을 벗어나거나 안전과 관련될 때에만 한다. +같은 방식은 다른 영역으로도 옮길 수 있다. 항공 고객 서비스 Agent의 전형적인 문제 사례는 이렇다. 사용자가 환불 수수료, 변경 수수료, 수하물 규정에 이의를 제기하면 Agent는 정책을 조회하지도, 규칙을 설명하지도, 규정에 맞는 대안을 찾지도 않은 채 `transfer_to_human`을 호출한다. 통상적인 정책 분쟁에는 이관이 필요 없다. **사용자가 명시적으로 상담원을 요구하거나 안전과 관련된 상황이 발생한 경우에만 이관이 반드시 필요하다**. 진단은 여전히 이관 경계가 명확히 규정되지 않았다는 점을 가리키고, 수정은 여전히 그것을 출처가 붙은 최소 규칙으로 떨어뜨리는 일이다. > **실험 9-3 ★★: 실패 궤적으로 항공 고객 서비스 시스템 Prompt 최적화하기** > diff --git a/book-ru/chapter9.md b/book-ru/chapter9.md index 495dbfd6f..344b2652f 100644 --- a/book-ru/chapter9.md +++ b/book-ru/chapter9.md @@ -83,18 +83,6 @@ Обучение на опыте GAIA служит наглядным примером. GAIA[^gaia-2023] содержит многоэтапные вопросы, требующие сочетания поиска, чтения веб-страниц, обработки файлов и вычислений, а AWorld[^aworld-2025] предоставляет среду для запуска Agent, вызова этих инструментов и сохранения траекторий. Первое можно сравнить с экзаменационным листом, второе — с экзаменационной аудиторией и системой записи эксперимента. В прежнем подходе после единственного успеха немедленно создавалось краткое описание стратегии, которое векторизовалось и сохранялось. Более строгая реализация сначала отмечает успех, частичный успех и неудачу посредством проверки ответов GAIA или другого проверяющего среды, а затем сопоставляет несколько путей в одном семействе задач. Успешные траектории дают потенциальные стратегии, неуспешные — исключающие знания, а частично успешные помогают понять, «какая часть сработала, а какая всё ещё проблемна». Предложенная в Reflexion[^reflexion-2023] рефлексия на естественном языке может участвовать в создании потенциальных уроков, однако сама по себе она не является свидетельством. В формальный документ опыта следует включать лишь материалы, согласующиеся с результатами среды, поддерживаемые несколькими траекториями и демонстрирующие положительный перенос на новые задачи. -> **Эксперимент 9-2 ★★: извлечение документов знаний об опыте из траекторий GAIA** -> -> **Цель эксперимента**: проверить, лучше ли «документ знаний по нескольким траекториям» переносится, чем «запомненное резюме одного успеха», и снижает ли он отрицательный перенос от случайных успехов и ошибочного опыта. -> -> **Данные и процедура**: `gaia-experience` сначала сохраняет полную траекторию и внешний `environment_score` каждого выполнения, а затем преобразует их в минимальную обучающую запись: `task_family`, требуемые `capabilities`, `applies_when`, наблюдаемая стратегия, ошибки, исключения и ID исходных траекторий. Проверяющий результата делит выполнения на успешные, частично успешные и неуспешные. Обучающий модуль сопоставляет пути одного семейства задач; LLM может предлагать потенциальные обобщения, но рекомендуемая стратегия должна быть подтверждена как минимум двумя не завершившимися неудачей траекториями. Итоговый документ Markdown содержит область применимости, рекомендуемую стратегию, распространённые ошибки, условия исключений, источники и время последней проверки. На этапе применения извлекаются только эти документы, без помещения длинных исходных траекторий непосредственно в контекст. -> -> **Три группы сравнения**: первая не использует прошлый опыт; вторая извлекает резюме одной траектории, наиболее похожей на текущую задачу; третья извлекает документ знаний, совместно подтверждённый несколькими траекториями. Обучающий набор не должен пересекаться с набором переноса, чтобы ответ на ту же задачу GAIA не просочился в оценку под видом «опыта». -> -> **Метрики и приёмка**: одновременно сообщаются доля успешных задач переноса, среднее число извлечённых символов или Token и доля отрицательного переноса; для каждого формального вывода проверяется наличие списка исходных траекторий. Если документ по нескольким траекториям лишь сокращает контекст, но не улучшает новые задачи, это не доказывает обучение на опыте. Если единичный случайный успех можно повысить до формального знания или документ нельзя проследить до исходных траекторий, эксперимент также не проходит приёмку. -> -> Сопутствующая реализация находится в [`gaia-experience`](../chapter9/gaia-experience/). `demo_documents.py` по умолчанию работает офлайн, а параметр `--extractor llm` позволяет настоящей LLM предлагать кандидатов опыта, обобщающих несколько траекторий. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Обучение системного промпта — не то же самое, что инженерия промптов из главы 2. Глава 2 обсуждала, как собрать хороший Prompt; этот раздел обсуждает, какой обратной связи достаточно, чтобы запустить правку, и как безопасно выпускать предложение об обновлении. Правка должна быть минимальным diff с указанием источника, а не полным переписыванием Prompt при каждом проходе — это и есть названный в главе 1 паттерн «минимальный diff плюс откат». Кандидатную версию обязательно тестируют одновременно на **граничном наборе, вызвавшем сбой**, и на **удерживающем наборе, который уже работает**: первый должен улучшиться, второй не должен деградировать. -#### Пример 1: Оптимизация правил в промпте на основе траекторий ошибок +#### Пример 1: превращение границы эскалации в правила + +В политике домена telecom из τ²-bench о передаче оператору сказано лишь двумя принципиальными фразами: передавать только тогда, когда запрос выходит за пределы действий Agent, и до передачи приложить все усилия к решению. Когда в главе 7 эта среда разбиралась по частям, обе строки не обнаруживали изъяна; запустите ту же среду на модели послабее — и недостаток проявляется сразу: после ошибки инструмента Agent раз за разом повторяет вызов и в итоге передаёт диалог оператору. Именно так завершились 19 из 20 задач набора для извлечения. -В главе 7 на примере τ-bench/τ²-bench было показано, как оценивают агента службы поддержки авиакомпании: пользователь раскрывает требования постепенно, а система проверяет и состояние среды (например, бронирование), и то, прозвучала ли в диалоге необходимая информация. Атрибуция сбоев в той же главе подчёркивала: недостаточно записать «неудача», нужно найти **первый ошибочный шаг**. +Передадим эти 19 неудачных траекторий модели, позволим ей самой вывести несколько исполнимых правил и допишем их в конец политики; затем перезапустим на наборе задач, не участвовавших в извлечении. Доля прохождения растёт с 12,3% до 19,3%, и ни одна из ранее проходивших задач не сломана. -Проблемный случай здесь такой: пользователь недоволен возвратом, сбором за обмен или правилами провоза багажа, а агент вызывает `transfer_to_human`, не заглянув в правила, не объяснив их и не поискав допустимую альтернативу. Обычный спор о правилах не требует перевода; **перевод обязателен лишь тогда, когда пользователь явно просит оператора или возникает угроза безопасности или здоровью**. Значит, проблема не в том, что «агент недостаточно вежлив», а в том, что Prompt не прописал границу перевода. +**То, что показано извлекающей модели, определяет, что она способна вывести.** Из тех же 19 траекторий при подаче одних лишь сводок отказов и текстов ошибок получается «не продолжай вызывать инструмент, который раз за разом возвращает одну и ту же ошибку»; после добавления перечня инструментов, доступных Agent и пользователю по отдельности, результат меняется на «проверка состояния сети, SIM-карты и APN относится к устройству пользователя и должна выполняться пользователем под руководством, а не вызываться напрямую». Первое фиксирует урок, второе схватывает распределение ответственности. + +**Модель принимает наблюдаемое поведение за должное.** Два правила первой версии гласили: «после трёх неудачных вызовов подряд передать оператору» и «если пользователь дважды не сообщил номер, передать оператору». Чаще всего в траекториях встречается именно передача оператору, и модель сочла её разумным запасным ходом. Но в этой системе оценки передача оператору неизбежно засчитывается как неудача, так что эти два правила вписывают неудачу в сам регламент. Поэтому продукт извлечения нельзя выпускать напрямую: он должен пройти проверку, независимую от того, что его породило. + +**Чинится, как правило, нечто предельно простое.** В базовом плече есть характерная траектория: Agent нуждается в номере телефона пользователя и вызывает инструмент поиска, подставив в параметр «Пожалуйста, сообщите ваш номер телефона» — пять раз подряд, пять ошибок, затем передача оператору. Он уже сообразил, что спросить нужно у пользователя, но адресовал эту фразу инструменту. После вступления правил в силу он сначала обращается с просьбой в диалоге, получает номер и лишь затем выполняет запрос; позже, когда попытка проверить состояние SIM-карты отклоняется на уровне инструментов, он переходит к тому, чтобы провести пользователя через переустановку SIM-карты, и задача проходит. + +> **Эксперимент 9-2 ★★: извлечение правил эскалации и работы с инструментами из неудачных траекторий τ²-bench** +> +> Используется среда τ²-bench telecom из главы 7. Набор для извлечения и набор для переноса изначально представляют собой два непересекающихся набора задач в исходном репозитории, поэтому процесс извлечения не соприкасается с набором для переноса. +> +> Сначала прогоните набор для извлечения слабой моделью и сохраните неудачные траектории; правила выводит модель, а не человек, и после порождения они дописываются в конец исходной политики; затем на наборе для переноса сопоставьте исходную политику с двумя эволюционировавшими версиями. Между тремя плечами заменяется только файл политики, симулятор пользователя остаётся неизменным. +> +> Помимо доли прохождения нужно фиксировать три поведенческих показателя, прямо соответствующих правилам: долю передач оператору, число случаев, когда Agent выходит за свои пределы и вызывает инструмент пользовательской стороны, и число вызовов, отправленных без обязательного параметра. Оба последних показателя падают в эволюционировавших версиях примерно на 80%, что показывает: прирост доли прохождения даёт починка конкретных действий правилами. -Этот диагноз прямо превращается в одно правило внутри промпта: сначала запросить и разъяснить правила, определить, какую цель пользователь на самом деле хочет достичь, и предложить допустимую альтернативу; переводить — только при явной просьбе об операторе либо при выходе за пределы полномочий или при вопросах безопасности. +Тот же приём переносится и на другие предметные области. Характерный проблемный случай для Agent авиационной поддержки таков: пользователь возражает против сбора за возврат, сбора за обмен или правил провоза багажа, а Agent вызывает `transfer_to_human`, не заглянув в правила, не объяснив их и не поискав допустимой альтернативы. Обычный спор о правилах не требует передачи; **обязательной она становится лишь при явной просьбе о человеке или в ситуации, связанной с безопасностью**. Диагноз снова указывает на границу эскалации, которая так и не была прописана, а исправление снова состоит в том, чтобы превратить её в одно минимальное правило с указанием источника. > **Эксперимент 9-3 ★★: оптимизация системного Prompt авиационной поддержки по неудачным траекториям** > diff --git a/book-ta/chapter9.ta.md b/book-ta/chapter9.ta.md index 7739e7f7d..ad855ed52 100644 --- a/book-ta/chapter9.ta.md +++ b/book-ta/chapter9.ta.md @@ -83,18 +83,6 @@ Learning signal Agent மாற வேண்டும் என்பதைச GAIA அனுபவக் கற்றல் இதற்கான நேரடியான எடுத்துக்காட்டை வழங்குகிறது. GAIA[^gaia-2023] தேடல், web page வாசிப்பு, file processing மற்றும் கணக்கீட்டை ஒருங்கிணைக்க வேண்டிய பல்படி கேள்விகளைக் கொண்டது; AWorld[^aworld-2025] Agent-ஐ இயக்கவும், இந்த tools-ஐ அழைக்கவும், trajectory-களைச் சேமிக்கவும் தேவையான execution environment-ஐ வழங்குகிறது. முன்னது தேர்வுத்தாள் போன்றது; பின்னது தேர்வறையும் பரிசோதனைப் பதிவு அமைப்பும் போன்றது. பழைய முறை ஒரு பணி வெற்றியடைந்த உடனே strategy summary உருவாக்கி, vectorize செய்து library-இல் சேர்க்கும். கடுமையான implementation முதலில் GAIA answer checker அல்லது வேறு environment verifier மூலம் வெற்றி, பகுதி வெற்றி, தோல்வி என label செய்து, பின்னர் ஒரே task family-இன் பல பாதைகளை ஒப்பிடும். வெற்றி trajectory candidate strategy-ஐ வழங்கும்; தோல்வி trajectory exclusion knowledge-ஐ வழங்கும்; பகுதி வெற்றி “எந்தப் பகுதி வேலை செய்தது, எது இன்னும் சிக்கலாக உள்ளது” என்பதை அடையாளம் காண உதவும். Reflexion[^reflexion-2023] முன்வைத்த natural-language reflection candidate lesson-களை உருவாக்கலாம்; ஆனால் reflection தானாகவே சான்றல்ல. Environment result-உடன் பொருந்தி, பல trajectory-களின் ஆதரவைப் பெற்று, புதிய பணிகளில் positive transfer-ஐக் காட்டும் உள்ளடக்கம் மட்டுமே முறையான அனுபவ ஆவணத்தில் சேர வேண்டும். -> **பரிசோதனை 9-2 ★★: GAIA trajectory-களிலிருந்து அனுபவ அறிவு ஆவணங்களைப் பிரித்தெடுத்தல்** -> -> **பரிசோதனை இலக்கு**: “பல trajectory-களிலிருந்து உருவான knowledge document”, “ஒரே வெற்றியின் summary-ஐ நினைவில் வைத்தல்” என்பதைக் காட்டிலும் சிறப்பாக transfer ஆகிறதா; மேலும் தற்செயலான வெற்றி மற்றும் தவறான அனுபவத்தால் ஏற்படும் negative transfer-ஐக் குறைக்கிறதா எனச் சோதித்தல். -> -> **தரவும் செயல்முறையும்**: `gaia-experience` முதலில் ஒவ்வொரு run-இன் முழு trajectory மற்றும் வெளிப்புற `environment_score`-ஐச் சேமித்து, பின்னர் அவற்றை `task_family`, தேவையான `capabilities`, `applies_when`, காணப்பட்ட strategy, error, exception மற்றும் source trajectory ID கொண்ட minimal learning record-ஆக மாற்றுகிறது. Result verifier run-ஐ வெற்றி, பகுதி வெற்றி அல்லது தோல்வி எனப் பிரிக்கிறது. Learning module ஒரே task family-இன் பாதைகளை ஒப்பிடுகிறது. LLM candidate generalization-ஐ முன்வைக்கலாம்; ஆனால் ஒரு recommended strategy குறைந்தபட்சம் இரண்டு தோல்வியல்லாத trajectory-களின் ஆதரவைப் பெற வேண்டும். இறுதி Markdown ஆவணத்தில் applicable context, recommended strategy, common mistake, exception condition, source மற்றும் last-verified time இடம்பெறும். Application கட்டத்தில் இவ்வாவணங்கள் மட்டுமே retrieval செய்யப்பட வேண்டும்; நீண்ட மூல trajectory நேரடியாக context-இல் வைக்கப்படக்கூடாது. -> -> **மூன்று ஒப்பீட்டுக் குழுக்கள்**: முதல் குழு வரலாற்று அனுபவத்தைப் பயன்படுத்தாது; இரண்டாவது தற்போதைய பணிக்கு மிகவும் ஒத்த ஒரே trajectory summary-ஐ retrieval செய்கிறது; மூன்றாவது பல trajectory-கள் இணைந்து ஆதரிக்கும் knowledge document-ஐ retrieval செய்கிறது. ஒரே GAIA கேள்வியின் பதில் “அனுபவம்” என்ற பெயரில் evaluation-க்கு கசியாதபடி learning set மற்றும் transfer set ஒன்றுடன் ஒன்று overlap ஆகக்கூடாது. -> -> **Metrics மற்றும் acceptance**: transfer task success rate, சராசரி retrieval character அல்லது Token எண்ணிக்கை, negative-transfer rate ஆகியவை ஒன்றாக அறிக்கையிடப்பட வேண்டும்; ஒவ்வொரு formal conclusion-உம் source trajectory-ஐப் பட்டியலிடுகிறதா எனச் சோதிக்க வேண்டும். Cross-trajectory document context-ஐச் சுருக்கினாலும் புதிய task performance-ஐ மேம்படுத்தவில்லை என்றால், அமைப்பு அனுபவத்திலிருந்து கற்றது என நிரூபிக்க முடியாது. ஒரே தற்செயலான வெற்றி formal knowledge-ஆக உயர்த்தப்படுமானாலும், ஆவணத்தை மூல trajectory வரை trace செய்ய முடியாவிட்டாலும் acceptance தோல்வியடையும். -> -> தொடர்புடைய implementation [`gaia-experience`](../chapter9/gaia-experience/) இல் உள்ளது. `demo_documents.py` இயல்புநிலையில் offline-ஆக இயங்குகிறது; `--extractor llm` பயன்படுத்தினால் உண்மையான LLM பல trajectory-களைக் கடக்கும் அனுபவ candidate-களை முன்வைக்கலாம். - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy இந்த அணுகுமுறையை **சிஸ்ட சிஸ்டம் ப்ராம்ப்ட் கற்றல் என்பது இரண்டாம் அத்தியாயத்தின் prompt engineering அல்ல. இரண்டாம் அத்தியாயம் நல்ல Prompt-ஐ எப்படி ஒழுங்கமைப்பது என்பதை விவாதித்தது; இப்பகுதி விவாதிப்பது, எத்தகைய பின்னூட்டம் ஒரு திருத்தத்தைத் தூண்டப் போதுமானது என்பதையும், புதுப்பிப்பு முன்மொழிவை எப்படிப் பாதுகாப்பாக வெளியிடுவது என்பதையும். திருத்தம் என்பது மூலம் குறிக்கப்பட்ட குறைந்தபட்ச diff ஆக இருக்க வேண்டும்; ஒவ்வொரு முறையும் மாதிரியை Prompt முழுவதையும் மீண்டும் எழுதச் செய்வதல்ல—இதுவே முதல் அத்தியாயத்தில் பெயரிடப்பட்ட “குறைந்தபட்ச diff + பின்வாங்கக்கூடியது” வடிவம். சரிபார்ப்புக்குக் காத்திருக்கும் பதிப்பை, **தோல்வியைத் தூண்டிய எல்லைத் தொகுப்பிலும்** **சரியாக இயங்கும் தக்கவைப்புத் தொகுப்பிலும்** ஒருசேரச் சோதிக்க வேண்டும்: முன்னது மேம்பட வேண்டும், பின்னது சரியக் கூடாது. -#### எடுத்துக்காட்டு 1: தோல்வி trajectory-களின் அடிப்படையில் prompt விதியை உகந்ததாக்குதல் +#### எடுத்துக்காட்டு 1: மாற்றுதல் எல்லையை விதிகளாக்குதல் + +τ²-bench இன் telecom கொள்கையில், மனித முகவருக்கு மாற்றுவது குறித்து இரண்டே கொள்கை வாக்கியங்கள் மட்டுமே உள்ளன: கோரிக்கை ஏஜெண்டின் செயல் எல்லையைத் தாண்டினால் மட்டுமே மாற்றவும், மாற்றுவதற்கு முன் தீர்க்க முழு முயற்சி செய்யவும். ஏழாம் அத்தியாயம் இச்சூழலை ஆய்ந்தபோது இவ்விரு வரிகளும் எந்தக் குறையையும் காட்டவில்லை; அதே சூழலை திறன் குறைந்த மாதிரியில் இயக்கினால் குறை உடனே வெளிப்படுகிறது — கருவி பிழையைத் திருப்பியதும் ஏஜெண்ட் மீண்டும் மீண்டும் முயன்று, இறுதியில் மனித முகவருக்கு மாற்றி முடித்துக்கொள்கிறது. பிரித்தெடுப்புத் தொகுப்பின் 20 பணிகளில் 19 இவ்வாறே முடிந்தன. -ஏழாம் அத்தியாயம் τ-bench/τ²-bench மூலம் விமான வாடிக்கையாளர் சேவை ஏஜெண்டை மதிப்பிடும் முறையை விளக்கியது: பயனர் தேவைகளைப் படிப்படியாக வெளிப்படுத்துகிறார்; அமைப்போ முன்பதிவு போன்ற சூழல் நிலையையும், உரையாடலில் தேவையான தகவல் வழங்கப்பட்டதா என்பதையும் சரிபார்க்கிறது. அந்த அத்தியாயத்தின் தோல்விக் காரணக் கூறல், “தோல்வி” என்று பதிவு செய்வதோடு நிற்காமல் **முதல் தவறான படியை** கண்டறிய வேண்டும் என்றும் வலியுறுத்தியது. +இந்த 19 தோல்வித் தடங்களை ஒரு மாதிரியிடம் ஒப்படைத்து, செயற்படுத்தத்தக்க சில விதிகளைத் தானே தொகுத்துக் கொள்கையின் இறுதியில் சேர்க்கச் செய்யுங்கள்; பின்னர் பிரித்தெடுப்பில் சிறிதும் பங்கேற்காத பணித் தொகுப்பில் மீண்டும் இயக்குங்கள். தேர்ச்சி விகிதம் 12.3% இலிருந்து 19.3% ஆக உயர்கிறது; முன்பு தேர்ச்சி பெற்ற பணிகளில் ஒன்றுகூடச் சிதையவில்லை. -இந்த எடுத்துக்காட்டின் சிக்கல் நிகழ்வு இதுவே: பணம் திரும்பப் பெறுதல், மாற்றக் கட்டணம் அல்லது சாமான் கொள்கை குறித்துப் பயனர் அதிருப்தி தெரிவிக்கும்போது, ஏஜெண்ட் கொள்கையைப் பார்க்காமல், விதியை விளக்காமல், அனுமதிக்கப்பட்ட மாற்று வழியைத் தேடாமல் `transfer_to_human` ஐ அழைத்துவிடுகிறது. வழக்கமான கொள்கைத் தகராறுக்கு மாற்றம் தேவையில்லை; **பயனர் வெளிப்படையாக மனிதரைக் கோரும்போது, அல்லது பாதுகாப்பு/உயிர் ஆபத்து எழும்போது மட்டுமே மாற்றம் கட்டாயம்**. எனவே சிக்கல் “ஏஜெண்ட் போதிய பணிவு காட்டவில்லை” என்பதல்ல; Prompt மாற்றத்தின் எல்லையைத் தெளிவாக எழுதவில்லை என்பதே. +**பிரித்தெடுப்பானுக்கு எதைக் காட்டுகிறோம் என்பதே அது எதைத் தொகுக்க முடியும் என்பதைத் தீர்மானிக்கிறது.** அதே 19 தடங்களிலிருந்து, தோல்விச் சுருக்கங்களையும் பிழை உரைகளையும் மட்டும் தந்தால் கிடைப்பது "ஒரே பிழையை மீண்டும் மீண்டும் திருப்பும் கருவியைத் தொடர்ந்து அழைக்காதே"; ஏஜெண்டும் பயனரும் தனித்தனியே எந்தக் கருவிகளை அழைக்கலாம் என்ற பட்டியலைச் சேர்த்தால் முடிவு "வலைப்பின்னல் நிலை, SIM அட்டை, APN போன்றவற்றைச் சரிபார்ப்பது பயனரின் சாதனத்துக்கு உரியது; நேரடியாக அழைக்காமல் பயனரை வழிநடத்திச் செய்யவைக்க வேண்டும்" என மாறுகிறது. முதலாவது ஒரு பாடத்தைப் பதிவு செய்கிறது; இரண்டாவது பொறுப்பு எங்கு இருக்கிறது என்பதைப் புரிந்துகொள்கிறது. + +**கவனித்த நடத்தையையே இருக்க வேண்டிய நடத்தையாக மாதிரி எடுத்துக்கொள்கிறது.** முதல் பதிப்பு விதிகளில் இரண்டு இவ்வாறு இருந்தன: "தொடர்ச்சியாக மூன்று அழைப்புகள் தோல்வியுற்றால் மனித முகவருக்கு மாற்று", "இரு முறை கேட்டும் பயனர் எண்ணைத் தராவிட்டால் மனித முகவருக்கு மாற்று". தடங்களில் மிக அடிக்கடி தோன்றுவது மனித முகவருக்கு மாற்றுவதே; எனவே மாதிரி அதை நியாயமான இறுதி வழியாகக் கருதியது. ஆனால் இந்த மதிப்பீட்டில் மனித முகவருக்கு மாற்றுவது தவிர்க்கமுடியாமல் தோல்வியெனத் தீர்மானிக்கப்படுகிறது; எனவே இவ்விரு விதிகளும் தோல்வியையே விதிமுறையுள் எழுதிவைத்தன. ஆகவே பிரித்தெடுப்பின் விளைபொருளை நேரடியாக வெளியிடக் கூடாது; அதை உருவாக்கியதிலிருந்து தனித்த ஒரு சரிபார்ப்பைக் கடக்க வேண்டும். + +**சரிசெய்யப்படுவது பெரும்பாலும் மிக எளிமையான குறையே.** அடிப்படைக் கையில் ஒரு வழக்கமான தடம் உள்ளது: ஏஜெண்டுக்குப் பயனரின் தொலைபேசி எண் தேவைப்படுகிறது, எனவே வினவல் கருவியை அழைக்கிறது — ஆனால் அளபுருவில் "தயவுசெய்து உங்கள் தொலைபேசி எண்ணைத் தாருங்கள்" என்று நிரப்பியிருந்தது. தொடர்ந்து ஐந்து முறை, ஐந்து பிழைகள், பின் மாற்றுதல். பயனரிடம் கேட்க வேண்டும் என்பதை அது ஏற்கெனவே ஊகித்திருந்தது; அந்த வாக்கியத்தைக் கருவியிடம் சொல்லியது மட்டுமே தவறு. விதிகள் அமலுக்கு வந்த பிறகு, முதலில் உரையாடலில் கேட்டு எண்ணைப் பெற்றுப் பின்னரே வினவுகிறது; பின்னர் SIM அட்டை நிலையைச் சரிபார்க்கும் முயற்சி கருவி அடுக்கால் மறுக்கப்பட்டபோது, பயனரை SIM அட்டையை மீண்டும் பொருத்த வழிநடத்துவதற்கு மாறியது; பணி தேர்ச்சி பெற்றது. + +> **சோதனை 9-2 ★★: τ²-bench தோல்வித் தடங்களிலிருந்து மாற்றுதல் மற்றும் கருவிப் பயன்பாட்டு விதிகளைப் பிரித்தெடுத்தல்** +> +> ஏழாம் அத்தியாயத்தின் τ²-bench telecom சூழலை அப்படியே பயன்படுத்துங்கள். பிரித்தெடுப்புத் தொகுப்பும் இடமாற்றத் தொகுப்பும் மேலோட்டக் களஞ்சியத்திலேயே ஒன்றோடொன்று வெட்டாத இரு தொகுப்புகள்; எனவே பிரித்தெடுப்பு நிகழ்வு இடமாற்றத் தொகுப்பைத் தொடுவதே இல்லை. +> +> முதலில் பலவீனமான மாதிரியால் பிரித்தெடுப்புத் தொகுப்பை இயக்கித் தோல்வித் தடங்களைச் சேமியுங்கள்; விதிகளை மனிதர் எழுதாமல் மாதிரியே தொகுக்கட்டும், உருவான பின் மூலக் கொள்கையின் இறுதியில் சேர்க்கப்படட்டும்; பின்னர் இடமாற்றத் தொகுப்பில் மூலக் கொள்கையையும் இரு பரிணமித்த பதிப்புகளையும் ஒப்பிடுங்கள். மூன்று கைகளுக்கு இடையே கொள்கைக் கோப்பு மட்டுமே மாற்றப்படுகிறது; பயனர் உருவகப்படுத்தி மாறாமல் வைக்கப்படுகிறது. +> +> தேர்ச்சி விகிதத்தைத் தவிர, விதிகளுடன் நேரடியாகப் பொருந்தும் மூன்று நடத்தை அளவீடுகளையும் பதிவு செய்ய வேண்டும்: மனித முகவருக்கு மாற்றிய விகிதம், ஏஜெண்ட் தன் எல்லையைத் தாண்டிப் பயனர் பக்கக் கருவியை அழைத்த எண்ணிக்கை, தேவையான அளபுரு இல்லாமலேயே வெளியிடப்பட்ட அழைப்புகளின் எண்ணிக்கை. பிந்தைய இரண்டும் பரிணமித்த பதிப்புகளில் ஏறத்தாழ 80% குறைகின்றன; தேர்ச்சி விகித உயர்வு விதிகள் குறிப்பான செயல்களைச் சரிசெய்ததால் வந்தது என்பதை இது காட்டுகிறது. -இந்தக் கண்டறிதல் நேரடியாகவே prompt-இல் ஒரு விதியாக மாறும்: முதலில் கொள்கையை வினவி விளக்குங்கள்; பயனர் உண்மையில் தீர்க்க விரும்பும் இலக்கை அடையாளம் காணுங்கள்; விதிமுறைக்கு உட்பட்ட மாற்று வழியை வழங்குங்கள்; வெளிப்படையாக மனிதர் கோரப்படும்போது, அல்லது அதிகார எல்லையைத் தாண்டும்/பாதுகாப்பு சார்ந்த நிலையில் மட்டுமே மாற்றுங்கள். +இதே அணுகுமுறையை வேறு களங்களுக்கும் கொண்டு செல்லலாம். விமானச் சேவை வாடிக்கையாளர் ஏஜெண்டின் வழக்கமான சிக்கல் வழக்கு இதுவே: பயனர் திருப்பிச் செலுத்தும் கட்டணம், மாற்றக் கட்டணம் அல்லது சாமான் விதிகள் குறித்து ஆட்சேபிக்கிறார்; ஏஜெண்டோ கொள்கையைப் பார்க்காமல், விதியை விளக்காமல், விதிக்கு உட்பட்ட மாற்று வழியையும் தேடாமல் `transfer_to_human` ஐ அழைக்கிறது. வழக்கமான கொள்கைத் தகராறுக்கு மாற்றுதல் தேவையில்லை; **பயனர் வெளிப்படையாக மனித முகவரைக் கோரினால், அல்லது பாதுகாப்பு தொடர்பான சூழல் எழுந்தால் மட்டுமே மாற்றுதல் கட்டாயமாகிறது**. நோயறிதல் மீண்டும் வெளிப்படையாக எழுதப்படாத மாற்றுதல் எல்லையையே சுட்டுகிறது; திருத்தமும் மீண்டும் அதை மூலம் குறிக்கப்பட்ட ஒரே குறைந்தபட்ச விதியாக மாற்றுவதே. > **பரிசோதனை 9-3 ★★: தோல்விப் பாதைகளிலிருந்து விமான வாடிக்கையாளர் சேவையின் சிஸ்டம் Prompt-ஐ மேம்படுத்துதல்** > diff --git a/book-tr/chapter9.tr.md b/book-tr/chapter9.tr.md index 46f9c5042..18d90c233 100644 --- a/book-tr/chapter9.tr.md +++ b/book-tr/chapter9.tr.md @@ -83,18 +83,6 @@ Eksiksiz bir bilgi damıtma boru hattı beş adıma ayrılabilir. Önce değişm GAIA deneyim öğrenmesi bunun sezgisel bir örneğini veriyor. GAIA[^gaia-2023], arama, web sayfası okuma, dosya işleme ve hesaplamayı bir arada gerektiren çok adımlı sorular içerir; AWorld[^aworld-2025] ise Agent'ı çalıştıran, bu araçları çağıran ve trajectory'leri saklayan yürütme ortamını sağlar. Birincisi sınav kâğıdı gibiyse ikincisi sınav salonu ve deney kayıt sistemidir. Eski usul yaklaşım, bir görev başarıyla tamamlanır tamamlanmaz strateji özeti üretip bunu vektörleştirerek depoya yazmaktı; daha titiz bir uygulama ise önce GAIA cevap doğrulamasını veya başka bir ortam doğrulayıcısını kullanarak çalışmaları başarılı, kısmen başarılı ve başarısız olarak etiketler, ardından aynı görev ailesindeki birden çok yolu karşılaştırır. Başarılı trajectory'ler aday stratejilere katkı verir, başarısız trajectory'ler dışlayıcı bilgiye katkı verir, kısmen başarılı trajectory'ler ise "hangi bölüm işe yaradı, hangi bölümde hâlâ sorun var" ayrımını yapmaya yardımcı olur. Reflexion'ın[^reflexion-2023] önerdiği doğal dil reflection'ı aday derslerin üretilmesine katılabilir, ama reflection'ın kendisi kanıt değildir; yalnızca ortam sonucuyla örtüşen, trajectory'ler arasında destek bulan ve yeni görevlerde olumlu aktarım gösteren içerik resmî deneyim dokümanına girmelidir. -> **Deney 9-2 ★★: GAIA Trajectory'lerinden Deneyim Bilgi Dokümanı Damıtmak** -> -> **Deney Amacı**: "Trajectory'ler arası bilgi dokümanı"nın "tek bir başarının özetini hatırlamak"tan daha kolay aktarılıp aktarılmadığını sınamak ve tesadüfi başarıların ve hatalı deneyimin yol açtığı negatif aktarımı azaltmak. -> -> **Veri ve Akış**: `gaia-experience` önce her çalışmanın eksiksiz trajectory'sini ve dışarıdan gelen `environment_score` değerini saklar, sonra bunları asgari öğrenme kayıtlarına dönüştürür: `task_family`, gereken `capabilities`, `applies_when`, gözlenen stratejiler, hatalar, istisnalar ve kaynak trajectory kimlikleri. Sonuç doğrulayıcısı çalışmaları başarılı, kısmen başarılı ve başarısız olarak ayırır; öğrenme modülü aynı görev ailesi içinde yolları karşılaştırır. LLM aday genellemeler önerebilir, ama önerilen bir stratejinin en az iki başarısız olmayan trajectory tarafından desteklenmesi gerekir. Sonuçta üretilen Markdown dokümanı uygulanabilir senaryoyu, önerilen stratejileri, sık yapılan hataları, istisna koşullarını, kaynağı ve en son doğrulama zamanını içerir. Uygulama aşamasında yalnızca bu dokümanlar retrieval ile getirilir; uzun ham trajectory'ler doğrudan context'e tıkıştırılmaz. -> -> **Üç Karşılaştırma Grubu**: Birinci grup geçmiş deneyimi hiç kullanmaz; ikinci grup mevcut göreve en çok benzeyen tek bir trajectory özetini getirir; üçüncü grup birden çok trajectory tarafından ortaklaşa desteklenen bilgi dokümanını getirir. Öğrenme kümesi ile aktarım kümesi kesinlikle örtüşmemelidir; aksi hâlde aynı GAIA sorusunun cevabı "deneyim" adı altında değerlendirmeye sızar. -> -> **Metrikler ve Kabul**: Aktarım görevlerindeki başarı oranı, ortalama getirilen karakter veya Token sayısı ve negatif aktarım oranı birlikte raporlanır; ayrıca her resmî sonucun kaynak trajectory'leri listeleyip listelemediği denetlenir. Trajectory'ler arası doküman yalnızca context'i kısaltıyor ama yeni görevlerdeki başarımı yükseltmiyorsa, sistemin deneyimi öğrendiği kanıtlanmış olmaz; tek bir tesadüfi başarı resmî bilgiye terfi edebiliyorsa ya da doküman ham trajectory'ye kadar izlenemiyorsa da kabul geçilmez. -> -> Eşlik eden uygulama için bkz. [`gaia-experience`](../chapter9/gaia-experience/). `demo_documents.py` varsayılan olarak çevrimdışı çalışır; `--extractor llm` ile trajectory'ler arası deneyim adaylarını gerçek bir LLM önerebilir. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy bu yaklaşımı **sistem promptu öğrenmesi** (System Prompt Le Sistem promptu öğrenmesi, 2. bölümdeki prompt mühendisliğiyle aynı şey değildir. 2. bölüm iyi bir Prompt'un nasıl düzenleneceğini tartışıyordu; bu bölüm ise hangi geri bildirimin bir değişikliği tetiklemeye yeteceğini ve güncelleme önerisinin nasıl güvenle yayına alınacağını tartışıyor. Değişiklik, kaynağı belirtilmiş en küçük diff olmalı; modele her seferinde Prompt'un tamamını yeniden yazdırmak değil. Bu, 1. bölümde adı konan "en küçük diff + geri alınabilirlik" örüntüsünün ta kendisidir. Aday sürüm hem **hatayı tetikleyen sınır kümesinde** hem de **halihazırda çalışan koruma kümesinde** sınanmalıdır: ilki iyileşmeli, ikincisi gerilememelidir. -#### Örnek 1: Başarısızlık Trajectory'lerine Dayanarak Prompt Kurallarını İyileştirmek +#### Örnek 1: Devir sınırının kurala dökülmesi + +τ²-bench'in telecom politikasında insan temsilciye devir yalnızca iki ilkesel cümleyle düzenlenmiştir: talep Agent'ın eylem kapsamını aştığında devret, devretmeden önce çözmek için elinden geleni yap. Yedinci bölüm bu ortamı incelerken bu iki satır bir kusur göstermemişti; aynı ortamı daha zayıf bir modelle çalıştırın, eksiklik hemen açığa çıkar — araç hata döndürdükten sonra Agent üst üste yeniden dener ve sonunda insana devrederek işi bitirir. Çıkarım kümesindeki 20 görevin 19'u böyle sonlandı. -7. bölümde τ-bench/τ²-bench ile bir havayolu müşteri hizmetleri Agent'ının nasıl değerlendirildiği anlatılmıştı: kullanıcı gereksinimlerini adım adım açar, sistem hem rezervasyon gibi ortam durumunu hem de konuşmada gerekli bilginin verilip verilmediğini denetler. O bölümdeki hata atfı ayrıca yalnızca "başarısız" diye kaydetmenin yetmediğini, **ilk hatalı adımın** bulunması gerektiğini vurguluyordu. +Bu 19 başarısız trajectory'yi bir modele verin, birkaç uygulanabilir kuralı kendi başına türetmesine izin verin ve bunları politikanın sonuna ekleyin; ardından çıkarıma hiç katılmamış bir görev kümesinde yeniden çalıştırın. Geçme oranı %12,3'ten %19,3'e çıkar ve daha önce geçen görevlerden hiçbiri bozulmaz. -Buradaki sorunlu vaka şu: kullanıcı iade, değişiklik ücreti ya da bagaj politikasından yakınır; Agent ise politikaya bakmadan, kuralı açıklamadan ve izin verilen bir alternatif aramadan `transfer_to_human` çağırır. Sıradan bir politika anlaşmazlığı aktarma gerektirmez; **aktarma yalnızca kullanıcı açıkça bir insan istediğinde ya da güvenlik/can riski doğduğunda zorunludur**. Dolayısıyla sorun "Agent yeterince kibar değil" değil, Prompt'un aktarma sınırını hiç yazmamış olmasıdır. +**Çıkarıcıya ne gösterildiği, neyi türetebileceğini belirler.** Aynı 19 trajectory'den yalnızca başarısızlık özetleri ve hata metinleri verildiğinde çıkan sonuç "aynı hatayı tekrar tekrar döndüren bir aracı çağırmayı sürdürme" olur; Agent'ın ve kullanıcının ayrı ayrı hangi araçları çağırabildiğini gösteren listeyi de eklediğinizde sonuç "ağ durumu, SIM kart ve APN denetimleri kullanıcının cihazına aittir; doğrudan çağrılmak yerine kullanıcıya yol gösterilerek yaptırılmalıdır" haline gelir. İlki bir dersi kaydeder, ikincisi sorumluluğun nerede durduğunu kavrar. + +**Model, gözlemlediği davranışı olması gereken davranış sayar.** İlk sürüm kurallardan ikisi şöyleydi: "art arda üç başarısız çağrıdan sonra insana devret" ve "kullanıcı iki istek sonrasında numarayı vermezse insana devret". Trajectory'lerde en sık görünen şey insana devirdir, model de bunu makul bir son çare saymıştır. Oysa bu değerlendirmede insana devir her zaman başarısızlık olarak hükme bağlanır; dolayısıyla bu iki kural başarısızlığı bizzat düzenlemenin içine yazar. Bu yüzden çıkarımın ürünü doğrudan yayına alınamaz, onu üreten şeyden bağımsız bir doğrulamadan geçmelidir. + +**Onarılan şey çoğu zaman son derece yalındır.** Temel kolda tipik bir trajectory vardır: Agent kullanıcının telefon numarasına ihtiyaç duyar, sorgu aracını çağırır ve parametreye "Lütfen telefon numaranızı verin" yazar — arka arkaya beş kez, beş hata, ardından devir. Kullanıcıya sorması gerektiğini zaten çıkarmıştı; yalnızca bu cümleyi araca söylemişti. Kurallar yürürlüğe girdikten sonra önce konuşmada talebi dile getiriyor, numarayı alıyor ve ancak sonra sorguluyor; daha sonra SIM kart durumunu denetleme girişimi araç katmanında reddedilince, kullanıcıyı SIM kartı çıkarıp yeniden takmaya yönlendirmeye geçiyor ve görev geçiyor. + +> **Deney 9-2 ★★: τ²-bench başarısız trajectory'lerinden devir ve araç kullanım kuralları çıkarmak** +> +> Yedinci bölümdeki τ²-bench telecom ortamı olduğu gibi kullanılır. Çıkarım kümesi ile aktarım kümesi, yukarı akış deposunda zaten birbiriyle kesişmeyen iki görev kümesidir; dolayısıyla çıkarım süreci aktarım kümesine hiç değmez. +> +> Önce çıkarım kümesini zayıf bir modelle çalıştırıp başarısız trajectory'leri saklayın; kuralları insan değil model türetsin ve üretildikten sonra özgün politikanın sonuna eklensinler; ardından aktarım kümesinde özgün politikayı iki evrilmiş sürümle karşılaştırın. Üç kol arasında yalnızca politika dosyası değiştirilir, kullanıcı simülatörü sabit tutulur. +> +> Geçme oranının yanı sıra kurallarla doğrudan örtüşen üç davranış göstergesi kaydedilmelidir: insana devir oranı, Agent'ın sınırını aşıp kullanıcı tarafındaki bir aracı çağırma sayısı ve zorunlu parametresi eksik gönderilen çağrı sayısı. Son iki gösterge evrilmiş sürümlerde yaklaşık %80 düşer; bu da geçme oranındaki artışın kuralların somut eylemleri onarmasından geldiğini gösterir. -Bu teşhis doğrudan promptta bir kurala dönüşür: önce politikayı sorgula ve açıkla, kullanıcının gerçekte çözmek istediği hedefi belirle ve mevzuata uygun bir alternatif sun; yalnızca açıkça insan istendiğinde ya da yetki aşıldığında veya güvenlik söz konusu olduğunda aktar. +Aynı yaklaşım başka alanlara da taşınır. Bir havayolu müşteri hizmetleri Agent'ı için tipik sorunlu vaka şudur: kullanıcı iade ücretine, değişiklik ücretine ya da bagaj kurallarına itiraz eder; Agent politikayı sorgulamadan, kuralı açıklamadan ve kurallara uygun bir alternatif aramadan `transfer_to_human` çağırır. Sıradan bir politika anlaşmazlığı devir gerektirmez; **devri zorunlu kılan yalnızca kullanıcının açıkça insan temsilci istemesi ya da güvenlikle ilgili bir durumun ortaya çıkmasıdır**. Teşhis yine hiç açıkça yazılmamış bir devir sınırını gösterir, düzeltme de yine onu kaynağı belirtilmiş tek bir asgari kurala dönüştürmektir. > **Deney 9-3 ★★: Başarısız yörüngelerden havayolu müşteri hizmetleri sistem Prompt'unu optimize etmek** > diff --git a/book-vi/chapter9.vi.md b/book-vi/chapter9.vi.md index 321bf3058..a0769afc6 100644 --- a/book-vi/chapter9.vi.md +++ b/book-vi/chapter9.vi.md @@ -83,18 +83,6 @@ Một đường ống chắt lọc tri thức hoàn chỉnh có thể chia thàn Học kinh nghiệm GAIA cung cấp một ví dụ trực quan. GAIA[^gaia-2023] gồm các câu hỏi nhiều bước cần kết hợp tìm kiếm, đọc trang web, xử lý tệp và tính toán; AWorld[^aworld-2025] cung cấp môi trường thực thi để chạy Agent, gọi các công cụ đó và lưu quỹ đạo. Nếu cái trước giống đề thi thì cái sau giống phòng thi và hệ thống ghi chép thí nghiệm. Cách cũ tạo ngay bản tóm tắt chiến lược sau một lần thành công rồi vector hóa và đưa vào kho. Cách nghiêm ngặt hơn trước tiên dùng bộ kiểm tra đáp án GAIA hoặc bộ xác minh môi trường khác để gắn nhãn thành công, thành công một phần và thất bại, sau đó so sánh nhiều lộ trình trong cùng họ nhiệm vụ. Quỹ đạo thành công cung cấp chiến lược ứng viên; quỹ đạo thất bại cung cấp tri thức loại trừ; quỹ đạo thành công một phần giúp xác định “đoạn nào hiệu quả, đoạn nào vẫn có vấn đề”. Phản tư bằng ngôn ngữ tự nhiên do Reflexion[^reflexion-2023] đề xuất có thể tham gia tạo bài học ứng viên, nhưng bản thân phản tư không phải bằng chứng. Chỉ nội dung phù hợp với kết quả môi trường, được nhiều quỹ đạo ủng hộ và thể hiện chuyển giao tích cực trên nhiệm vụ mới mới nên đi vào tài liệu kinh nghiệm chính thức. -> **Thí nghiệm 9-2 ★★: Chắt lọc tài liệu tri thức kinh nghiệm từ quỹ đạo GAIA** -> -> **Mục tiêu thí nghiệm**: Kiểm tra liệu “tài liệu tri thức xuyên quỹ đạo” có dễ chuyển giao hơn “ghi nhớ bản tóm tắt của một lần thành công”, đồng thời giảm chuyển giao tiêu cực do thành công ngẫu nhiên và kinh nghiệm sai hay không. -> -> **Dữ liệu và quy trình**: `gaia-experience` trước tiên lưu toàn bộ quỹ đạo và `environment_score` bên ngoài của mỗi lần chạy, rồi chuyển chúng thành bản ghi học tập tối thiểu gồm `task_family`, `capabilities` cần thiết, `applies_when`, chiến lược quan sát được, sai sót, ngoại lệ và ID quỹ đạo nguồn. Bộ xác minh kết quả phân loại lần chạy thành thành công, thành công một phần hoặc thất bại. Mô-đun học tập so sánh các lộ trình trong cùng họ nhiệm vụ; LLM có thể đề xuất quy nạp ứng viên, nhưng một chiến lược đề xuất phải được ít nhất hai quỹ đạo không thất bại ủng hộ. Tài liệu Markdown cuối cùng gồm bối cảnh áp dụng, chiến lược đề xuất, sai lầm thường gặp, điều kiện ngoại lệ, nguồn và thời điểm xác minh gần nhất. Giai đoạn áp dụng chỉ truy xuất các tài liệu này, không nhét quỹ đạo gốc dài vào ngữ cảnh. -> -> **Ba nhóm đối chứng**: Nhóm một không dùng kinh nghiệm lịch sử. Nhóm hai truy xuất bản tóm tắt của một quỹ đạo giống nhiệm vụ hiện tại nhất. Nhóm ba truy xuất tài liệu tri thức được nhiều quỹ đạo cùng ủng hộ. Tập học và tập chuyển giao phải không giao nhau, tránh để đáp án của cùng một câu GAIA bị rò rỉ vào đánh giá dưới tên “kinh nghiệm”. -> -> **Chỉ số và nghiệm thu**: Đồng thời báo cáo tỷ lệ thành công của nhiệm vụ chuyển giao, số ký tự hoặc Token truy xuất trung bình và tỷ lệ chuyển giao tiêu cực; kiểm tra mỗi kết luận chính thức có liệt kê quỹ đạo nguồn hay không. Nếu tài liệu xuyên quỹ đạo chỉ rút ngắn ngữ cảnh mà không cải thiện nhiệm vụ mới, không thể kết luận hệ thống đã học từ kinh nghiệm. Nếu một thành công ngẫu nhiên có thể được nâng thẳng thành tri thức chính thức, hoặc tài liệu không truy vết được về quỹ đạo gốc, thí nghiệm cũng không đạt. -> -> Phần triển khai đi kèm nằm tại [`gaia-experience`](../chapter9/gaia-experience/). `demo_documents.py` mặc định chạy ngoại tuyến; dùng `--extractor llm` để LLM thực đề xuất các ứng viên kinh nghiệm xuyên quỹ đạo. - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy gọi cách làm này là **học Prompt hệ thống** (System Học Prompt hệ thống không phải là kỹ thuật prompt ở chương 2. Chương 2 bàn cách tổ chức một Prompt tốt; mục này bàn xem phản hồi thế nào thì đủ để kích hoạt việc sửa, và đề xuất cập nhật được phát hành an toàn ra sao. Sửa đổi phải là một diff tối thiểu có nguồn gốc, chứ không phải mỗi lần đều để mô hình viết lại toàn bộ Prompt — đây chính là mô thức "diff tối thiểu + có thể quay lui" đã được đặt tên ở chương 1. Phiên bản chờ kiểm chứng bắt buộc phải được thử đồng thời trên **tập biên đã gây ra thất bại** và **tập giữ lại vốn đang chạy tốt**: tập trước phải cải thiện, tập sau không được thoái lui. -#### Ví dụ 1: Tối ưu hóa quy tắc trong prompt dựa trên quỹ đạo thất bại +#### Ví dụ 1: quy tắc hóa ranh giới chuyển tiếp + +Trong chính sách telecom của τ²-bench, việc chuyển sang nhân viên chỉ được quy định bằng hai câu mang tính nguyên tắc: chỉ chuyển khi yêu cầu vượt quá phạm vi hành động của Agent, và trước khi chuyển hãy cố hết sức giải quyết. Khi chương 7 mổ xẻ môi trường này, hai dòng ấy không bộc lộ vấn đề gì; chạy cùng môi trường với một mô hình yếu hơn thì khiếm khuyết lộ ra ngay — sau khi công cụ trả về lỗi, Agent lặp đi lặp lại việc thử lại rồi kết thúc bằng chuyển cho nhân viên. Đó chính là cách 19 trong 20 nhiệm vụ của tập chắt lọc kết thúc. -Chương 7 đã dùng τ-bench/τ²-bench để nói về cách đánh giá Agent chăm sóc khách hàng hàng không: người dùng hé lộ nhu cầu từng bước, hệ thống vừa kiểm tra trạng thái môi trường như đơn đặt chỗ, vừa kiểm tra xem trong hội thoại đã đưa ra thông tin cần thiết hay chưa. Phần quy trách thất bại của chương đó còn nhấn mạnh rằng không thể chỉ ghi "thất bại", mà phải tìm ra **bước sai đầu tiên**. +Giao 19 quỹ đạo thất bại ấy cho mô hình, để nó tự quy nạp ra vài quy tắc khả thi rồi bổ sung vào cuối chính sách; sau đó chạy lại trên một tập nhiệm vụ chưa từng tham gia quá trình chắt lọc. Tỷ lệ vượt qua tăng từ 12,3% lên 19,3%, và không một nhiệm vụ vốn đã vượt qua nào bị làm hỏng. -Ca xấu trong ví dụ này là: người dùng không hài lòng về hoàn vé, phí đổi vé hay chính sách hành lý, còn Agent thì gọi `transfer_to_human` mà không tra chính sách, không giải thích quy định, cũng không tìm phương án thay thế được phép. Tranh cãi chính sách thông thường không cần chuyển tiếp; **chỉ khi người dùng yêu cầu rõ ràng gặp nhân viên, hoặc xuất hiện rủi ro an toàn/thân thể, thì mới bắt buộc chuyển tiếp**. Vậy nên vấn đề không phải là "Agent chưa đủ lễ độ", mà là Prompt chưa viết rõ ranh giới chuyển tiếp. +**Cho bộ chắt lọc xem gì sẽ quyết định nó quy nạp được gì.** Vẫn 19 quỹ đạo ấy, nếu chỉ cung cấp bản tóm tắt thất bại và văn bản lỗi thì thứ nó rút ra là "cùng một công cụ đã báo lỗi nhiều lần thì đừng gọi tiếp"; bổ sung thêm danh sách công cụ mà Agent và người dùng mỗi bên có thể gọi thì kết quả đổi thành "kiểm tra trạng thái mạng, SIM, APN thuộc về thiết bị của người dùng, phải hướng dẫn người dùng tự thao tác chứ không gọi trực tiếp". Cái trước ghi lại một bài học, cái sau nắm được trách nhiệm thuộc về ai. + +**Mô hình coi hành vi quan sát được là hành vi đáng phải làm.** Trong bản quy tắc đầu tiên có hai điều: "ba lần gọi thất bại liên tiếp thì chuyển cho nhân viên" và "người dùng hai lần không cung cấp số thì chuyển cho nhân viên" — thứ xuất hiện nhiều nhất trong các quỹ đạo chính là việc chuyển cho nhân viên, nên mô hình xem đó là phương án dự phòng hợp lý. Nhưng trong bộ đánh giá này, chuyển cho nhân viên tất yếu bị phán là thất bại; hai điều ấy chẳng khác nào viết thất bại vào chính quy phạm. Vì vậy sản phẩm chắt lọc không thể phát hành thẳng, phải qua một khâu kiểm chứng độc lập với thứ đã sinh ra nó. + +**Chỗ được sửa thường là điều hết sức mộc mạc.** Trong nhánh cơ sở có một quỹ đạo điển hình: Agent cần số điện thoại của người dùng, bèn gọi công cụ tra cứu và điền vào tham số dòng chữ "Xin vui lòng cho biết số điện thoại của bạn" — năm lần liên tiếp, năm lần báo lỗi, rồi chuyển cho nhân viên. Nó đã suy ra rằng phải hỏi người dùng, chỉ có điều nó nói câu ấy với công cụ. Sau khi quy tắc có hiệu lực, nó hỏi trong hội thoại trước, lấy được số rồi mới tra; về sau khi ý định kiểm tra trạng thái SIM bị tầng công cụ từ chối, nó chuyển sang hướng dẫn người dùng tự tháo lắp lại SIM, và nhiệm vụ vượt qua. + +> **Thí nghiệm 9-2 ★★: Chắt lọc quy tắc chuyển tiếp và sử dụng công cụ từ quỹ đạo thất bại của τ²-bench** +> +> Dùng lại môi trường τ²-bench telecom của chương 7. Tập chắt lọc và tập chuyển giao vốn đã là hai tập nhiệm vụ không giao nhau trong kho thượng nguồn, nên quá trình chắt lọc không hề chạm tới tập chuyển giao. +> +> Trước hết chạy tập chắt lọc bằng mô hình yếu và lưu lại các quỹ đạo thất bại; quy tắc do mô hình quy nạp chứ không do người viết, sinh xong thì bổ sung vào cuối chính sách gốc; sau đó trên tập chuyển giao hãy đối chiếu chính sách gốc với hai bản tiến hóa. Giữa ba nhánh chỉ thay tệp chính sách, bộ mô phỏng người dùng giữ nguyên. +> +> Ngoài tỷ lệ vượt qua, cần ghi lại ba chỉ số hành vi tương ứng trực tiếp với các quy tắc: tỷ lệ chuyển cho nhân viên, số lần Agent vượt quyền gọi công cụ phía người dùng, và số lần phát ra lời gọi khi còn thiếu tham số. Hai chỉ số sau đều giảm khoảng 80% ở các bản tiến hóa, cho thấy mức tăng của tỷ lệ vượt qua đến từ việc quy tắc đã sửa được những hành động cụ thể. -Chẩn đoán này chuyển thẳng thành một quy tắc trong prompt: trước hết tra cứu và giải thích chính sách, nhận ra mục tiêu mà người dùng thực sự muốn giải quyết, đưa ra phương án thay thế hợp quy; chỉ chuyển tiếp khi được yêu cầu rõ ràng gặp nhân viên, hoặc khi vượt quá thẩm quyền/liên quan đến an toàn. +Cách làm tương tự có thể chuyển sang lĩnh vực khác. Ca lỗi điển hình của Agent chăm sóc khách hàng hàng không là thế này: người dùng phản đối phí hoàn vé, phí đổi vé hoặc quy định hành lý, còn Agent thì không tra chính sách, không giải thích quy định, cũng không tìm phương án thay thế hợp lệ, mà gọi thẳng `transfer_to_human`. Tranh chấp chính sách thông thường không cần chuyển tiếp; **chỉ khi người dùng nêu rõ muốn gặp nhân viên, hoặc xuất hiện tình huống liên quan đến an toàn, thì mới bắt buộc phải chuyển**. Chẩn đoán vẫn chỉ về chỗ ranh giới chuyển tiếp chưa được viết rõ, và cách sửa vẫn là biến nó thành một quy tắc tối thiểu có ghi xuất xứ. > **Thí nghiệm 9-3 ★★: Tối ưu hóa Prompt hệ thống của chăm sóc khách hàng hàng không từ quỹ đạo thất bại** > diff --git a/book-zhtw/chapter9.zhtw.md b/book-zhtw/chapter9.zhtw.md index 32a644479..074ef125a 100644 --- a/book-zhtw/chapter9.zhtw.md +++ b/book-zhtw/chapter9.zhtw.md @@ -83,18 +83,6 @@ GAIA 經驗學習提供一個直觀案例。GAIA[^gaia-2023] 包含需要綜合搜尋、網頁閱讀、檔案處理與計算的多步驟問題，AWorld[^aworld-2025] 則提供執行 Agent、呼叫這些工具與保存軌跡的執行環境；前者像考卷，後者像考場與實驗紀錄系統。舊式做法是在一次任務成功後立刻產生策略摘要並向量化入庫；更嚴謹的實作會先用 GAIA 答案驗證器或其他環境驗證器標記成功、部分成功與失敗，再比較同一任務家族的多條路徑。成功軌跡貢獻候選策略，失敗軌跡貢獻排除性知識，部分成功軌跡則協助辨識「哪一段有效、哪一段仍有問題」。Reflexion[^reflexion-2023] 所提出的自然語言反思可以參與產生候選教訓，但反思本身不是證據；只有與環境結果相符、獲得跨軌跡支持，並在新任務上展現正向遷移的內容，才應進入正式經驗文件。 -> **實驗 9-2 ★★：從 GAIA 軌跡提煉經驗知識文件** -> -> **實驗目標**：檢驗「跨軌跡知識文件」是否比「記住一次成功的摘要」更容易遷移，並降低偶然成功與錯誤經驗造成的負向遷移。 -> -> **資料與流程**：`gaia-experience` 先保存每次執行的完整軌跡與外部 `environment_score`，再將其轉換為最小學習紀錄：`task_family`、所需 `capabilities`、`applies_when`、觀察到的策略、錯誤、例外與來源軌跡 ID。結果驗證器將執行分為成功、部分成功與失敗；學習模組在同一任務家族內比較路徑，LLM 可以提出候選歸納，但一條建議策略至少要獲得兩條非失敗軌跡支持。最後產生的 Markdown 文件包含適用場景、建議策略、常見誤區、例外條件、來源與最近驗證時間。套用階段只檢索這些文件，不將冗長的原始軌跡直接塞入上下文。 -> -> **三組對照**：第一組不使用歷史經驗；第二組檢索與目前任務最相似的一條軌跡摘要；第三組檢索由多條軌跡共同支持的知識文件。學習集與遷移集必須互不重疊，避免將同一道 GAIA 題目的答案當作「經驗」洩漏給評測。 -> -> **指標與驗收**：同時報告遷移任務成功率、平均檢索字元數或 Token 數、負向遷移率，並檢查每條正式結論是否列出來源軌跡。若跨軌跡文件只是縮短上下文，卻沒有提升新任務表現，便不能證明系統學會了經驗；若一次偶然成功即可升級為正式知識，或文件無法追溯至原始軌跡，也不通過驗收。 -> -> 配套實作見 [`gaia-experience`](../chapter9/gaia-experience/)。`demo_documents.py` 預設離線執行，使用 `--extractor llm` 可由真實 LLM 提出跨軌跡經驗候選。 - [^reflexion-2023]: Shinn, N., et al. *Reflexion: Language Agents with Verbal Reinforcement Learning.* arXiv:2303.11366, 2023. [^gaia-2023]: Mialon, G., et al. *GAIA: a benchmark for General AI Assistants.* arXiv:2311.12983, 2023. @@ -109,13 +97,27 @@ Andrej Karpathy 將這種做法稱為**系統提示學習**（System Prompt Lear 系統提示學習與第二章的提示工程不是一回事。第二章討論怎樣組織一份好 Prompt；本節討論什麼回饋足以觸發修改，以及更新提案怎樣安全發布。修改應是帶來源的最小 diff，而不是讓模型每次都重寫整份 Prompt——這正是第一章命名的最小 diff + 可回滾模式。待驗證版本必須同時在**觸發失敗的邊界集**和**正常工作的保留集**上測試，前者要改善，後者不能退化。 -#### 例子一：基於失敗軌跡最佳化提示詞中的規則 +#### 例子一：轉接邊界的規則化 + +τ²-bench 的 telecom 政策中，關於轉接人工只有兩條原則性規定：請求超出 Agent 的動作範圍時才轉接，轉接前應先盡力解決。第七章解剖該環境時，這兩條並未顯出問題；換用能力較弱的模型執行，缺陷隨即暴露——工具返回錯誤後 Agent 反覆重試，最終以轉接人工收場，提煉集的 20 條任務中有 19 條如此結束。 -第七章用 τ-bench／τ²-bench 說明了航空客服 Agent 的評估方式：使用者逐步透露需求，系統既檢查訂單等環境狀態，也檢查對話中是否給出了必要資訊。該章的失敗歸因還強調，不能只記錄「失敗」，而要找到**首個錯誤步驟**。 +將這 19 條失敗軌跡交由模型自行歸納，產出若干條可執行的規則追加到政策末尾，再在一批未參與提煉的任務上重新執行：通過率由 12.3% 升至 19.3%，且原本通過的任務無一被改壞。 -本例的問題案例是：使用者對退票、改簽費或行李政策不滿，Agent 沒有查政策、解釋規則或尋找允許的替代方案，就呼叫 `transfer_to_human`。普通政策爭議不需要轉接；**使用者明確要求人工或出現安全／人身風險時才必須轉接**。因此，問題不是「Agent 不夠禮貌」，而是 Prompt 沒有寫清轉接邊界。 +**提煉所依據的材料決定了能夠歸納出什麼。** 同樣是這 19 條軌跡，僅提供失敗摘要與錯誤文字時，模型歸納出的是「同一工具反覆報錯即不應繼續呼叫」；補充 Agent 與使用者各自可呼叫的工具清單之後，歸納結果變為「網路狀態、SIM 卡、APN 等項屬於使用者裝置側，應引導使用者自行操作而非直接呼叫」。前者記錄的是教訓，後者理解的是職責歸屬。 + +**模型會把觀察到的行為當作應然的行為。** 第一版規則中有兩條為「連續三次呼叫失敗即轉接人工」「使用者兩次未提供號碼即轉接人工」——軌跡中出現最頻繁的正是轉接人工，模型據此將其視為合理的兜底手段。但在這套評估中轉接人工必然判定失敗，這兩條規則等於把失敗寫入了規範。提煉產物因此不能直接釋出，須經與提煉者相互獨立的驗證。 + +**被修復的往往是極樸素的缺陷。** 基線中有一條典型軌跡：Agent 需要使用者的電話號碼，於是呼叫查詢工具，並將「請您提供您的電話號碼」填入參數，連續五次，五次報錯，隨後轉接人工。它已經判斷出應當詢問使用者，卻把這句話說給了工具。規則生效後，它先在對話中提出請求，取得號碼再行查詢；此後欲檢查 SIM 卡狀態遭工具拒絕，轉而引導使用者自行重新插拔 SIM 卡，任務通過。 + +> **實驗 9-2 ★★：從 τ²-bench 失敗軌跡提煉轉接與工具使用規則** +> +> 沿用第七章的 τ²-bench telecom 環境。提煉集與遷移集在上游倉庫中本就是兩套互不相交的任務，提煉過程接觸不到遷移集。 +> +> 先以弱模型執行提煉集並儲存失敗軌跡；規則由模型歸納而非人工撰寫，生成後追加至原始政策末尾；再在遷移集上對照原始策略與兩個進化版本。三臂之間只替換策略檔案，使用者模擬器保持不變。 +> +> 除通過率外，還需記錄三項與規則直接對應的行為指標：轉接人工的比例、Agent 越界呼叫使用者側工具的次數、參數缺失即發出的呼叫次數。後兩項在進化版本中均下降約八成，說明通過率的提升來自規則修復了具體動作。 -這條診斷可以直接變成提示詞中的一條規則：先查詢並解釋政策，識別使用者真正想解決的目標，提供合規替代方案；只有在明確要求人工或超出權限／涉及安全時才轉接。 +同樣的做法可以移植到其他領域。航空客服 Agent 的典型問題案例是：使用者對退票費、改簽費或行李政策提出異議，Agent 未查詢政策、未解釋規則、未尋找合規的替代方案，即呼叫 `transfer_to_human`。一般的政策爭議無須轉接，**只有使用者明確要求人工介入，或出現安全相關情形時才必須轉接**。診斷同樣指向轉接邊界未予明確，修法同樣是將其落成一條帶出處的最小規則。 > **實驗 9-3 ★★：基於失敗軌跡最佳化航空客服的系統 Prompt** >