تراکم بیش از حد داده‌ها دقت عامل‌های هوش مصنوعی را کاهش می‌دهد

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

این چالشی است که خالق Zugrow، یک پلتفرم مدیریت املاک با محوریت هوش مصنوعی، با آن روبرو شد. او که ۲۳ ملک اجاره‌ای کوتاه مدت را مدیریت می‌کرد، دریافت که افزایش حجم زمینه (Context) اغلب باعث کاهش عملکرد عامل‌های هوش مصنوعی می‌شود. او متوجه شد که برخورد با زمینه به عنوان یک «توده عظیم از متن»، منجر به دفن شدن اطلاعات حیاتی می‌شود و باعث می‌شود عامل‌ها، حتی با وجود استفاده از مدل‌های با کیفیت بالا، تصمیمات اشتباه بگیرند. این پدیده با یافته‌های علمی همسو است؛ برای مثال، مطالعه‌ای از دانشگاه پن استیت نشان داد که در برخی سیستم‌ها بخش بزرگی از دستورات کاربران در هنگام فشرده‌سازی حافظه هوش مصنوعی حذف می‌شوند.

در چنین سناریوهایی، پاسخ به متغیرهای لحظه‌ای بستگی دارد: وضعیت رزرو، قوانین خاص هر ملک، ترتیبات فعلی پارکینگ، وضعیت پذیرش (Check-in)، به‌روزرسانی‌هایی که پس از نوشتن متن آگهی رخ داده و حتی احتمالاً نظری که یکی از اعضای تیم ۲۰ دقیقه پیش ثبت کرده است. توسعه‌دهنده دریافت که یک عامل می‌تواند مدل بسیار خوبی داشته باشد اما اگر «وضعیت» (State) اشتباهی به آن داده شود، همچنان تصمیمی غلط بگیرد.

بسیاری از توسعه‌دهندگان با این غریزه شروع می‌کنند که داده بیشتر یعنی جواب بهتر. در سناریوی پیام‌رسانی با مهمان، منطقی به نظر می‌رسد که تمام قوانین خانه، امکانات، یادداشت‌های داخلی، توضیحات ملک، کل تاریخچه گفتگوها، جزئیات رزرو، سؤالات مهمانان قبلی و دستورالعمل‌های میزبان را در اختیار عامل قرار دهند. اما این رویکرد یک «هرج‌ومرج اطلاعاتی» ایجاد می‌کند که در آن مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — نمی‌تواند حقیقت مورد نیاز برای یک پرسش خاص را از میان نویزها استخراج کند. این مشکل شباهت زیادی به پدیده پوسیدگی زمینه در عامل‌های کدنویسی دارد که در آن حجم زیاد داده‌های غیرضروری، بازدهی مدل را کاهش می‌دهد.

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

معماری دقت و کنترل

بر اساس مستندات این پروژه، چندین تغییر کلیدی برای افزایش قابلیت اطمینان اعمال شد:

• ترجیح وضعیت ساختاریافته بر متن: متون تبلیغاتی برای انسان‌ها نوشته شده‌اند، اما عامل‌ها به وضعیت ساختاریافته نیاز دارند. به جای تغذیه مدل با متون بازاریابی مانند «پارکینگ برای مهمانان موجود است»، آن‌ها از وضعیت صریح استفاده می‌کنند: { parkingAvailable: true, guaranteedSpaces: 1, extraSpacesRequireApproval: true }. به همین ترتیب، به جای عبارات مبهمی مثل «ورود زودهنگام ممکن است گاهی در دسترس باشد»، داده‌های دقیق را ذخیره می‌کنند: { standardCheckIn: "15:00", earlyCheckInAllowed: true, earliestPossibleTime: "13:00", requiresTeamApproval: true }. این کار مانع از آن می‌شود که مدل زبان مبهم را تفسیر کرده و وعده‌های غیرمجاز بدهد.
• تفکیک واقعیت از سیاست: سیستم بین «آنچه در جهان هست» (واقعیت‌ها/Facts) و «آنچه عامل اجازه دارد انجام دهد» (سیاست‌ها/Policy) تمایز قائل می‌شود. برای مثال، واقعیت‌ها ممکن است این باشند: { parkingType: "allocated", primaryBay: "14", additionalSpacePossible: true } در حالی که سیاست این است: { mayGuaranteeAdditionalSpace: false }. این تفکیک حیاتی است زیرا واقعیت‌ها مکرراً تغییر می‌کنند، اما سیاست‌ها به ندرت تغییر می‌کنند. همچنین به اپلیکیشن اجازه می‌دهد قوانین را بدون تکیه بر حافظه مدل اجرا کند. در واقع، ایجاد یک لایه محدودیت‌های صریح می‌تواند مانع از شکست عامل‌های داده‌محور در محیط‌های سازمانی شود.
• تازگی داده‌ها: آن‌ها نوع ContextValue<T> را معرفی کردند که مقدار، تاریخ به‌روزرسانی (updatedAt) و منبع (میزبان، سیستم، کانال یا عامل) را ردیابی می‌کند. این موضوع مشکلی را حل می‌کند که در آن یک حقیقت در پایگاه داده درست است اما در واقعیت قدیمی شده است؛ مثلاً وضعیت وای‌فای دیروز «سالم» ثبت شده اما امروز مودم سوخته است. اگر برچسب زمانی updatedAt قدیمی‌تر از ۷۲ ساعت باشد، سیستم می‌تواند یک بررسی requireVerification() را فعال کند یا از عامل بخواهد با احتیاط پاسخ دهد.

