سیستم چند ایجنتی: سه ایجنت و یک هماهنگ‌کننده که یک گراف چهارگره‌ای شدند

«اگر به‌جای یک ایجنت، سه ایجنت متخصص داشته باشیم بهتر نمی‌شود؟» این پیشنهاد تقریبا در هر پروژه‌ای یک بار سر جلسه گفته می‌شود، معمولا درست بعد از اینکه ایجنت موجود در یک کار خوب جواب داده و در کار دیگری ضعیف.

پیشنهاد جذابی است، چون شبیه سازمان آدم‌هاست: یکی پژوهش کند، یکی بنویسد، یکی ویرایش کند. ولی سیستم چند ایجنتی در بیشتر پروژه‌های واقعی گران‌ترین راه رسیدن به نتیجه‌ای است که یک گراف ساده هم می‌داد. در ادامه یک طرح را باز می‌کنیم و می‌بینیم از آن چه می‌ماند.

چهار الگو، و اینکه از کدام سر جدول شروع کنی

از بالای جدول شروع کن و فقط وقتی یک ردیف پایین برو که دلیلی داشته باشی که بشود نوشتش. «ایجنت متخصص» در عمل معمولا یعنی «پرامپت متخصص»، و پرامپت متخصص با یک شاخه در همان گراف به دست می‌آید. پس وقتی ایجنتت در یک کار خوب است و در کار دیگر ضعیف، اولین چیزی که امتحان می‌کنی دو پرامپت متفاوت روی یک گراف است، نه ایجنت دوم.

هر ایجنت تازه یک مرز است، و مرز سه خرج دارد

چیزی که هنگام کشیدن جعبه‌ها روی تخته دیده نمی‌شود، خط‌های میان جعبه‌هاست. هر خط سه هزینه می‌آورد که معمولا حساب نمی‌شوند:

1. انتقال حالت. هر مرز یعنی چیزی باید بسته‌بندی شود و آن طرف دوباره فهمیده شود. هر انتقال جایی است که اطلاعات می‌تواند گم شود.
2. تاخیر و هزینه‌ی ضرب‌شده. سه ایجنت یعنی دست‌کم سه بار صدا زدن مدل، و اگر هماهنگ‌کننده هم باشد، بیشتر.
3. عیب‌یابی سخت‌تر. وقتی جواب غلط است باید بفهمی کدام ایجنت اشتباه کرد، و بدون ردگیری کامل از سر تا ته، این کار تقریبا ناشدنی است.

یک نکته‌ی ظریف هم هست که دیر فهمیده می‌شود. ایجنت‌ها با هم متن رد و بدل می‌کنند. خروجی مبهم ایجنت اول ورودی ایجنت دوم می‌شود، و خطا در طول مسیر بزرگ‌تر می‌شود، نه اصلاح.

کالبدشکافی یک طرح: دسته‌بند، پژوهشگر، نویسنده

مثالی که دنبال می‌کنیم فرضی است و برای نشان دادن روش آمده. تیمی سیستمی با سه ایجنت ساخته است: دسته‌بند که می‌گوید سوال از چه نوعی است، پژوهشگر که سندها را می‌آورد، و نویسنده که جواب را می‌نویسد. یک هماهنگ‌کننده هم میانشان نشسته است. سیستم کار می‌کند، ولی کند است، گران است، و وقتی جواب غلط می‌دهد کسی نمی‌فهمد چرا.

قدم اول قضاوت نیست؛ اندازه‌گیری است:

اولین یافته در همین جدول است. هماهنگ‌کننده هیچ کار محتوایی نمی‌کند و با این حال سهم بزرگی از تاخیر و هزینه را برده است. حالا از هر بخش یک پرسش می‌پرسیم: واقعا مستقل است؟

دسته‌بند

خروجی‌اش یک برچسب است. ابزار ندارد و حلقه ندارد. این یک فراخوانی با خروجی ساختاریافته است، نه ایجنت.

پژوهشگر

بازیابی می‌کند. این یک گره است. اگر خودش تصمیم بگیرد که دوباره جست‌وجو کند، حداکثر یک زیرگراف می‌شود.

نویسنده

