تغییر ساختار پردازش: افزایش پایداری خروجی‌های پیچیده از ۶۰٪ به ۹۵٪

اگر برای مدیریت گردش‌کارهای پیچیده از عامل‌های هوش مصنوعی استفاده می‌کنید، احتمالاً با کابوس «خرابی‌های تصادفی» در خروجی‌ها آشنا هستید. اما یک تغییر ساختاری در نحوه سازماندهی وظایف می‌تواند نرخ خطای شما را از ۴۰٪ به ۵٪ کاهش دهد.

به گزارش Wu Ji، پایداری تولید گزارش‌های هوشمند پس از جایگزینی «صحنه گزارش» (Report Scene) با یک کانتینینر خط لوله (Pipeline Container) پنج‌مرحله‌ای، از حدود ۶۰٪ به ۹۵٪ جهش کرد. این نتیجه ثابت می‌کند که وظایف ترکیبی — یعنی کارهایی که نیاز به دسترسی هم‌زمان به چندین حوزه ابزاری دارند — توسط یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به صورت بداهه و در لحظه قابل مدیریت نیستند.

اکثر معماری‌های فعلی عامل‌ها بر اساس «مسیریابی صحنه» (Scene Routing) برای حل وظایفی با مسئولیت واحد طراحی شده‌اند. این روش برای ۹۰٪ عملیات‌ها جواب می‌دهد، اما در وظایف ترکیبی مثل تولید گزارش وضعیت، جایی که سیستم باید هم‌زمان به ایمیل‌ها، پایگاه‌های داده و منطق‌های مالی دسترسی داشته باشد، شکست می‌خورد. یک گزارش وضعیت معمولاً مجموعه‌ای از زیر-وظایف پراکنده شامل استعلام‌ها، پیش‌فاکتورها، یادآورها، یادداشت‌های تحویل (DNs) و گواهی‌های تحویل کالا (PODs) است؛ هیچ «صحنه» واحدی نمی‌تواند تمام این الزامات را هم‌زمان در خود جای دهد.

شکست «صحنه گزارش»

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

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

مکانیسم خط لوله پنج‌مرحله‌ای

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

• مرحله ۱ — تجمیع (Aggregate): سیستم تمام داده‌های دوره گزارش، شامل تمامی ایمیل‌ها، به‌روزرسانی‌های داده‌ای و لاگ‌های رویداد را می‌خواند. این مرحله صرفاً برای جمع‌آوری است و هیچ عملیات طبقه‌بندی، قضاوت یا فیلتری در آن صورت نمی‌گیرد.
• مرحله ۲ — تجزیه (Decompose): مطالب تجمیع شده به واحدهای کاری مستقل تقسیم می‌شوند. این واحدها بر اساس ایمیل، محموله یا موضوع سازماندهی می‌شوند. هر واحد کاری شامل داده‌های خام، موارد منتظر قضاوت و شماره محموله‌های مرتبط است.
• مرحله ۳ — ارسال (Dispatch): هر واحد کاری به مدیریت صحنه‌ای که مالک آن است ارجاع داده می‌شود. ایمیل‌ها به صحنه ایمیل، مسائل مالی به صحنه مالی و جمع‌آوری‌ها به صحنه Collection می‌روند. هر زیر-وظیفه در بستر (Context) مستقل خود اجرا می‌شود.
• مرحله ۴ — اجرا (Execute): زیر-وظایف به طور مستقل اجرا شده و نتایج ساختاریافته برمی‌گردانند. برای مثال، صحنه ایمیل خروجی «طبقه‌بندی شده + قضاوت شده» را ارائه می‌دهد، صحنه مالی «خلاصه‌ای از وجوه دریافتنی/پرداختی» را تولید می‌کند و صحنه Collection «پیشنهادهای یادآور» را ارائه می‌دهد.
• مرحله ۵ — گزارش (Report): در نهایت، LLM این نتایج ساختاریافته را در یک مرحله نهایی تجمیع کرده و در قالب یک گزارش کامل با فرمتی یکپارچه ارائه می‌دهد.

پیاده‌سازی فنی و محدودیت‌ها

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

