ردیابی سطری در برابر معیارهای تأخیری برای شناسایی خطاهای کوئری

تصور کنید یک سیستم پاسخ را در ۴۰۰ میلی‌ثانیه و با بهینه‌ترین مصرف توکن برمی‌گرداند، اما اگر کوئری SQL تولید شده یک فیلتر حیاتی را فراموش کرده باشد، داده‌های ارسالی کاملاً غلط خواهد بود. اینجاست که متوجه می‌شویم معیارهای ظاهری (Vanity Metrics) مثل تأخیر p99 و توان عملیاتی توکن‌ها، درباره عملکرد واقعی عامل‌های هوش مصنوعی شما دروغ می‌گویند.

یک سناریوی واقعی و ملموس را در نظر بگیرید: کاربر از عامل می‌خواهد «تمام مشتریانی که در ۳۰ روز گذشته ثبت‌نام کرده‌اند و خریدی نداشته‌اند» را لیست کند. عامل این درخواست را به مراحل مختلف تجزیه می‌کند: تولید یک کوئری SQL، اجرای آن در PostgreSQL، تفسیر نتایج و در نهایت قالب‌بندی پاسخ. داشبورد شما چراغ سبز نشان می‌دهد؛ زمان پاسخ ۴۰۰ میلی‌ثانیه و ۱۲۰۰ توکن تولید شده است. اما کوئری واقعی که عامل نوشته، به این شکل بوده است: SELECT * FROM users WHERE created_at > NOW() - INTERVAL '30 days'؛ یعنی فیلتر مربوط به «عدم خرید» را کاملاً فراموش کرده است. در نتیجه، عامل با اطمینان کامل ۸۴۷ مشتری را برمی‌گرداند، در حالی که پاسخ درست باید تنها ۲۳ نفر می‌بود.

این شکاف در قابلیت مشاهده (Observability) دلیل شکست خاموش بسیاری از عامل‌ها در محیط عملیاتی است. وقتی یک عامل به جای ۲۳ نفر، ۸۴۷ نفر را برمی‌گرداند، هیچ جهشی در نمودار تأخیر رخ نمی‌دهد که باعث فعال شدن هشدار شود. هیچ تعداد توکنی این خطا را علامت‌گذاری نمی‌کند. شما به داشبورد سریع‌تر نیاز ندارید؛ شما به یک کنسول اپراتوری نیاز دارید که ردیف‌های واقعی پایگاه‌داده را در لحظه (Real-time) نمایش دهد.

به نقل از راهنمای فنی منتشر شده در dev.to در ۲۳ سپتامبر ۲۰۲۶، راهکار این مشکل در به‌کارگیری اصول مهندسی قابلیت اطمینان سایت (SRE) در ارکستراسیون عامل‌هاست. SRE سنتی بر این تمرکز دارد که سیستم دقیقاً «چه کاری» انجام می‌دهد، نه اینکه فقط «چقدر سریع» آن را انجام دهد. وقتی یک کاربر در ساعت ۲ صبح مشکلی را گزارش می‌کند، یک مهندس SRE به نمودار تأخیر p99 خیره نمی‌شود؛ بلکه درخواست‌های واقعی در حال جریان در سیستم را تماشا می‌کند، محموله‌ها (Payloads) را بازرسی می‌کند و منشأ شکست را ردیابی می‌کند.

در دنیای عامل‌های هوش مصنوعی، این به معنای عبور از نظارت سطح بالا و رسیدن به سیستمی است که در آن هر کوئری پایگاه‌داده، در کنار قصد اصلی کاربر و استدلال داخلی عامل ثبت شود. در این رویکرد، عامل دیگر یک جعبه سیاه نیست، بلکه مجموعه‌ای از بازه‌های ردیابی‌پذیر (Traceable Spans) در سیستم‌های ناهمگون است. این رویکرد تکاملی در نظارت، مشابه آن چیزی است که TrustGraph برای تبدیل علائم مدل‌های هوش مصنوعی به تحلیل‌های ریشه‌ای به کار می‌گیرد تا نقاط شکست را با دقت شناسایی کند.

