پرش به محتوای اصلی

وقتی یک ازدحام ایجنت LLM را مقیاس‌پذیر می‌کنید، واقعاً چه چیزی می‌شکند

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

A magnifying glass focuses on various business charts and graphs on paper.

مسئله هماهنگی، مدل نیست

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

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

چرا تحویل‌های زبان طبیعی شکننده هستند

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

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

دوم، آن‌ها غیرقطعی هستند. همان خروجی بالادستی می‌تواند در اجراهای مختلف متفاوت تفسیر شود، که بازتولید شکست‌ها را دشوار می‌کند.

سوم، آن‌ها شکست جزئی را پنهان می‌کنند. ایجنتی که یک نتیجه قابل‌قبول اما ناقص برمی‌گرداند، دقیقاً مانند یکی که موفق شده به نظر می‌رسد، مگر اینکه چیزی در پایین‌دست آن را بررسی کند.

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

یک مکانیزم مشخص: پاکت‌های نوع‌دار و دروازه‌های اعتبارسنجی

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

با پاکت‌های نوع‌دار، جریان این‌گونه است:

A developer's hand interacting with code on a laptop screen in a workspace setting.

{
  "task_id": "r-014",
  "produced_by": "retriever-2",
  "status": "partial",
  "artefact": { "claims": [ { "text": "...", "source": "..." } ] },
  "constraints": ["no claims without a source", "max 12 claims"],
  "missing": ["coverage of the cost dimension"]
}

ارکستراتور نثر را نمی‌خواند. status، constraints و missing را می‌خواند. اگر status برابر partial باشد، می‌تواند بُعد گم‌شده را دوباره ارسال کند به‌جای اینکه یک مصنوع تنزل‌یافته را به جلو بفرستد. ترکیب‌کننده فقط پاکت‌هایی را دریافت می‌کند که محدودیت‌هایشان برآورده شده است.

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

انتخاب‌های توپولوژی و هزینه‌هایشان

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

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

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

الگوی همتا-به-همتا یا مناظره. ایجنت‌ها مستقیماً تبادل می‌کنند و روی یک پاسخ همگرا می‌شوند. می‌تواند اختلاف‌نظرهایی را آشکار کند که یک سرپرست آن‌ها را صاف می‌کرد. هزینه‌اش این است که کران‌دار کردنش دشوار است: مصرف توکن، تأخیر، و شرایط خاتمه همه غیرساده می‌شوند. بدون یک محدودیت نوبت صریح و یک معیار همگرایی، می‌تواند بی‌نهایت اجرا شود در حالی که نویز مطمئن‌به‌نظر تولید می‌کند.

در عمل، بیشتر سیستم‌های تولیدی یک سرپرست با پاکت‌های نوع‌دار و یک یا دو زیر-خط لوله تخصصی هستند، نه یک مش کاملاً متصل.

بده‌بستان صادقانه: موازی‌سازی تأخیر می‌خرد و انسجام را هزینه می‌کند

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

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

Close-up of a magnifying glass over financial data charts and metrics on printed paper.

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

ارزیابی باید درزها را هدف بگیرد

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

یک رویکرد عملی ارزیابی در سه سطح است.

  • سطح ایجنت. آیا ایجنت با یک ورودی به‌خوبی شکل‌گرفته، قرارداد خودش را برآورده می‌کند؟ این آسان‌ترین برای آزمون و کم‌ترین پیش‌بینی‌کننده رفتار سیستم است.
  • سطح تحویل. با پاکت‌های بالادستی ضبط‌شده، آیا ایجنت پایین‌دست پاکتی تولید می‌کند که محدودیت‌های اعلام‌شده‌اش را برآورده کند؟ این انحراف اسکیما و شکست جزئی خاموش را می‌گیرد.
  • سطح مسیر. با یک وظیفه کامل، آیا سیستم در تعداد محدودی گام و توکن به یک نتیجه قابل‌قبول می‌رسد؟ اینجاست که توپولوژی و سیاست ادغام واقعاً آزموده می‌شوند.

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

اول چه چیزی بسازیم

اگر یک ازدحام شکست می‌خورد، ترتیب اصلاحات مهم‌تر از پیچیدگی هر یک از آن‌هاست.

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

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

نتیجه‌گیری

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

اشتراک‌گذاریXLinkedInپیوند یکتا5 دقیقه مطالعه

خواندن مرتبط

پرسش‌هایی که این پاسخ می‌دهد

What is the first thing to fix in a failing multi-agent system?

Introduce typed envelopes for every inter-agent message. Structured status, artefact and constraint fields make silent partial failures visible and allow the orchestrator to route on facts rather than re-inferred prose.

Is a fully connected peer-to-peer swarm better than a supervisor pattern?

Not by default. Peer-to-peer can surface disagreements, but token spend, latency and termination become hard to bound. Most production systems use a supervisor with typed handoffs and a few specialised sub-pipelines.

How should parallel agents handle conflicting results?

Parallel branches should emit typed envelopes and the merge step should apply a defined policy, such as preferring higher-provenance sources or routing conflicts to a critic agent. Without a merge policy, parallelism just produces more unverified text faster.

Why is evaluating individual agents not enough?

Most swarm failures occur at the seams: dropped constraints in handoffs, incorrect conflict resolution in merges, duplicated work in retries. Handoff-level and trajectory-level evaluation are needed to catch these.