به گزارش از وبسایت cncf 📚
ما چند ماه پیش یک نماینده (agent) را در داخل محصول خود منتشر کردیم. این نماینده در برنامه وب ما کار میکند و به کاربران امکان میدهد دربارهٔ استقرار خود سؤال بپرسند — برای مثال: “در ماه گذشته کاربران چند سؤال از ربات Slack پرسیدهاند؟”
هدف ما ارائهٔ این نماینده آن بود که ابزار تحلیلی پیشین (خوشهبندی، برچسبگذاری، فیلترها) نتوانسته بود تمام موارد استفاده را پوشش دهد و میخواستیم ببینیم آیا یک رابط چت میتواند این خلأ را پر کند یا خیر.
این نماینده حدود 30 ابزار بومی دارد که برای تعامل با پلتفرم ما طراحی شدهاند، مانند search_conversations و display_chart. علاوه بر اینها، یک ابزار به نام search_knowledge_base وجود دارد که میتواند اسناد، نمونههای کد، سؤالات متداول و مرجع API را بخواند.
ما تصور میکردیم ابزارهای بومی بیشترین بار را بر دوش خواهند داشت. اما وقتی 1192 مکالمهٔ گذشته را بررسی کردیم، متوجه شدیم استفاده از search_knowledge_base تقریباً برابر با مجموع استفاده از تمام ابزارهای بومی بود.
این الگو برای جامعهٔ cloud-native اهمیت ویژهای دارد. در چشمانداز CNCF، از Kubernetes و Prometheus تا Envoy، Argo و OpenTelemetry، مستندات اغلب نخستین نقطهٔ برخورد کاربران با یک پروژه هستند؛ مستندات معمولاً بزرگ، پویا و در سطوح متعددی منتشر میشوند.
با افزوده شدن ابزارها و منابع مختلف در کنار مستندات، این سؤال عملی پدید میآید که نماینده تا چه اندازه باید اسناد را بخواند و چه چیزهایی را باید از طریق ابزارهای فراخوانیشونده به دست آورد. در ادامه یافتههای اصلی ما دربارهٔ اهمیت جستجوی مستندات را میخوانید.
یافتهٔ شمارهٔ 1: مستندات بهعنوان یک ابزار بازگشتی عمل میکند. کاربرد اصلی search_knowledge_base زمانی بود که کاربران سؤالهایی مطرح میکردند که هیچ ابزار بومی قادر به پاسخگویی آنها نبود؛ این دسته حدود 32.1٪ از مکالمات را تشکیل میداد. پرسشهایی مانند “چگونه یکپارچهسازی Slack را تنظیم کنم؟” یا “چرا خطاهای CORS در ویجت دریافت میکنم؟” یا “خزیدن وبسایت هر چند وقت یکبار انجام میشود؟” بدون دسترسی به search_knowledge_base، نماینده یا باید امتناع میکرد یا حدس میزد.
یافتهٔ شمارهٔ 2: مستندات زمینهٔ لازم را به ابزارهای بومی اضافه میکند. در حدود 7٪ از مکالمات، نماینده هم از ابزارهای بومی و هم از search_knowledge_base استفاده کرد. ابزارهای بومی وضعیت فعلی حساب کاربر را گزارش میدادند، اما برای توضیح معنای آن وضعیت یا مقایسه گزینهها، نماینده باید اسناد را میخواند. برای مثال کاربری پرسید چه نوع ادغامهایی در MCP راهاندازی شده و تفاوت آنها با گزینههای دیگر چیست؛ list_integrations وضعیت پیکربندی فعلی را اعلام کرد، و برای مقایسهٔ انواع ادغام نماینده به مستندات مراجعه کرد. هیچیک از ابزارها بهتنهایی نمیتوانستند پاسخ کامل بدهند.
یافتهٔ شمارهٔ 3: مستندات به نماینده کمک میکند تا از ابزارهای خود بهتر استفاده کند. این نکتهای بود که کمتر انتظارش را داشتیم. در برخی مکالمات، search_knowledge_base نه برای پاسخدهی مستقیم، بلکه برای راهنمایی نماینده فراخوانی شد؛ یعنی نماینده ابتدا اسناد را خواند تا دریابد چه کاری باید انجام دهد. نمونهٔ واضح این است که کاربری خواست مکالماتی با احساسات منفی پیدا شود؛ در محصول ما فیلتر یا فیلد احساسات وجود نداشت. نماینده با خواندن اسناد متوجه شد که سیگنالهای منفی بهعنوان downvote و open feedback ثبت میشوند و سپس ابزار بومی مناسب با فیلترهای صحیح را فراخواند. در این حالت، مستندات نه تنها پاسخ نمیدادند بلکه اطلاعات لازم را فراهم کردند تا نماینده بتواند اقدام کند.
جمعبندی کوتاه: اگر در حال طراحی یک نمایندهٔ محصول هستید، ابزار مبتنی بر دانش احتمالاً مهمتر از آنچه در ابتدا تصور میکنید خواهد بود. این ابزار سؤالاتی را پاسخ میدهد که ابزارهای بومی برایشان طراحی نشدهاند، توضیح میدهد که خروجی خام ابزارهای اصلی چه مفهومی دارد، و وقتی زبان کاربر با طرح شما تطابق ندارد، به نماینده میگوید کدام ابزار بومی را فراخوانی کند. ما 30 ابزار بومی و یک ابزار برای خواندن اسناد ارسال کردیم؛ همان ابزار مستندسازی بود که سایر ابزارها را کاربردی کرد. برای پروژههایی با مستندات عمیق و در حال تحول—بهویژه در اکوسیستم cloud-native—مستندات تنها یک بازگشت نیستند، بلکه بخشی از منطق تصمیمگیری نماینده به شمار میآیند. 🔎