چارچوب SRE برای عامل‌ها

دستیابی به قابلیت مشاهده واقعی برای عامل‌ها نیازمند سه اصل کلیدی SRE است که به ندرت در پلتفرم‌های فعلی نظارت بر عامل‌ها پیاده‌سازی می‌شوند:

• تجمیع لاگ‌های ساختاریافته (Structured Log Aggregation): هر لاگ باید دارای یک Trace ID و Span ID باشد. در نظارت بر هوش مصنوعی، این یعنی هر کوئری پایگاه‌داده باید با قصد اصلی کاربر و استدلال عامل ثبت شود. به جای یک پیام کلی مانند «کوئری با موفقیت اجرا شد»، سیستم باید متن دقیق کوئری و مجموعه داده‌های حاصل از آن را ذخیره کند.
• ردیابی توزیع‌شده (Distributed Tracing): از آنجا که عامل‌ها با مدل‌های زبانی بزرگ (LLM)، ذخیره‌سازهای برداری (Vector Stores)، APIها و پایگاه‌های داده تعامل دارند، هر مرحله باید یک بازه (Span) در یک ردیابی واحد باشد. وقتی یک ارکستراسیون شامل زنجیره‌ای از پنج فراخوانی LLM و سه کوئری پایگاه‌داده است، توسعه‌دهندگان باید بتوانند وارد هر بازه شوند تا دقیقاً ببینند چه داده‌ای از آن عبور کرده است.
• بودجه خطای مبتنی بر کیفیت (Quality-Based Error Budgets): مهندسان SRE از بودجه‌های در دسترس بودن (مثلاً ۹۹.۹٪) استفاده می‌کنند تا تصمیم بگیرند چه زمانی انتشار ویژگی‌های جدید را متوقف کنند. تیم‌های توسعه عامل باید «بودجه صحت» (Accuracy Budgets) را پیاده کنند؛ اگر صحت خروجی از یک آستانه تعریف شده پایین‌تر رفت، انتشار نسخه‌ها برای بررسی متوقف شود. اندازه‌گیری این صحت نیازمند دید به این است که عامل «دقیقاً چه کاری انجام داده»، نه اینکه صرفاً «کار را به پایان رسانده است».

برای مثال، یک ردیابی ساختاریافته برای یک عامل می‌تواند به این شکل باشد: یک بازه parse_step با استفاده از مدل claude-sonnet-4-5 استدلال را ثبت می‌کند («کاربر مشتریان ۳۰ روز اخیر با صفر خرید را می‌خواهد») و فراخوانی ابزار تولید شده را ذخیره می‌کند. پس از آن، یک بازه db_exec می‌آید که زمان اجرا (مثلاً ۳۴ میلی‌ثانیه)، تعداد ردیف‌های بازگشتی (۲۳ ردیف) و نمونه‌ای از ردیف‌های واقعی، مانند «سارا کیم» (شناسه ۱۰۴۱۲) ایجاد شده در تاریخ ۲۰۲۵-۰۶-۰۲ را ثبت می‌کند.

طراحی کنسول اپراتور

یک کنسول مؤثر برای اپراتور هوش مصنوعی باید شبیه به اتاق جنگ یک مرکز عملیات شبکه (NOC) باشد. ساختار پیشنهادی از چهار جزء حیاتی تشکیل شده است:

۱. جریان ردیابی (The Trace Stream): یک فید زنده و کدگذاری شده با رنگ از فراخوانی‌ها. رنگ سبز نشان‌دهنده موفقیت، زرد نشان‌دهنده کیفیت کاهش‌یافته (عامل کار را تمام کرده اما با اطمینان کم یا خروجی تأیید نشده) و قرمز نشان‌دهنده شکست کامل است. هر ورودی باز می‌شود تا ردیابی کامل را نشان دهد و به عنوان رابط اصلی برای تماشای درخواست‌های واقعی در لحظه عمل می‌کند.
۲. بازرس داده‌ها (The Data Inspector): پنلی که دقیقاً کوئری تولید شده، پارامترهای آن و نمایی صفحه‌بندی شده از ردیف‌های نتیجه را نمایش می‌دهد. این کار حدس زدن را حذف می‌کند و به اپراتورها اجازه می‌دهد داده‌های واقعی را که عامل مشاهده کرده است، بخوانند. در یک داشبورد لحظه‌ای، این ردیف‌ها همزمان با اجرای کوئری‌ها به‌روزرسانی می‌شوند.
۳. نوار معیارهای کیفیت (The Quality Metrics Bar): یک ردیاب لحظه‌ای در بالای صفحه برای صحت خروجی (اندازه‌گیری شده در برابر حقیقت زمینی یا Ground Truth)، نرخ موفقیت فراخوانی ابزارها، میانگین امتیاز مرتبط بودن پاسخ‌ها و بودجه خطای باقی‌مانده. وقتی دقت افت می‌کند، نوار قرمز شده و هشدار فعال می‌کند.
۴. آشکارساز ناهنجاری (The Anomaly Detector): یک مدل آماری در پس‌زمینه که الگوهای غیرعادی را علامت‌گذاری می‌کند؛ مواردی مانند جهش ناگهانی در مقادیر NULL، تعداد ردیف‌های غیرمنتظره، عدم تطبیق طرحواره (Schema Mismatch) یا الگوهای پاسخی که از هنجارهای تاریخی فاصله دارند.

برای شناسایی انحراف (Drift)، آشکارساز ناهنجاری کوئری‌های SQL خاصی را روی داده‌های ردیابی اجرا می‌کند. برای مثال، می‌تواند دقایقی را نظارت کند که در آن بیش از ۱۵٪ از فراخوانی‌های پایگاه‌داده، صفر ردیف برمی‌گردانند؛ این یک سیگنال کلاسیک است که تولید کوئری عامل از طرحواره واقعی یا وضعیت داده‌ها منحرف شده است. کوئری مورد استفاده برای این تحلیل، zero_row_percentage را از طریق تقسیم zero_row_queries بر total_queries در یک بازه یک ساعته محاسبه می‌کند و برای tool_type = 'database_query' فیلتر می‌شود.

پیاده‌سازی دید در سطح ردیف

پیاده‌سازی این سیستم نیازمند ابزارگذاری (Instrumentation) لایه ابزارهاست، نه فقط لایه LLM. بسیاری از تیم‌ها فراخوانی‌های LLM را ردیابی می‌کنند اما ابزارهای پایگاه‌داده، API و جست‌وجوی خود را بدون ابزارگذاری رها می‌کنند. هر ابزار باید در یک بافت ردیابی (Tracing Context) قرار گیرد.

با استفاده از ابزارهایی مانند @tormentnexus/sdk، توسعه‌دهندگان می‌توانند تابعی مانند executeDatabaseQuery را پیاده کنند که بازه‌ای را برای ثبت db.system (مثلاً postgresql)، متن کامل db.query و agent.intent آغاز کند. این پیاده‌سازی باید موارد زیر را ثبت کند:

• معیارهای اجرا: db.rows_returned و db.execution_time_ms.
• نمونه داده‌ها: یک db.result_sample شامل پنج ردیف اول.
• متادیتای طرحواره: db.column_names و یک پرچم db.has_nulls برای شناسایی مشکلات احتمالی داده‌ها.
• پرچم‌های کیفیت: اگر rowCount === 0 بود، سیستم باید agent.quality_flag را روی «zero_results» تنظیم کرده و یک رویداد anomaly_detected اضافه کند.

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