از روی حالت گراف جواب می‌سازد. یک گره‌ی دیگر. و هماهنگ‌کننده؟ کارش این بود که بگوید «نفر بعدی کیست»، و این را یک یال شرطی بدون صدا زدن مدل انجام می‌دهد.

هیچ‌کدام از این سه با دیگری هم‌زمان کار نمی‌کرد و هیچ‌کدام حالت مستقل بلندمدتی نداشت. طرح تازه یک گراف است: گره‌ی دسته‌بندی اول می‌آید؛ اگر سوال به سند نیاز داشت به گره‌ی بازیابی می‌رود و بعد به نوشتن، و اگر نداشت مستقیم به نوشتن. فراخوانی‌های مدل از پنج به دو رسید (دسته‌بندی و نوشتن)، هماهنگ‌کننده کاملا حذف شد، و مسیری که سند لازم ندارد دیگر اصلا بازیابی نمی‌کند؛ کاری که پیش‌تر برای هر سوال انجام می‌شد.

کار این‌جا تمام نیست. بعد از ساده‌سازی باید مجموعه‌ی ارزیابی‌ات را روی هر دو نسخه اجرا کنی. اگر نرخ درستی افت نکرد، این ساده‌سازی رایگان بوده است. اگر افت کرد، یکی از آن ایجنت‌ها کاری می‌کرده که در تبدیل از دست رفته، و همان‌جا می‌فهمی کدام و چرا.

آزمون سه‌سوالی برای هر جعبه‌ای که اسمش را ایجنت گذاشته‌ای

همین بازجویی را می‌شود روی هر طرحی اجرا کرد، چه ساخته شده باشد و چه هنوز روی کاغذ باشد. برای هر «ایجنت» سه پرسش جواب بده:

1. ابزار دارد و خودش تصمیم می‌گیرد کدام را صدا بزند؟ اگر نه، ایجنت نیست؛ یک فراخوانی است.
2. حالت مستقلی دارد که بقیه نباید ببینند؟ اگر نه، یک گره است، نه ایجنت جدا.
3. می‌تواند هم‌زمان با بقیه کار کند؟ اگر نه، مرز جدا فقط خرج است.

هر کدام که به هر سه «بله» نگرفت به گره تبدیل می‌شود. بعد بشمار چند تا مانده است. در بیشتر پروژه‌ها جواب یک یا دو است.

این تمرین معمولا نتیجه‌ی ناخوشایندی دارد: بیشتر آنچه ایجنت نامیده‌ایم یک فراخوانی ساختاریافته است. و اسم‌گذاری غلط بی‌ضرر نیست. وقتی به چیزی ایجنت می‌گویی، برایش مرز جدا می‌سازی و هر سه هزینه را می‌پذیری، بدون اینکه چیزی در برابرش بگیری. از آن طرف، هر مرزی که حذف می‌شود یک دسته باگ را هم با خودش می‌برد.

موازی‌سازی تاخیر را کم می‌کند، هزینه را نه

در همان مثال یک جا واقعا جای کار هم‌زمان بود. اگر پژوهشگر باید سه منبع مستقل را بگردد (مخزن سندهای داخلی، پایگاه سفارش‌ها و یک سرویس بیرونی) این سه جست‌وجو به خروجی هم نیاز ندارند و می‌توانند با هم بروند. آن‌وقت تاخیر کل به کندترینشان بسته است، نه به جمع هر سه.

ولی این هنوز «چند ایجنت» نیست. سه گره‌ی موازی در یک گراف است که بعد به یک گره‌ی ادغام می‌رسند. همان سود را می‌دهد و هیچ‌کدام از سه خرج مرز را ندارد. برای اینکه مطمئن شوی، یک بار ترتیبی اجرا کن و زمان بگیر، یک بار موازی، و سه عدد را کنار هم بنویس: تاخیر ترتیبی، تاخیر موازی، و تعداد فراخوانی، که در هر دو حالت یکی است.

