رصدپذیری ایجنت هوش مصنوعی: پنج ردی که باید از روز اول ثبت کنید

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

رصدپذیری (Observability) برای سرویس‌های معمولی حل‌شده است: زمان پاسخ، نرخ خطا، مصرف منابع. برای ایجنت‌ها این ابزارها تقریباً بی‌فایده‌اند، چون بدترین شکست‌ها هیچ خطایی تولید نمی‌کنند. ایجنت با موفقیت پاسخ می‌دهد. پاسخ فقط غلط است.

پس چیز دیگری باید ثبت شود.

چرا رصدپذیری ایجنت با رصدپذیری سرویس فرق دارد

در یک سرویس معمولی شما مسیر اجرا را از کد می‌خوانید؛ در یک ایجنت، مسیر اجرا خودش یک خروجی است که در زمان اجرا ساخته می‌شود.

این تفاوت همه چیز را عوض می‌کند. کد سرویس ثابت است و لاگ فقط می‌گوید کدام شاخه رفته. ایجنت در هر اجرا تصمیم می‌گیرد چه ابزاری صدا بزند، با چه ترتیبی، و کِی متوقف شود. اگر آن تصمیم‌ها ثبت نشوند، بازسازی یک شکست غیرممکن است — شما فقط ورودی و خروجی نهایی را دارید و بین آن دو یک جعبهٔ سیاه.

رد اول: پرامپت نهایی، بعد از همهٔ جایگزینی‌ها

تقریباً هیچ‌کس پرامپتِ خامی را که در کد نوشته، به مدل نمی‌فرستد. یک قالب دارد، متغیرها جایگزین می‌شوند، نتایج بازیابی (Retrieval) به آن اضافه می‌شود، تاریخچهٔ گفتگو چسبانده می‌شود.

آنچه باید ثبت شود، رشتهٔ نهایی است — دقیقاً همان چیزی که به مدل رفت. اکثر تیم‌ها قالب را لاگ می‌کنند و بعد ساعت‌ها دنبال باگی می‌گردند که در یکی از جایگزینی‌ها بوده. یک سند بازیابی‌شدهٔ نامرتبط، پرامپت را ۴۰۰۰ توکن طولانی‌تر می‌کند و رفتار مدل را عوض می‌کند، بدون اینکه هیچ‌جا دیده شود.

رد دوم: فراخوانی ابزارها با آرگومان و حجم پاسخ

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

حجم پاسخ معمولاً فراموش می‌شود و بیشترین ارزش تشخیصی را دارد. یک کوئری که به‌جای ۵ رکورد، ۵۰۰ رکورد برمی‌گرداند نه خطا می‌دهد و نه کند است — فقط پنجرهٔ زمینه را پر می‌کند و ایجنت بقیهٔ دستورها را فراموش می‌کند. در لاگ، این فقط یک عدد است که ناگهان صد برابر شده.

رد سوم: توکن و هزینه به‌ازای هر گام، نه هر درخواست

هزینهٔ کل درخواست به شما می‌گوید ماه گران بوده. هزینهٔ هر گام به شما می‌گوید کدام گام گران بوده.

در عمل، معمولاً یک گام هشتاد درصد هزینه را می‌سوزاند و تا زمانی که در سطح گام اندازه نگیرید، دیده نمی‌شود.

رد چهارم: تصمیم ارجاع — و آن یکی که گرفته نشد

وقتی ایجنت به انسان ارجاع می‌دهد، دلیلش را ثبت کنید: اطمینان پایین، نبود دسترسی، یا قانون صریح.

سخت‌تر و مهم‌تر: مواردی که نزدیک آستانهٔ ارجاع بودند و ارجاع نشدند. اگر آستانهٔ اطمینان ۰.۷ است، هر موردی که بین ۰.۷ و ۰.۷۵ تصمیم گرفته را جدا نگه دارید. این‌ها فهرست شکست‌های بعدی شما هستند.

چرا این پنج‌تا و نه بیشتر

