برنامهنویسی که ساعتها وقت خود را صرف تعقیب حدسهای متناقض هوش مصنوعی میکند، احتمالاً نمیداند مشکل از هوش مدل نیست، بلکه از نبود دادههای اثباتی است. در ۶ اوت ۲۰۲۶، مایانک کال (Mayank Kaul)، معمار نرمافزار، با ارائه یک تحلیل دقیق نشان داد که پیروزی در «بازی» دیباگینگ با هوش مصنوعی نه در انتخاب مدل قدرتمندتر یا گرانتر، بلکه در کاهش میزان حدسزنیهایی است که مدل مجبور به انجام آنهاست. در نهایت، یک مجموعه عینی از سوابق اجرا برای شکار باگها بسیار ارزشمندتر از یک مدل پیشرفتهتر است.
بسیاری از توسعهدهندگان با مدلهای زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — مانند یک آینه جادویی برخورد میکنند. آنها کد یک مخزن (Repository) را به مدل میدهند، میپرسند چرا چیزی در سیستم شکست خورده است و پاسخی دریافت میکنند که با اعتمادبهنفسی بالا همراه است اما اغلب نادرست است. مشکل اساسی اینجاست که این پاسخها، چه بر اساس شواهد واقعی باشند و چه بر اساس آنچه «معمولاً» در یک کدبیس معمولی اتفاق میافتد، ظاهر یکسانی دارند. در واقع، همان اطمینانِ مدل در پاسخدهی است که مشکل ایجاد میکند، نه اینکه مهندس را آرام دهد. این چالش با آنچه در تحلیلهای پیشین درباره تأثیر مخرب دادههای خام بر عملکرد عاملهای هوش مصنوعی دیدیم، همسو است؛ جایی که کیفیت ورودی تعیینکننده خروجی است.
کال برای آزمایش این فرضیه، یک سؤال دیباگینگ یکسان را روی سه مدل مختلف، شامل Claude 3.5 Sonnet، Claude 3 Opus و Fable اجرا کرد. او برای این کار از چهار سطح افزایشیافته از شواهد استفاده کرد. هدف او در اینجا صرفاً یافتن یک باگ نبود، بلکه میخواست بفهمد اتفاقی که پیشتر رخ داده است، دقیقاً چگونه به وقوع پیوسته است. او دریافت وقتی شواهد بهگونهای فراهم شوند که نیاز به حدس زدن را بهطور کامل حذف کنند، توانایی مدل در حدس زدن دیگر هیچ اهمیتی نخواهد داشت.
چهار پلهٔ شواهد
چارچوب کال یک سلسلهمراتب از زمینه (Context) را تعریف میکند. در این مدل، هر «پله» صرفاً دادههای بیشتر اضافه نمیکند، بلکه در واقع هر پله چیزی را میگیرد که مدل در غیر این صورت مجبور بود درباره آن حدس بزند:
- پله ۱: دسترسی گسترده به مخزن کد: در این سطح، مدل به همه چیز دسترسی دارد. پاسخها از نظر ساختاری منطقی به نظر میرسند اما بهکرات قطعات و کامپوننتهایی را نام میبرند که اصلاً در باگ دخیل نیستند. نکته تکاندهنده این است که این پاسخهای غلط با همان میزان اطمینان و بدون هیچ تردیدی نسبت به پاسخهای درست ارائه میشوند. این همان نقطهای است که بیشتر تیمها متوقف شده و به این نتیجه میرسند که ابزارهای AI «هنوز آماده نیستند».
- پله ۲: مخازن محدودشده + نقشه مکتوب: در این مرحله، سه مخزن محدود (Bounded Repositories) و نقشهای از اینکه کدام سرویس با کدام سرویس صحبت میکند، اضافه میشود. این نقشه شامل پروتکلهای ارتباطی و تضمینهای مربوط به تحویل و ترتیب ارسال پیامهاست. این کار نیاز به «کشف مجدد» مسیرها توسط مدل را حذف میکند. موفقیت در این پله زمانی حاصل میشود که به مدل دستور داده شود نقشه را به عنوان «حقیقت مطلق» بپذیرد و دوباره آن را چک نکند؛ این کار باعث تمرکز بیشتر مدل میشود اما در عوض، امکان تأیید مجدد (Verification) را از بین میبرد. در اینجا باید به این نکته توجه داشت که افزایش حجم زمینه برای دقت بیشتر، میتواند منجر به جهش هزینههای عملیاتی در خط لولههای زمینه شود.
- پله ۳: اثرها (Traces) و لاگها: افزودن دادههای واقعی اجرا که اجراهای واقعی سیستم را پوشش میدهد. این سطح، حدس زدن درباره توالی اتفاقات و اینکه چه دادهای از یک مرز (Boundary) عبور کرده است را حذف میکند. این مرحله، نزدیکترین حالت ممکن به راه حل است، مگر اینکه شواهدی از «حالت» (State) در اختیار باشد.
- پله ۴: سوابق اجرا (Execution Records): ارائه مجموعهای کوچک از رکوردهایی که رفتار واقعی سیستم را نشان میدهد. در این سوابق، فیلدهای مربوط به مشتری حذف شده و شناسهها جایگزین شدهاند، اما ساختار دادهها کاملاً دستنخورده باقی مانده است. این دادهها دقیقاً فاش میکنند که کد در واقعیت از کدام مسیر (Path) عبور کرده است.
چرخش از استدلال پیشرو به استدلال معکوس
طبق مشاهدات کال، در پله سوم (لاگها)، مدلها معمولاً از استدلال پیشرو (Forward Reasoning) استفاده میکنند: «کد این قابلیتها را دارد، پس احتمالاً این اتفاق افتاده است». اما با رسیدن به پله چهارم (سوابق)، منطق بهطور کامل به استدلال معکوس (Backward Reasoning) تغییر میکند: «با توجه به این مقادیر موجود در این رکورد، قطعاً این شاخه از کد اجرا شده است و آن شاخههای دیگر اجرا نشدهاند».
در یک مورد واقعی مربوط به باگی در یکی از پروژههای شخصی کال، مدل Sonnet — که در پلههای پایینتر، ضعیفترین، مبهمترین و خوشبینترین مدل بود — بهمحض دریافت سوابق اجرا، ناگهان به مؤثرترین مدل تبدیل شد. چون دیگر هیچ چیزی برای حدس زدن باقی نمانده بود، مدل توانست برای مسیر شناساییشده یک تست بنویسد، آن را اجرا کند و در نهایت یک بازتولید (Reproduction) کامل از باگ را تحویل دهد. این رویکرد دقیق در اعتبارسنجی خروجی، یادآور تفاوت میان بررسیهای ساختاری و تستهای سنتی در پالایش پاسخهای هوش مصنوعی است.
این اتفاق به دلیل یک واقعیت معماری ساده رخ میدهد: هر شاخهای از کد که شما لاگ نکنید، در واقع شاخهای است که نمیتوانید احتمال اجرای آن را رد کنید. ثبت (Logging) تمام شاخهها در сервиشی که طی سالها شرطهای پیچیدهای accumulated کرده است، بهدلیل هزینههای بالای ذخیرهسازی، تأخیر در پاسخدهی (Latency) و دشواری در بازبینی کد، نادیده گرفته میشود. یک رکورد از یک اجرای آسیبدیده، این ابهام را برطرف میکند، به شرطی که مقدار تصمیمگیرنده در آن لحظه ذخیره شده باشد و توسط یک نوشتنِ بعدی پاک نشده باشد.
تحلیل: هزینهٔ یک «حدس خوب»
برای یک توسعهدهنده عملیاتی، این یافته یک تلهٔ خطرناک را فاش میکند: تعقیب یک حدس محتمل (Plausible Guess)، دقیقاً به اندازه تعقیب یک حقیقت هزینه دارد. شما تفاوت این دو را تنها در پایان بررسی و تحقیقات خود متوجه میشوید. در تجربه کال، دو مورد از حدسهای مدل او را به سمت بررسی چیزهایی فرستاد که قبلاً چک نکرده بود؛ یکی از آنها یک بنبست محض بود و دیگری یک مشکل واقعی بود که کال از آن بیخبر بود. نکته کلیدی این است که هیچکدام از این دو پاسخ، نشانهای نداشت که کدام یک حقیقت است و کدام یک حدس.
وقتی مدل بدون داشتن شواهد «خوشبین» است، سطحی از اطمینان ایجاد میکند که میتواند مهندسان را به بنبستهای بسیار هزینهبر بکشاند. نگرانکنندهترین حالت، زمانی است که مدل در وضعیتی درست قبل از داشتن شواهد کافی قرار دارد؛ جایی که دادهها برای ساخت یک فرضیه واقعی کافی هستند، اما برای تفکیک یک حقیقت واقعی از یک حدس محتمل، کافی نیستند.
این یافته، هدف مهندسی AI را از «پرامپتنویسی برای استدلال بهتر» به «مهندسی خط لوله شواهد» تغییر میدهد. گلوگاه دیگر هوش مدل زبانی نیست، بلکه توانایی فنی و قانونی برای استخراج سوابق پاکسازیشده (Sanitized) از محیط عملیاتی (Production) است. در یک پروژه شخصی، گرفتن سوابق با یک کوئری ساده ممکن است، اما در یک محیط شرکتی، این یک مسئله حقوقی است که احتمالاً سالها پیش پاسخ آن داده شده و ممنوع شده است.
ابزارهای دیباگینگ
برای پیادهسازی این رویکرد، کال پیشنهاد میکند که توسعهدهندگان مجموعهای از مصنوعات (Artifacts) خاص را حفظ کنند:
- نقشههای ارتباطی آمادهمدل: نقشههای کوتاهی برای هر سرویس که شامل تضمینهای تحویل و ترتیب پیامها باشد (چون هیچ کدبیسی این موارد را بهطور صریح بیان نمیکند). این نقشهها باید بهجای نگهداری دستی، هنگام هر Merge بهطور خودکار بازتولید شوند.
- تاریخهای اعتبارسنجی: درج تاریخ آخرین تأیید روی نقشه؛ زیرا مدل دستور میگیرد که به نقشه اعتماد کند و نقشهها ممکن است بهسادگی و بدون خبر دادن، قدیمی و منسوخ شوند.
- اسکریپتهای استخراج داده با آگاهی از فیلد: اسکریپتهایی که در زمانی نوشته شوند که «هیچ چیز در حال سوختن نیست» (زمانی که بحران باگ وجود ندارد) تا مقادیر حساس را حذف کنند اما نام فیلدها، برچسبهای زمانی (Timestamps) و پیوندهای (Joins) بین دادهها را حفظ کنند.
مهمتر از همه، توسعهدهندگان باید عادت پرسشگری خود را تغییر دهند. بهجای پرسیدن «چه چیزی غلط است؟»، بپرسند «به نظر تو کدام شاخه از کد اجرا شده است و چه چیزی در دادهها این موضوع را ثابت میکند؟». این سؤال دقیق، تفاوت بین پله سوم و پله چهارم است و میتوان آن را از هر پلهای پرسید.
از این پس، تغییر کوچک در پرسش، تفاوت بین حدس زدن و اثبات است. اما اثر این تغییر بر هزینه استنتاج در مقیاس بزرگ، بحثی پیچیدهتر است — به تحلیل ما درباره هزینه GPUها در محیطهای سازمانی مراجعه کنید.
گفتگو