هیچکس تو Dreamforce از کاربر حرف نزد
هوش مصنوعیClaude Opus 5خلاصهٔ کاملتر
نویسنده که امسال دو تا سخنرانی تو Dreamforce داشته، میگه سه روز کف نمایشگاه راه رفته و همهجا ابزار ساخت، ارکستریشن، guardrail (یعنی قانونهایی که جلوی خروجی خطرناک ایجنت رو میگیره) و eval (یعنی نمره دادن خودکار به جواب ایجنت) دیده. به گفتهٔ اون، همهٔ این ابزارها یه سوال رو جواب میدن: ایجنت میتونه کارو انجام بده؟ ولی هیچکدوم نمیگن آدمی که اون طرف نشسته کارش راه افتاد یا نه.
یه نمونهٔ واقعی هم رو صفحه آورده: خریداری که دنبال کفش پهن بوده. تو داشبورد، نمرهٔ مفید بودن ۰٫۹۶، نمرهٔ مرتبط بودن ۰٫۹۵ و تیکت هم «حلشده» علامت خورده. ولی چیزی که واقعاً اتفاق افتاده این بوده که طرف چهار بار درخواستشو تکرار کرده، آخرش کاتالوگ رو تو یه تب دیگه باز کرده و در سکوت کمتر از چیزی که میخواست برداشته و رفته. هیچکدوم از این رفتارها تو ستون معیارها پیدا نمیشه.
به گفتهٔ نویسنده، اندازهگیری باید از بیرون خود ایجنت شروع بشه: گفتگوها، traceها (یعنی ثبت قدمبهقدم کاری که ایجنت انجام داده)، رویدادهای سایت و رویدادهای محصول، همه روی یه هویت و یه خط زمانی به هم وصل بشن. بعد از بدترین گروه شروع میکنی؛ مثلاً کسایی که یه سوال رو سه بار یا بیشتر پرسیدن. علتش خودش رو لو میده، چون ایجنت بهجای پرسیدن، نیت کاربر رو حدس زده. راهحلش هم سادهست: یه بار بپرس و پیشفرض حدس نزن.
این ماجرا یه صورتحساب هم داره. نویسنده میگه هزینه تقریباً با مجذور تعداد نوبتهای گفتگو بالا میره، پس ۹ نوبت بهجای ۳ نوبت یعنی نزدیک به ده برابر هزینه. هر نوبت اضافه هم از eval رد شده و هیچ خطایی نداده، برای همین اصلاً به چشم شکست نمیاد و فقط به شکل مصرف ثبت میشه. جملهای که خودش میگه اینه: قبض inference، در واقع فهرست ریز سوءتفاهمهای ایجنت توئه.
حرف آخرش اینه که observability از اتاق سرور اومده و میگه سیستم بالاست یا نه، evaluation هم از مرحلهٔ ریلیز اومده و میگه خروجی قابل قبوله یا نه. هر دو تو کار خودشون خوبن، ولی هیچکدوم ساخته نشدن که به اون سوالی جواب بدن که کاربر داره باهاش نمره میده: این کار به زحمتش میارزید؟
نکات کلیدی:
- هزینهٔ گفتگو تقریباً با مجذور تعداد نوبتها بالا میره، یعنی ۹ نوبت بهجای ۳ نوبت حدود ده برابر هزینه
- تو نمونهٔ نویسنده، گفتگویی با نمرهٔ ۰٫۹۶ مفید بودن و تیکت «حلشده»، کاربرش چهار بار خودشو تکرار کرده بود
- observability میگه سیستم بالاست یا نه و eval میگه خروجی قابل قبوله یا نه؛ هیچکدوم نمیگن کاربر راضی بوده
- نویسنده سنجش تجربه با judge model رو کافی نمیدونه و رفتار واقعی کاربر رو شاهد محکمتری میدونه
- تو این نمونه، مشتری Conviva ایجنتهاشو از طریق MCP به سامانهٔ اندازهگیری وصل کرده
