تیپ #۲۹

ردیابی؛ ببینید ایجنت کجای مسیر اشتباه کرد

وقتی یک ایجنت چندمرحله‌ای شکست می‌خورد، بدون ردیابی هیچ راهی ندارید بفهمید مشکل از کدام فراخوانی مدل یا کدام ابزار بوده است. ردیابی هر فراخوانی مدل، هر tool call و هر بازیابی را در قالب یک اسپن با ورودی، خروجی، تأخیر، تعداد توکن و خطا ثبت می‌کند 🔍 و اسپن‌ها را تودرتو می‌چیند تا کل مسیر اجرا قابل بازپخش باشد. آن را از همان روز اول با OpenTelemetry یا ردیاب داخلی فریم‌ورک‌تان فعال کنید، چون trace تن‌ها سندی است که نشان می‌دهد ایجنت چرا چنین تصمیمی گرفت، نه فقط این‌که در نهایت چه گفت.

توضیح کامل‌تر

ردیابی یعنی ثبت ساختاریافته‌ی هر کاری که ایجنت در طول یک اجرا انجام می‌دهد. هر فراخوانی مدل، هر tool call، هر جست‌وجو در پایگاه دانش و هر تصمیم میانی به شکل یک اسپن ذخیره می‌شود و این اسپن‌ها با رابطه‌ی والد و فرزند به هم وصل می‌شوند تا یک درخت کامل از اجرا ساخته شود. مزیت اصلی همین ساختار درختی است: وقتی اجرا کند یا گران می‌شود، می‌توانید ببینید کدام شاخه وقت و توکن را خورده است. برای مثال فرض کنید ایجنت پشتیبانی مشتری بعد از پنج گام پاسخ اشتباه می‌دهد؛ در trace مشخص می‌شود که در گام دوم شناسه‌ی سفارش نادرستی به ابزار استعلام سفارش پاس داده شده و بقیه‌ی زنجیره روی همان خطا بنا شده است. بدون این داده‌ها فقط می‌توانید حدس بزنید و هر بار باید کل مکالمه را دستی بازسازی کنید. استانداردهایی مثل OpenTelemetry با قراردادهای معنایی GenAI کمک می‌کنند نام اسپن‌ها، نام مدل، تعداد توکن و وضعیت خطا در همه‌ی سرویس‌ها یکسان ثبت شود. نکته‌ی مهم این است که ردیابی را از همان ابتدا و پیش از رفتن ایجنت به محیط تولید فعال کنید، چون بازسازی گذشته تقریباً غیرممکن است.