• تعداد فراخوانی همان است، پس هزینه همان می‌ماند. اگر مسئله‌ات هزینه است، راهش کم کردن کار است، نه هم‌زمان کردنش.
• سه منبع یعنی سه برابر محتوا. اگر همه‌اش وارد ورودی مدل شود، توجه مدل رقیق می‌شود و کیفیت پایین می‌آید. به هر منبع سهم مشخصی بده؛ مثلا هر کدام حداکثر دو تکه، نه «هر چه پیدا شد».
• پیش از ادغام، تکراری‌ها را حذف کن. منبع‌های مختلف خیلی وقت‌ها همان قاعده را تکرار می‌کنند و همین حذف بیشترین اثر را دارد.

چهار تله‌ای که طرح‌های چندایجنتی در آن می‌افتند

هماهنگ‌کننده‌ای که فقط مسیریابی می‌کند

این کار را یک یال شرطی انجام می‌دهد. هماهنگ‌کننده وقتی می‌ارزد که واقعا تصمیم پیچیده‌ای بگیرد.

گفت‌وگوی ایجنت‌ها با یکدیگر

در نمایش جذاب است و در عمل حلقه‌های بی‌پایان و هزینه‌ی پیش‌بینی‌ناپذیر می‌سازد. اگر واقعا لازم شد، برای تعداد دورها سقف سخت بگذار.

تقسیم نقش از روی عنوان شغلی

«پژوهشگر، نویسنده، ویراستار» تقسیم‌بندی آدم‌هاست، نه تقسیم‌بندی محاسبه. معیار درست استقلال کار است، نه شباهت به چارت سازمانی.

نبود ردگیری سرتاسری

این تنها چیزی است که باید پیش از ساختن آماده باشد. بدون آن، پیدا کردن خطا در سیستمی با چند ایجنت عملا ممکن نیست.

تیم دونفره در برابر یک نفر منظم

یک کار کوچک را به دو نفر بسپار و بخش بزرگی از وقتشان صرف هماهنگی می‌شود: یکی باید توضیح بدهد، دیگری باید بفهمد، و آخر سر نتیجه باید یکی شود. برای کار کوچک، یک نفر منظم سریع‌تر است. تیم وقتی می‌ارزد که کار واقعا قابل تقسیم باشد؛ یعنی دو نفر بتوانند هم‌زمان و جدا از هم کار کنند و نتیجه‌شان قابل ترکیب باشد.

همین معیار برای ایجنت‌ها هم صادق است. اگر ایجنت دوم باید منتظر اولی بماند، تیم نساخته‌ای؛ یک صف ساخته‌ای با خرج یک تیم.

اگر بعد از ساده‌سازی کیفیت افت کرد

این خبر بدی نیست؛ اطلاعات است. یعنی یکی از ایجنت‌های حذف‌شده کاری می‌کرده که حالا دقیقا می‌دانی چیست. معمولا آن کار یک پرامپت متخصص بوده که در گره‌ی مشترک گم شده است. راهش برگرداندن ایجنت نیست؛ برگرداندن همان پرامپت به شکل یک شاخه است.

و اگر بعد از این هم معلوم شد آن بخش واقعا به مرز مستقل نیاز دارد، حالا دلیل نوشتنی داری. کل این روش دنبال همین بود: نه حذف هر ایجنتی، که داشتن یک دلیل برای هر کدام.

جایی که چند ایجنت واقعا انتخاب درست است

این نوشته نمی‌گوید سیستم چند ایجنتی بد است. می‌گوید گران است و باید با معیار انتخاب شود، نه با جذابیت. وقتی چند مسیر مستقل باید هم‌زمان بروند و نتیجه‌شان ترکیب شود، یا وقتی بخشی واقعا ابزار خودش، حالت خودش و اختیار خودش را دارد، ساختار چندگانه چیزی اضافه می‌کند که یک گراف ساده نمی‌دهد.

محک آخر یک جمله است. اگر نمی‌توانی در یک جمله بگویی هر ایجنت چه تصمیمی می‌گیرد که بقیه نمی‌گیرند، آن ایجنت لازم نیست. «ایجنت» واحد معماری نیست؛ واحد اختیار است. پس پرسش «چند ایجنت بسازم؟» را کنار بگذار و بپرس چه چیزی واقعا باید مستقل تصمیم بگیرد. اگر می‌خواهی ساخت گراف، ابزار، ارزیابی و همین تصمیم‌های طراحی را با تمرین روی پروژه‌ی خودت یاد بگیری، جزئیات این دوره را ببین.