می‌شود بیست چیز را ثبت کرد و بیشتر تیم‌هایی که سراغ رصدپذیری می‌روند دقیقاً همین کار را می‌کنند. نتیجه، حجمی از داده است که هیچ‌کس نگاهش نمی‌کند.

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

معیار ساده برای هر ردی که می‌خواهید اضافه کنید: نام ببرید کدام تصمیم را با آن متفاوت خواهید گرفت. اگر پاسخی نداشتید، اضافه‌اش نکنید.

رد پنجم: کنش بعدی کاربر

این تنها سیگنال واقعی کیفیت است و اغلب اصلاً ثبت نمی‌شود.

کاربر بعد از دیدن پاسخ چه کرد؟ بست و رفت؟ دوباره همان سؤال را با جملهٔ دیگری پرسید؟ به انسان وصل شد؟ اقدام پیشنهادی را انجام داد؟ بازنویسی سؤال، قوی‌ترین نشانهٔ پاسخ بی‌فایده است و هیچ ارزیابی خودکاری آن را نمی‌بیند.

یک نمونهٔ واقعی: باگی که هیچ خطایی نداشت

یک ایجنت پشتیبانی چند هفته درست کار می‌کرد و بعد کیفیتش آرام افت کرد. هیچ خطایی در لاگ نبود، تأخیر ثابت، هزینهٔ ماهانه کمی بالاتر — در حدی که به رشد ترافیک نسبت داده شد.

وقتی هزینه در سطح گام ثبت شد، معلوم شد گام بازیابی به‌طور میانگین از ۹۰۰ به ۶۱۰۰ توکن رفته. علتش یک تغییر بی‌ضرر بود: کسی فیلد یادداشت‌های داخلی را به ایندکس اضافه کرده بود. آن یادداشت‌ها اغلب طولانی و بی‌ربط بودند، پنجرهٔ زمینه را پر می‌کردند، و دستور «اگر مطمئن نیستی ارجاع بده» عملاً از انتهای پرامپت بیرون می‌افتاد.

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

یک شناسه که همه چیز را به هم می‌دوزد

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

پس یک شناسهٔ اجرا (run id) در اولین لحظه تولید کنید و آن را در همهٔ گام‌ها، همهٔ فراخوانی‌های ابزار و همهٔ لاگ‌های سرویس‌های پایین‌دستی حمل کنید. این ساده‌ترین کار کل این فهرست است و اگر از روز اول انجام نشود، اضافه‌کردنش بعداً به معنی دست‌زدن به هر مسیر کد است.

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

پیش از نوشتن هر لاگ، چه چیزی را حذف کنید

پرامپت نهایی شامل دادهٔ مشتری است. این یعنی لاگ ایجنت شما یک انبار دادهٔ حساس است که کسی برایش سیاست تعریف نکرده.

• شماره تماس، ایمیل و شناسه‌های ملی را پیش از نوشتن پاک کنید، نه هنگام نمایش.
• برای اسناد بازیابی‌شده، شناسه و طول را ثبت کنید، نه متن کامل را.
• مدت نگهداری تعیین کنید. سی تا نود روز برای تشخیص کافی است.

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

آیا برای این کار به ابزار تخصصی نیاز است؟

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

ثبت پرامپت کامل چقدر هزینه دارد؟

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

از کجا شروع کنم اگر سیستم همین حالا در حال کار است؟

با رد سوم و چهارم شروع کنید. هزینهٔ هر گام و نرخ ارجاع را می‌شود بدون تغییر معماری اضافه کرد و بیشترین سیگنال را در کمترین کار می‌دهند.

جمع‌بندی

یک ایجنت بدون این پنج رد، سیستمی است که فقط می‌توانید دربارهٔ آن نظر بدهید. با آن‌ها، سیستمی است که می‌توانید تعمیرش کنید.

این لایه همان چیزی است که تفاوت بین یک نمونهٔ اولیه و یک ایجنت عملیاتی را می‌سازد.