داده‌های واقعی در برابر توهمات مدل؛ استراتژی جدید عامل‌های لاراول

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

برای حل این چالش، در ۱۷ ژوئیه ۲۰۲۶، آدیتیا کومار (Aditya Kumar)، مدیر فنی، الگویی را منتشر کرد که به مدل‌های هوش مصنوعی اجازه می‌دهد مستقیماً با سرویس‌های داخلی و پایگاه‌داده‌ها تعامل کنند. این رویکرد از قابلیت «فراخوانی ابزار» (Tool Calling) بهره می‌برد تا مدل‌ها بتوانند با سرویس‌های داخلی ارتباط برقرار کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش ۶۳.۵ درصدی توکن‌ها با استفاده از فراخوانی برنامه‌ریزی‌شده اشاره کردیم، کلید این تحول در ایجاد یک حلقهٔ اجرای عملیاتی در محیط PHP است.

در این ساختار، هوش مصنوعی زاینده (Generative AI) — شبیه دستیاری است که دستورات را می‌فهمد اما برای اجرای آن‌ها نیاز دارد ابزارهای میز کار را بشناسد — از طریق مکانیزمی به نام فراخوانی تابع (Function Calling) عمل می‌کند. تصور کنید مشتری وضعیت ارسال یک سفارش را می‌پرسد؛ به جای حدس زدن، عامل یک کلاس PHP خاص را فعال می‌کند تا وضعیت واقعی سفارش را واکشی کند. این اتفاق، یک رابط چت ایستا را به عاملی تبدیل می‌کند که قادر به انجام کارهای عملیاتی نظیر تریاژ پشتیبانی، تولید گزارش و جست‌وجوی سفارش‌ها است. این تحول در اکوسیستم PHP مشابه رویکردهایی است که در زبان‌های دیگر نیز در حال گسترش است؛ برای مثال، قابلیت اجرای گردش‌کارهای عامل‌محور در Spring AI 2.0 تحول مشابهی را برای توسعه‌دهندگان جاوا به ارمغان آورد.

معماری این عامل

طبق گزارش منتشر شده در dev.to، این سامانه بر سه مؤلفه ساده لاراول استوار است: یک AgentController برای مدیریت پیام‌های کاربر، یک AgentRunner برای کنترل حلقه منطقی و یک ToolRegistry برای متصل کردن توابع به کلاس‌ها. طبق این گزارش، طراحی سیستم یک توالی سخت‌گیرانه را دنبال می‌کند: پیام کاربر به کنترلر می‌رسد، رانر حلقه را مدیریت می‌کند و ابزارها نتایجی ارائه می‌دهند که دوباره به لیست پیام‌ها اضافه شده تا مدل نهایی را ترکیب و سنتز کند.

پیاده‌سازی فنی طبق مستندات کومار در سه مرحله و طی یک قرارداد مشخص رخ می‌دهد:

• رابط ابزار (Tool Interface): این رابط در مسیر app/Ai/Tools/Tool.php قرار دارد. هر ابزار باید چهار متد اصلی را تعریف کند: name() برای نام ابزار، description() برای توصیف کاربرد، متد parameters() که یک JSON Schema برای آرگومان‌ها بازمی‌گرداند، و متد handle(array $args) که خروجی آن باید یک رشته (String) باشد. دلیل بازگشت رشته این است که داده‌ها باید در جریان گفتگو جاری شوند؛ داده‌های ساختاریافته نیز صرفاً به صورت JSON-encoded بازگردانده می‌شوند.
• ابزارهای عملیاتی: برای مثال، ابزار OrderLookupTool در مسیر app/Ai/Tools/OrderLookupTool.php با استفاده از Eloquent ORM لاراول پیاده شده است. این ابزار طرح‌واره‌ای (Schema) تعریف می‌کند که نیاز به یک order_number (مثلاً "ORD-2041") دارد و در نهایت شماره سفارش، وضعیت، نام اقلام و تاریخ ارسال (shipped_at) را بازمی‌گرداند. در اینجا استفاده از ابزارهای تخصصی برای اعتبارسنجی داده‌ها حیاتی است؛ رویکردی که در پلتفرم Verifly برای حذف ثبت‌نام‌های جعلی در عامل‌های هوشمند با استفاده از سرورهای MCP پیاده‌سازی شده است.
• حلقه منطقی: بخش AgentRunner در مسیر app/Ai/AgentRunner.php مدیریت گفتگو را از طریق Http::post به API OpenAI (با استفاده از مدل gpt-4.1-mini) بر عهده دارد. برای جلوگیری از ایجاد حلقه‌های بی‌نهایت و اتلاف توکن‌ها، این رانر مدل را به حداکثر ۵ دور اجرا محدود می‌کند.