در نهایت، سیستم باید تصمیمات عامل را با وضعیت داده‌ها مرتبط کند. وقتی یک عامل ادعا می‌کند که «۸۴۷ مشتری پیدا کرد»، آن بازه استدلال باید به صورت موازی با مجموعه نتایج ۸۴۷ ردیفی در داشبورد لینک شود. این کار به توسعه‌دهندگان اجازه می‌دهد نه تنها ببینند عامل چه داده‌ای را دیده، بلکه بفهمند آن داده چگونه بر استدلال او تأثیر گذاشته است.

از نظارت تا حفاظ‌های خودکار

زمانی که قابلیت مشاهده در سطح ردیف ایجاد شد، می‌توان آن را به یک خط لوله حفاظتی فعال تبدیل کرد. این کار سیستم را از نظارت غیرفعال به گیت‌های کیفی خودکار تبدیل می‌کند که خطاها را قبل از رسیدن به کاربر می‌گیرند:

• گیت‌های اعتبارسنجی طرحواره (Schema Validation Gates): کوئری‌ها قبل از اجرا با یک رجیستری طرحواره اعتبارسنجی می‌شوند. اگر عامل به ستونی غیرموجود یا یک نام مستعار منسوخ شده برای جدول اشاره کند، کوئری رد شده و درخواست تولید مجدد داده می‌شود. این کار ۸ تا ۱۲٪ از کوئری‌های تولید شده توسط عامل را در سیستم‌هایی با طرحواره‌های در حال تغییر اصلاح می‌کند.
• تأیید قرارداد نتایج (Result Contract Verification): سیستم بررسی می‌کند که آیا مجموعه نتایج با الگوهای مورد انتظار مطابقت دارد. اگر استدلال عامل بر «مشتریان ۳۰ روز اخیر» تأکید دارد اما کوئری ردیف‌هایی با برچسب زمانی سال ۲۰۲۳ برمی‌گرداند، یا اگر تعداد نتایج با پیش‌بینی عامل تفاوت مرتبه‌ای (Order of Magnitude) دارد، خروجی علامت‌گذاری می‌شود.
• نمونه‌برداری حقیقت زمینی (Ground Truth Sampling): مقایسه مستمر پاسخ‌های عامل با داده‌های تأیید شده برای حفظ بودجه خطا و تضمین قابلیت اطمینان بلندمدت.

این تغییر در عمل، فرض بنیادی عملیات هوش مصنوعی را تغییر می‌دهد. هدف از «آیا عامل کار را به پایان رساند؟» به «آیا عامل از داده‌های درست برای رسیدن به نتیجه درست استفاده کرد؟» تغییر می‌یابد.

برای توسعه‌دهندگان، این بدان معناست که ابزار اصلی عیب‌یابی دیگر پرامپت نیست، بلکه ردیابی (Trace) است. با نگاه به عامل‌های هوش مصنوعی به عنوان سیستم‌های توزیع‌شده، تیم‌ها می‌توانند در نهایت همان سخت‌گیری را که برای پایداری (Uptime) پایگاه‌داده به کار می‌برند، برای خروجی‌های LLM اعمال کنند.

برای شروع پیاده‌سازی، باید لایه فراخوانی ابزارهای فعلی خود را بازرسی کنید تا ببینید آیا مجموعه‌های نتایج واقعی را ثبت می‌کنید یا صرفاً وضعیت موفقیت/شکست فراخوانی را.

گام بعدی شما

• لایه فراخوانی ابزارهای خود را بررسی کنید و ببینید آیا نتایج واقعی (Result Sets) را ذخیره می‌کنید یا فقط وضعیت موفقیت/شکست را.
• یک «بودجه صحت» (Accuracy Budget) برای عامل‌های خود تعریف کنید تا از انتشار نسخه‌های ناپایدار جلوگیری شود.
• برای هر کوئری تولید شده توسط مدل، یک نمونه از ردیف‌های بازگشتی را در لاگ‌های خود ثبت کنید.

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