در کد این خط لوله، تابع generate_report(period) ابتدا توابع fetch_inbox(period) و fetch_events(period) را برای تجمیع داده‌های خام فراخوانی می‌کند. سپس از split_into_units برای ایجاد واحدهای کاری (مثلاً [{"ticket": "TK001", "mails": [...], "pending": [...]}]) استفاده می‌کند. یک طبقه‌بندی‌کننده دو لایه در مرحله ارسال برای هدایت واحدها به صحنه‌های مربوطه مجدداً استفاده می‌شود. در نهایت، تابع llm_assemble(results) نتایج ساختاریافته را گرفته، یک پرامپت می‌سازد و فراخوانی نهایی LLM را برای تولید زبان طبیعی انجام می‌دهد.

مدیریت دسترسی به ابزارها و قوانین

این معماری یک استثنای منحصر‌به‌فرد در مسیریابی استاندارد صحنه‌ها ایجاد می‌کند: «دسترسی نامحدود به ابزارها». خط لوله گزارش نیاز دارد هم‌زمان به دسترسی ایمیل (ابزارهای صحنه ایمیل)، کوئری‌های پایگاه داده (ابزارهای صحنه کوئری) و تولید جدول (ابزارهای صحنه گزارش) داشته باشد. محدود کردن هر یک از این دسته‌ها منجر به تولید گزارشی ناقص می‌شد.

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

تحلیل عملکرد و سبک-سنگین کردن (Trade-offs)

با تغییر نقش LLM از «نویسنده گزارش» به «مجری SOP»، سیستم به دستاوردهای کلیدی زیر رسید:

• پایداری: پایداری گزارش‌ها از حدود ۶۰٪ به ۹۵٪ افزایش یافت.
• ردیابی (Traceability): پیش‌نویس‌ها در یک ذخیره‌گاه واحد قرار دارند و هر نتیجه‌گیری به منبع داده خاص خود ارجاع می‌دهد که تضمین می‌کند قضاوت‌ها دارای دلیل و مدرک هستند.
• ایزولاسیون: چون زیر-وظایف در بسترهای مستقل اجرا می‌شوند، خطای یک زیر-وظیفه هرگز باعث مسمومیت یا خرابی سایر بخش‌ها نمی‌شود.
• یکپارچگی: تمام ایمیل‌های دوره گزارش بدون استثنا طبقه‌بندی و مدیریت شده و فرمت خروجی فارغ از حجم داده‌ها، ثابت می‌ماند.

اما این رویکرد کانتینری هزینه‌های خاصی دارد. فرآیند پنج‌مرحله‌ای باعث افزایش تأخیر (Latency) در حدود ۳۰٪ نسبت به یک پرامپت تک-صحنه‌ای شده است. علاوه بر این، سیستم به شدت به یک SOP دقیق وابسته است؛ زمانی که دستورالعمل‌ها ضعیف باشند، LLM دوباره به حالت بداهه و ناپایدار بازمی‌گردد. همچنین، تجزیه خودکار چند-صحنه‌ای در حال حاضر نیازمند یک چارچوب ارکستراسیون دستی (Hand-wired) است و برخی وظایف هنوز در مرز مبهم بین انواع تک-صحنه‌ای و ترکیبی قرار دارند.

این تغییر نشان‌دهنده یک جهش شناختی در مهندسی عامل‌هاست: گذار از خوش‌بینیِ «بگذار مدل خودش بفهمد» به نظمِ «طراحی سیستم». این درک این نکته است که یک «صحنه» باید اتمی (مسئولیت واحد) باشد، در حالی که یک «جریان» (Flow) ترکیبی است (اتمی‌ها را برای رسیدن به یک هدف پیچیده سازماندهی می‌کند). این‌ها دو سطح انتزاع در دانه‌بندی‌های متفاوت هستند.

برای کسانی که عامل‌های تجاری می‌سازند، چالش بعدی «مشاهده‌پذیری» (Observability) است. پیاده‌سازی سه‌گانه‌ای از دروازه‌ها، ممیزی‌ها و رسوب اصلاحات (Correction Sedimentation)، تنها راه برای اطمینان از این است که یک عامل در محیط عملیاتی از طریق یک حلقه بازخورد بسته، به طور مداوم بهبود یابد.

گام بعدی شما

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

اما داستان چالش‌های نظارتی در این سیستم‌ها حتی پیچیده‌تر است — به تحلیل ما درباره‌ی «سه‌گانه نظارتی» در عامل‌های AI مراجعه کنید.