نرده‌های ایمنی در محیط عملیاتی

بزرگ‌ترین نگرانی هنگام دادن «دسترسی به کیبورد» به یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — بحث امنیت است. کومار تأکید می‌کند که احراز هویت و مجوزها (Authorization) باید در کد PHP زندگی کنند، نه در پرامپت. به طور مشخص، افزودن شرط ->where('user_id', auth()->id()) به پرس‌وجوی دیتابیس، حیاتی‌ترین خط دفاعی است. از آنجایی که یک مهاجم می‌تواند با یک پرامپت مهندسی‌شده، فراخوانی ابزارها را هدایت کند، هر ابزار باید مانند یک Endpoint عمومی API در نظر گرفته شود و امنیت آن در سطح کد تضمین گردد.

برای حفظ پایداری سیستم، معماری مذکور چندین محدودیت اجباری را دیکته می‌کند:

• MAX_ROUNDS: سقف ۵ دور برای جلوگیری از رفتارهای «پینگ‌پونگی» مدل بین ابزارها که می‌تواند باعث شود کاربر سی ثانیه منتظر چرخش آیکون لودینگ بماند و توکن‌ها بیهوده مصرف شوند.
• مدیریت تدافعی آرگومان‌ها: متدهای ToolRegistry::execute() باید ورودی‌های مدل را با احتیاط json_decode کنند. نبود کلیدهای مورد نیاز یا نوع داده‌های اشتباه باید به عنوان اتفاقات روتین در نظر گرفته شوند، نه به عنوان Exception یا خطای سیستمی.
• بازیابی خطا: ابزارها نباید Exception پرتاب کنند، بلکه باید خطاها را به عنوان داده (JSON) بازگردانند. برای مثال، اگر ابزاری شکست بخورد، یک پیام خطای JSON برمی‌گرداند. این کار به مدل اجازه می‌دهد تا با اصلاح آرگومان‌ها دوباره تلاش کند یا کاربر را به شکلی مودبانه مطلع سازد.
• قابلیت مشاهده (Observability): هر فراخوانی ابزار باید شامل نام، آرگومان‌ها، مدت زمان اجرا و حجم نتیجه ثبت (Log) شود. این لاگ برای عیب‌یابی زمانی که عامل رفتاری غیرمنتظره دارد، ضروری است.
• استراتژی تست: هر متد handle() یک قطعه کد PHP ساده است و باید مستقیماً با Unit Test تست شود. کل حلقه منطقی نیز باید با یک Integration Test و با استفاده از Http::fake() اعتبارسنجی گردد.

تحلیل هزینه و عملکرد

هر دور از این حلقه، یک فراخوانی کامل API است که کل تاریخچه گفتگو به اضافه تمام طرح‌واره‌های (Schemas) ابزارهای ثبت‌شده را حمل می‌کند. این بدان معناست که یک پاسخ ۳ دوره‌ای با ۵ ابزار فعال، می‌تواند ۳ تا ۵ برابر بیشتر از یک چت ساده توکن مصرف کند.

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

در مدل gpt-4.1-mini، هزینه هر گفتگوی موفق در این سیستم به‌طور میانگین کمتر از یک سنت است. این هزینه با توجه به کاهش زمان مورد نیاز مهندسان برای کارهای تکراری استخراج داده، کاملاً به‌صرفه و جبران‌شده است.

این حلقه همگام (Synchronous) برای جست‌وجوهای سریع عالی است، اما برای کارهای سنگین‌تر — مانند تولید گزارش‌هایی از میلیون‌ها ردیف داده یا ابزارهایی که اجرای آن‌ها ۳۰ ثانیه زمان می‌برد — نیاز به تغییر رویکرد به سمت Queue-based Jobs است. انتقال حلقه عامل به یک Worker پس‌زمینه، امکان به‌روزرسانی وضعیت پیشرفت، تلاش مجدد (Retry) و تعریف بودجه توکن بدون مسدود کردن رابط کاربری را فراهم می‌کند. این گذار به «گردش‌کارهای هوش مصنوعی مبتنی بر صف»، تمرکز بخش بعدی این مجموعه خواهد بود.

گام بعدی شما

• بررسی مستندات JSON Schema برای تعریف دقیق پارامترهای هر ابزار جهت کاهش خطای مدل
• پیاده‌سازی لایه Middleware در لاراول برای کنترل سطح دسترسی (ACL) هر ابزار به‌صورت مجزا
• تست مدل‌های کوچک‌تر (مثل Llama 3) در محیط میزبانی شخصی برای کاهش هزینه استنتاج

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