نقش APIها در هوش مصنوعی عامل‌محور Exploring the Role of APIs in Agentic AI
در ماه‌های اخیر، عوامل هوش مصنوعی موضوع داغ بحث‌ها بوده‌اند. هوش مصنوعی عامل‌محور به‌طور قابل‌بحثی مرحله بعدی در چرخه هیجان هوش مصنوعی مولد است، زیرا مربوط به توانمندسازی دستیارهای هوش مصنوعی با قابلیت‌های خودکار است که می‌تواند تجربه کاربران را متحول کند. با این حال، وضعیت فعلی نشان می‌دهد که فاصله‌ای بین هیجان پیرامون عوامل هوش مصنوعی و کاربرد واقعی آن‌ها وجود دارد.
طبق گفته Anushrut Gupta، مدیر محصول ارشد، هوش مصنوعی مولد، Hasura، عوامل هوش مصنوعی هنوز تمایل دارند در محیط‌های سازمانی نتایج نادرست یا غیرقابل‌اقدام تولید کنند. دستیارهای هوش مصنوعی معمولاً عملکرد ضعیفی دارند، چه از Gemini گوگل بپرسید که چه فایل‌هایی توسط همکاران ویرایش شده‌اند، چه چرخه‌های فروش در Einstein Salesforce را بررسی کنید، یا تاریخچه خرید کاربران در Rufus آمازون را جویا شوید.
بخشی از این فاصله به داده‌ها مربوط می‌شود، زیرا همان‌طور که گفته می‌شود، “ورودی بی‌کیفیت، خروجی بی‌کیفیت دارد.” هوش مصنوعی نه تنها به داده‌های مرتبط برای تولید نتایج دقیق و قابل‌اقدام نیاز دارد، بلکه باید دسترسی آسان و بلادرنگ به آن داده‌ها داشته باشد. بنابراین، سیستم‌های تولید تقویت‌شده با بازیابی (RAG) ایجاد شده‌اند تا مکانیزم بازیابی داده به مدل‌های زبان بزرگ (LLM) بدهند و تجربه کاربری را با اطلاعات بلادرنگ زمینه‌سازی کنند.
APIها نقش قابل توجهی در RAG دارند. اما کار به همین‌جا ختم نمی‌شود. APIها می‌توانند عوامل هوش مصنوعی را فراتر از درخواست‌های ساده بازیابی ببرند و تغییراتی در backend ایجاد کنند، با سرویس‌های داخلی یا نرم‌افزار به‌عنوان سرویس (SaaS) شخص ثالث ارتباط برقرار کنند. بنابراین، APIها موقعیت خوبی دارند تا وعده هوش مصنوعی عامل‌محور را تحقق بخشند، منابع مختلف را به هم متصل کنند و اقدامات را به نمایندگی از کاربران انجام دهند. با این حال، برخی موانع نیز وجود دارد. پس چگونه می‌توان همه این نقاط را به هم متصل کرد؟
وضعیت عوامل هوش مصنوعی
یکی از موانع احتمالی امروز، عدم دسترسی آسان به API و جزئیات یکپارچه‌سازی است که LLMها بتوانند آن را تحلیل کنند. همان‌طور که Zednec “Z” Nemec در Platform Summit 2024 اشاره کرد، عوامل هوش مصنوعی در حال حاضر با ادغام APIها مشکل دارند.
APIها همیشه مستندات کاملی ندارند، بنابراین متادیتای API کشف آن‌ها را دشوار می‌کند. همه APIها مشخصات OpenAPI عمومی یا یک schema صریح GraphQL ارائه نمی‌دهند. اگر مستندات ناقص باشد یا فیلدها مفقود باشند، اغلب اسکرین‌اسکرپ کردن داده‌ها راحت‌تر از طی کردن مراحل ادغام استاندارد است.
فراتر از دسترسی، خود عوامل هوش مصنوعی با چند چالش در محیط‌های سازمانی مواجه‌اند، به‌ویژه در هماهنگی جریان‌های کاری واقعی و قابل‌اقدام بین برنامه‌ها. Gupta از Hasura می‌گوید: «هماهنگی بین حوزه‌ها و منابع داده مختلف و اتصال آن‌ها به یک LLM orchestrator آسان نیست.» این فرآیند ممکن است نیاز به دسترسی به داده‌ها از منابع مختلف و رعایت الزامات خاص هر ادغام، مانند احراز هویت و مجوز، صفحه‌بندی، محدودیت نرخ و تأخیر پردازش محاسبات داشته باشد.
از Rufus آمازون بپرسید که در سال ۲۰۲۴ چقدر هزینه کرده‌اید، و نتیجه تقریباً بی‌ربط خواهد بود. (البته هنوز در نسخه بتا است). در زمینه کسب‌وکار، برای دریافت نتایج قابل‌اقدام از یک عامل، نیاز به پرسش‌های بسیار خاص‌تر است. برای مثال، اگر یک نماینده پشتیبانی بخواهد بلیط‌های ثبت‌شده توسط مشتریان خاص در هفته گذشته را که SLA رعایت نشده پیدا کند و سپس به‌صورت خودکار بازپرداخت صادر کند، این صرفه‌جویی زیادی در زمان خواهد بود، اما عوامل در حال حاضر با پرسش‌های پیچیده چندمرحله‌ای و تغییرات دچار مشکل هستند.
تقویت دستیارهای هوش مصنوعی: نیازمندی‌ها
برای اینکه این کاربردهای سازمانی آگاه به زمینه باشند، دستیارهای هوش مصنوعی ابتدا باید به کل داده‌های موجود دسترسی داشته باشند. Gupta می‌گوید، این نیازمند فراهم کردن یک schema معنایی یکپارچه در تمام منابع داده است، چه پایگاه داده SQL، پایگاه داده برداری، APIهای داخلی یا ادغام‌های SaaS شخص ثالث. همچنین احتمالاً به مجوزهای یکپارچه بیشتری برای منابع داده نیاز خواهید داشت.
پیشرفت‌هایی برای استانداردسازی نحوه اتصال دستیارهای هوش مصنوعی به داده‌ها انجام شده است. برای مثال، Model Context Protocol شرکت Anthropic استاندارد جهانی برای اتصال سیستم‌های هوش مصنوعی به منابع داده با استفاده از سرورها و کلاینت‌های MCP پیشنهاد می‌دهد. با این حال، Gupta می‌گوید: «MCP مشکلات اساسی در اتصال داده‌ها (از انواع، اندازه‌ها و منابع مختلف) به LLMها و پرسش‌های کاربران واقعی را حل نمی‌کند.» او محدودیت‌های سیستم‌های RAG، برنامه‌ریزی محدود پرسش و نبود دستورالعمل‌های واضح برای اعمال کنترل دسترسی را به عنوان موانع احتمالی برای Claude با MCP در مقایسه با سایر راه‌حل‌ها ذکر می‌کند.
برخی پیشرفت‌های معماری نیز باید انجام شود. برخی توسعه‌دهندگان هوش مصنوعی به رویکرد چندعاملی روی آورده‌اند، اما Gupta می‌گوید این روش در محیط سازمانی خیلی کارآمد نیست. در عوض، او پیشنهاد می‌کند یک عامل واحد توانایی فکر کردن در لحظه با برنامه‌ریزی پرسش چندمرحله‌ای با بازیابی و محاسبات، توانایی اجرا و خوداصلاحی، حافظه ساختاریافته و کنترل دسترسی مبتنی بر نقش به حوزه‌های مختلف داشته باشد.
علاوه بر این، وظایف محاسباتی تحلیلی باید نتایج قطعی ارائه دهند. به عبارت دیگر، همان پرسش باید همان پاسخ را بدهد. این موضوع اهمیت دارد زیرا دقت در کار با داده‌های حساس داخلی مانند بلیط‌های پشتیبانی، فاکتورها یا نرخ خطا بسیار مهم است. بنابراین دستیارهای هوش مصنوعی باید منطقی و تجویزی باشند و امکان استفاده از وزن‌های مختلف و تنظیم آن‌ها در مواقع مناسب را فراهم کنند.
مثال: PromptQL
سناریوی پشتیبانی مشتری ذکر شده را در نظر بگیرید، جایی که یک شرکت می‌خواهد به تعدادی از مشتریان با بلیط پشتیبانی بازپرداخت ارائه دهد. Gupta پیشنهاد می‌کند پرسش زیر را استفاده کنید:
«پنج مشتری برتر بر اساس درآمد که حداقل چهار پروژه و حداقل دو بلیط پشتیبانی دارند، چه کسانی هستند؟ برای پروژه با دومین بالاترین درآمد، بازپرداخت ۳.۷۵٪ از درآمد را اعمال کنید.»
اتوماتیک کردن این فرآیند پیچیده احتمالاً نیازمند چندین فراخوان پایگاه داده و تعامل API برای بررسی مشتریان در پایگاه داده Postgres، جمع‌آوری بلیط‌ها از سیستم Zendesk، تحلیل اطلاعات و سپس اعمال بازپرداخت از طریق Stripe است. تمام این‌ها از نظر فنی با استفاده از PromptQL از Hasura، عامل دسترسی به داده برای ساخت برنامه‌های هوش مصنوعی، امکان‌پذیر است.
برای جمع‌آوری داده‌ها، عامل از یک supergraph عبور می‌کند، که اساساً یک فایل YAML بزرگ است که schemaها از سرویس‌ها، APIها و پایگاه داده‌های مختلف را ترکیب می‌کند. PromptQL سپس یک طرح پرسش بر اساس prompt ایجاد می‌کند. این شبیه‌سازی عملکرد انسان است، باز کردن یک نوت‌بوک Jupiter و نوشتن کد SQL در لحظه که نیازهای داده، نیازهای محاسبات و «تفکر» پشت صحنه را توصیف می‌کند.
با PromptQL، لایه‌ای برای هماهنگی بین چند فراخوان به LLM وجود ندارد. تنها یک فراخوان به LLM انجام می‌شود. عامل به‌طور ۱۰۰٪ خودکار عمل نمی‌کند — برای تغییرات (هر فراخوان POST API) قبل از ادامه درخواست تأیید انسانی می‌کند. تمام این‌ها به این معناست که برای توسعه‌دهندگان، اقدامات انجام شده و طراحی زیرساختی آن شفاف، قابل توضیح و تکرارپذیر است.
موانع احتمالی: چیزی فراتر از APIها؟
Gupta اذعان دارد که این رویکرد ممکن است موانع احتمالی داشته باشد. برای مثال، راه‌اندازی یک لایه داده یکپارچه ممکن است نیازمند تلاش باشد. برای عملکرد صحیح، متادیتا باید محکم باشد، بنابراین ممکن است نیاز به کار اولیه برای تعریف روابط در لایه داده معنایی یکپارچه داشته باشد تا زمینه‌ای‌تر باشند.
همچنین جمع‌آوری ساختارهای داده مورد نیاز نیازمند کار اولیه است. با استفاده از پلتفرم‌هایی مانند Hasura یا Apollo GraphQL، بیشتر introspection و وارد کردن schemaها به supergraph خودکار است. با این حال، اگر APIهای خارجی که می‌خواهید ادغام کنید APIهای مشخص و کامل نداشته باشند، روند کند می‌شود. (نکته منفی اینکه ۷۵٪ APIها دارای endpointهایی هستند که با مستندات آن‌ها مطابقت ندارد!)
جالب است که Gupta می‌گوید APIها پاسخ نهایی برای عوامل هوش مصنوعی نیستند، زیرا به طور ذاتی برای این منظور مناسب طراحی نشده‌اند، زیرا معمولاً محدودیت نرخ، صفحه‌بندی و قوانین پیچیده کنترل دسترسی دارند. او می‌گوید: «آن‌ها محدودیت‌های ذاتی دارند زیرا برای رابط وب طراحی شده‌اند. ما باید برای عوامل به چیزی جدید فکر کنیم.»
این «چیز جدید» می‌تواند به‌طور کامل از APIها چشم‌پوشی کند و به جای آن مستقیماً به پایگاه داده‌هایی که توسط شرکت‌های SaaS ارائه شده‌اند متصل شود. Gupta می‌گوید: «اتصال مستقیم به پایگاه داده بهترین راه برای پیشرفت است.» اگر این روند اتفاق بیفتد، روش ادغام کاملاً جدیدی ایجاد می‌شود و برخی از REST APIهای سنتی را جایگزین می‌کند.
فراتر از APIهای معمولی REST، معماری داده مش و معماری رویدادمحور (EDA) نیز می‌تواند دنیای «پس از API» برای هوش مصنوعی عامل‌محور را شکل دهد و امکان دریافت به‌روزرسانی‌های مبتنی بر trigger در زمان واقعی را فراهم کند. اما صرف‌نظر از روش ادغام، ریسک‌های امنیتی زمانی که عوامل استقلال بیشتری دارند، افزایش می‌یابد. بنابراین، کنترل دسترسی دقیق برای داده‌های حساس سازمانی ضروری است.
آینده: توانمندسازی عوامل هوش مصنوعی با قابلیت تغییر
وقتی به دستیارهای هوش مصنوعی فکر می‌کنید، احتمالاً چت‌بات‌های سنگین مشتری‌محور برای سایت‌های تجارت الکترونیک به ذهن می‌آید. یا شاید تجربه ناموفق تماس با پشتیبانی انسانی. اگرچه چت‌بات‌های هوش مصنوعی اغلب وعده‌های خود را برآورده نمی‌کنند، عوامل هوش مصنوعی به سرعت در حال تکامل هستند.
عوامل هوش مصنوعی از تعاملات زودگذر به حافظه پایدار منتقل می‌شوند. آن‌ها اکنون منابع داده خارجی را ادغام می‌کنند تا زمینه بیشتری را در اختیار ما قرار دهند. عوامل هوش مصنوعی هوشمندتر در محیط کسب‌وکار می‌توانند قابلیت‌های عمیقی برای تیم‌های HR، مدیران مهندسی، نمایندگان پشتیبانی و سایر نقش‌ها فراهم کنند.
اگرچه دسترسی به API برای عوامل هوش مصنوعی در حال حاضر محدود است، اما به سرعت در حال بهبود است. به عنوان مثال، API Gatewayها مانند Kong’s AI Gateway می‌توانند به عنوان middleware برای تغییرات پویا عمل کنند و برخی از چالش‌های فعلی را کاهش دهند.
البته، اتصال وب API تنها یک عامل است. بسیاری از فناوری‌ها می‌توانند دستیاران هوش مصنوعی فردا را تقویت کنند، از مدل‌های پایه باز، پایگاه‌های داده برداری و نرم‌افزارهای متن‌باز دیگر گرفته تا فناوری‌های تجربه کاربری مانند چت‌بات‌ها، پردازش زبان طبیعی، تشخیص گفتار و غیره. به عبارت دیگر، برای موفقیت هوش مصنوعی به یک جامعه کامل نیاز است.
فراتر از ادغام خودکار داده‌های بلادرنگ، اجرای خودکار تغییرات در بارهای کاری backend نسل بعدی هوش مصنوعی است. این بخش بزرگی از پازل است بدون پاسخ قطعی. PromptQL یک راه‌حل قابل توجه است. اما هر کسی که بتواند این کد را به مؤثرترین و استانداردترین شکل حل کند، آماده است که واقعاً پیشرفت کند و اقتصاد API را به قلمرو عوامل هوش مصنوعی بیاورد تا به‌طور خودکار عمل کنند. وقتی این اتفاق بیفتد، امکانات بی‌پایان خواهد بود.