• تاریخچه مبتنی بر رویداد: به جای ارسال متن ۷۰ پیام از یک اقامت دو هفته‌ای، سیستم تاریخچه را به «وضعیت فعلی» و «رویدادهای اخیر» تبدیل می‌کند. برای سؤال «ساعت خروج فردا چند است؟»، مدل یک شیء زمینه دریافت می‌کند که شامل رزرو فعلی، واقعیت‌های مرتبط با ملک و لیستی از recentEvents (مانند پیام خاص مهمان و وضعیت درخواست‌های خروج دیر هنگام) است. این تضمین می‌کند که مدل روی وظیفه فوری تمرکز کند و توسط گفتگوهای بی‌ربط گذشته منحرف نشود.

پر کردن شکاف هم‌زمانی

یکی از حیاتی‌ترین یافته‌ها، فاصله بین «تصمیم» و «اقدام» است. توسعه‌دهنده به یک مشکل خاص در هم‌زمانی (Concurrency) اشاره کرد: در ثانیه ۱۰:۰۰:۰۰ مهمان درخواست ورود زودهنگام می‌دهد؛ در ثانیه ۱۰:۰۰:۰۲ عامل موجود بودن اتاق را می‌خواند؛ در ثانیه ۱۰:۰۰:۰۸ نظافتچی برنامه را تغییر می‌دهد و در ثانیه ۱۰:۰۰:۱۱ عامل ورود را تأیید می‌کند. مدل بر اساس اطلاعاتی که داشت درست تصمیم گرفت، اما سیستم در کل تصمیم اشتباهی گرفت.

برای رفع این مورد، Zugrow یک مرحله اعتبارسنجی قطعی (Deterministic) اضافه کرد. مدل برای تصمیم‌گیری درباره آنچه «دوست دارد» انجام دهد (پیشنهاد یا suggestion) استفاده می‌شود، اما سپس اپلیکیشن latestState (آخرین وضعیت) را از پایگاه داده رزروها فراخوانی می‌کند. اگر پیشنهاد بر اساس آخرین وضعیت دیگر معتبر نباشد، سیستم یک محرک requireHumanReview() (درخواست بازبینی انسانی) برمی‌گرداند. این بررسی دوم، برای پایداری بسیار مؤثرتر از این است که ۵۰۰ کلمه به پرامپت اضافه کنید.

ردپای حسابرسی

برای عیب‌یابی «اشتباهات هوش مصنوعی»، تیم رابط AgentTrace را پیاده کرد. این رابط، شناسه عامل، نسخه زمینه (contextVersion)، ورودی، تصمیم، مدل مورد استفاده و برچسب زمانی را ثبت می‌کند. با ثبت دقیق آنچه مدل در لحظه تصمیم‌گیری «حقیقت» می‌پنداشت، تیم دریافت که بسیاری از توهمات ظاهری AI، در واقع خطاهای نرم‌افزاری در لایه‌های بالادستی بودند. این خطاها شامل مواردی چون لینک شدن ملک اشتباه، ارائه داده‌های قدیمی، فیلدهای خالی یا وضعیت نادرست رزرو بود.

جریان کاری نهایی به این شکل است: پیام مهمان $ \rightarrow $ تشخیص قصد/وظیفه $ \rightarrow $ سازنده زمینه $ \rightarrow $ وضعیت فعلی مرتبط $ \rightarrow $ تصمیم AI $ \rightarrow $ اعتبارسنجی قطعی $ \rightarrow $ بازبینی مجدد وضعیت $ \rightarrow $ اقدام یا تأیید انسانی $ \rightarrow $ ثبت در لاگ حسابرسی.

این چرخش، LLM را از «خودِ اپلیکیشن» به «یک قطعه در میان یک خط لوله نرم‌افزاری» تبدیل می‌کند. این یعنی پایداری در سامانه‌های عامل‌محور، حاصل مهندسی نرم‌افزار کلاسیک (مدیریت وضعیت، کنترل هم‌زمانی و ثبت لاگ) است، نه مهندسی پرامپت (Prompt Engineering). توسعه‌دهنده نسبت به الگوی رایج نمونه‌سازی اولیه هشدار می‌دهد: داده $ \rightarrow $ پرامپت عظیم $ \rightarrow $ مدل $ \rightarrow $ اقدام. این الگو از یک مدل احتمالی می‌خواهد که کمبودهای معماری اپلیکیشن را جبران کند.

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

گام بعدی شما

• لاگ‌های زمینه (Context Logs) خود را بررسی کنید تا ببینید مدل شما به دلیل ضعف در استدلال شکست می‌خورد یا به دلیل دریافت نسخه‌ای تحریف‌شده از واقعیت.
• داده‌های ورودی به مدل را از متون توصیفی به فرمت‌های ساختاریافته (JSON) تبدیل کنید.
• یک لایه اعتبارسنجی قطعی بعد از تصمیم مدل و قبل از اجرای عملیات در دنیای واقعی قرار دهید.

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