‏از دموی جذاب تا ایجنت هوش مصنوعی قابل‌اعتماد

نویسنده با یه صحنهٔ آشنا شروع می‌کنه: یه استارتاپ سفر به اسم WanderAI که کاربر می‌نویسه «ده روز ژاپن، بودجهٔ متوسط، عاشق غذا، از شلوغی بدش میاد» و ایجنت تو چند ثانیه یه برنامهٔ سفر می‌سازه. دمو همه رو مجذوب می‌کنه، ولی یکی از ته جلسه اون سؤالی رو می‌پرسه که هر دموی AI رو می‌شکنه: «از کجا می‌دونی واقعاً داره درست کار می‌کنه؟» به گفتهٔ نویسنده، یه دمو لازم نیست به این جواب بده، ولی یه سرویس واقعی تو پروداکشن باید بده.

نویسنده می‌گه چالش اصلی اینه که یه ایجنت فقط یه فراخوانی ساده به مدل نیست؛ یه موتور تصمیم‌گیریه که خودش انتخاب می‌کنه کِی و کدوم ابزار رو صدا بزنه و چطور جوابش رو تفسیر کنه. برای همین تأخیر می‌تونه از چند جا بیاد، خروجی غیرقطعیه (یه ورودی ممکنه دو تا برنامهٔ متفاوت بده) و خطاها قایم می‌شن، چون اگه یه ابزار جواب خراب بده ایجنت بدون هیچ خطایی روش برنامه می‌سازه. راه‌حل، ردیابی (trace) و متریک و لاگ ساختاریافتهٔ به‌هم‌مرتبطه.

نکتهٔ جالبی که نویسنده روش تأکید می‌کنه اینه که گرفتن رصدپذیری پایه برای یه اپ مبتنی بر Agent Framework فقط دو خط کده، چون خود فریم‌ورک طبق قراردادهای معنایی GenAI تو OpenTelemetry از قبل instrument شده و فقط باید یه exporter بهش وصل کنی:

from agent_framework.observability import configure_otel_providers

# Console exporter first - verify locally
configure_otel_providers()

بعد از این، با تنظیم OTEL_EXPORTER_OTLP_ENDPOINT به سمت New Relic، کل مسیر ایجنت تو Distributed Tracing دیده می‌شه. ولی نویسنده می‌گه این پایه کافی نیست؛ instrument خودکار فقط می‌گه ایجنت چی کار کرد، نه اینکه برای کسب‌وکار تو چه اتفاقی افتاد. برای همین باید span سفارشی دور توابع ابزار و route ها بذاری و attribute هایی مثل travel.location و trip.duration_days اضافه کنی که بعداً باهاشون فیلتر و گروه‌بندی و آلارم می‌سازی.

بعد نوبت ساختن سیستم روی این داده‌هاست: داشبورد با ویجت‌هایی مثل نرخ درخواست، نرخ خطا، p95 زمان پاسخ و هزینهٔ توکن. این کوئری NRQL مثلاً مصرف هر ابزار رو نشون می‌ده:

SELECT count(*) FROM Span
WHERE service.name = 'WanderAI'
  AND name IN ('get_weather', 'get_random_destination', 'get_datetime')
FACET name TIMESERIES

نویسنده می‌گه فقط داشبورد کافی نیست؛ آلارم‌هایی که روی سیگنال واقعی شلیک کنن (نه نویز)، به‌علاوهٔ SLO ها (مثلاً دسترس‌پذیری ۹۹٫۵٪ و ۹۵٪ درخواست‌ها زیر ۱۰ ثانیه) و deployment marker ها تیم رو از حالت واکنشی به فعال می‌برن.

سخت‌ترین بخش به نظر نویسنده اینه که از کجا بفهمی AI واقعاً خوبه. یه سرویس سنتی وقتی کد ۲۰۰ بده «کار می‌کنه»، ولی یه سرویس AI می‌تونه سریع و موفق جواب بده ولی یه مقصد توهمی یا برنامهٔ ۱۴ روزه به‌جای ۵ روزه تحویل بده. اینجا سه لایه پیشنهاد می‌شه: رویدادهای سفارشی AI Monitoring (مثل LlmChatCompletionSummary) برای مقایسهٔ مدل و هزینه، ارزیابی قانون‌محور و سریع (آیا ساختار روزبه‌روز داره؟ آیا بخش اقامت و حمل‌ونقل هست؟) و بازخورد کاربر که با همون trace_id به تعامل اصلی join می‌شه تا بفهمی کاربرها کدوم مدل رو ترجیح می‌دن.

لایهٔ آخر امنیته. نویسنده می‌گه بهتره گاردریل رو دو لایه بسازی: یه لایهٔ پلتفرمی (Microsoft Foundry Guardrails) که حملات آشکار مثل prompt injection و jailbreak رو روی ورودی و خروجی تشخیص می‌ده و روی ریسک بالا بلاک می‌کنه، و یه لایهٔ دامنه‌محور داخل خود اپ که قبل از اجرای ایجنت با ترکیب قانون و heuristic سوءاستفاده‌های خاص حوزهٔ سفر رو می‌گیره. نکتهٔ کلیدی اینه که هر تصمیم امنیتی هم باید قابل‌مشاهده باشه؛ هر بلاک یه متریک و هر الگوی شناسایی‌شده یه attribute روی span می‌شه. به گفتهٔ نویسنده، با هر دو لایه به تشخیص بالای ۹۰٪ روی ورودی‌های مخرب با کمتر از ۱۰٪ false positive رسیدن.

نکات کلیدی:

• فرق دمو با پروداکشن اینه که سرویس واقعی باید بتونه ثابت کنه واقعاً درست کار می‌کنه، نه فقط بالا بودن سرور
• Microsoft Agent Framework از قبل با OpenTelemetry instrument شده و رصدپذیری پایه با چند خط کد فعال می‌شه
• span و attribute سفارشی، داده‌های فنی رو به معنای کسب‌وکاری تبدیل می‌کنن
• داشبورد و آلارم و SLO و deployment marker، تله‌متری خام رو به یه سیستم قابل‌بهره‌برداری تبدیل می‌کنن
• کیفیت خروجی AI با ترکیب رویداد، ارزیابی قانون‌محور و بازخورد کاربرِ join‌شده روی trace_id سنجیده می‌شه
• امنیت بهتره دو لایه باشه و هر تصمیم امنیتی هم قابل‌مشاهده و قابل‌اندازه‌گیری بمونه