نقش APIها در فریمورک هوش مصنوعی آرایجی The Role of APIs in Retrieval-Augmented Generation (RAG)
هوش مصنوعی از زمان عرضه گسترده ChatGPT در نوامبر ۲۰۲۲ به سرعت در حال تکامل است. صاحبان کسبوکار، توسعهدهندگان و علاقهمندان به هوش مصنوعی با هیجان به این جریان پیوستهاند، با دیدن امکان افزایش بهرهوری و آزاد شدن از کارهای تکراری.
با این حال، هر کسی که از ابزارهای مبتنی بر هوش مصنوعی مانند LLMها استفاده کرده باشد میداند که این ابزارها بدون محدودیت نیستند. LLMها وقتی پاسخ را نمیدانند، معمولاً اطلاعاتی را اختراع میکنند. همچنین کنترل کیفیت محدودی برای بررسی صحت یا ارزیابی کیفیت منابع بدون دخالت انسان وجود دارد. این موضوع استفاده از هوش مصنوعی را برای بسیاری از کاربران پیچیده میکند.
تولید تقویتشده با بازیابی (RAG) یکی از راهحلهایی است که برای پاسخ به این محدودیتها ایجاد شده است. در RAG، یک LLM برای تایید پاسخهای خود قبل از ارائه نتیجه، به منبع معتبر خارج از دادههای آموزشی خود مراجعه میکند. وقتی به درستی پیادهسازی شود، RAG میتواند بسیاری از مشکلاتی را که مانع استفاده حداکثری از LLMها میشوند، حل کند. همانطور که اغلب در ابزارهای دیجیتال نیاز است با منابع خارجی تعامل داشته باشند، APIها یک بخش حیاتی از RAG هستند.
در ادامه، آنچه باید درباره APIها و RAG بدانید تا ایدههایی برای استفاده از این فناوری نوظهور داشته باشید ارائه شده است.
چگونه فریمورک هوش مصنوعی RAG از APIها استفاده میکند
هم RAG و هم LLMها به شدت به پایگاههای داده برداری وابستهاند. این پایگاهها سنگ بنای کل سیستم هستند و به عنوان یک لایه اساسی بین دادههای بسیار ساختاریافته و برنامههای واقعی عمل میکنند. همچنین بسیار سریعتر و کارآمدتر هستند، زیرا دادهها را به صورت بردارهای عددی ذخیره میکنند نه خود شیء، که امکان بازیابی سریعتر، پردازش پیشرفته و نمایش داده چندبعدی را فراهم میکند. نمایش داده چندبعدی برای افزودن زمینه به یک پرسش حیاتی است. همچنین نیاز به مجموعه دادههای بسیار بزرگ را کاهش میدهد و بیشتر عملکردهای لازم برای RAG را از طریق یک API انجام میدهد.
سیستمهای RAG را میتوان به سه جزء تقسیم کرد:
-
زمینه (Context): پایه و اساس پرسوجوی API RAG است و به سیستم میگوید که کجا به دنبال دادههای مورد نیاز بگردد.
-
نقش (Role): هدف سیستم را تعریف میکند و به مدل میگوید چگونه پاسخها را قالببندی کند.
-
پرسش (Query): خود پرسش است که کل فرآیند را آغاز میکند.
۴ مثال از RAG در عمل
حالا که ایده بهتری از عملکرد RAG دارید، بیایید به برخی سناریوهای واقعی نگاه کنیم که RAG را بهطور مؤثر پیادهسازی کردهاند و APIهایی که با آنها تعامل دارند.
۱. دستیارهای مجازی
دستیارهای مجازی کاربردی محبوب از هوش مصنوعی و LLMها هستند. آنها نیاز به نمایندگان خدمات مشتری انسانی را برای برخی پرسشها حذف میکنند و خدمات مشتری ۲۴ ساعته ارائه میدهند. در برخی موارد، دستیارهای مجازی حتی از نمایندگان انسانی خدمات مشتری بهتر هستند، زیرا انسانها خطاپذیر هستند. حتی ماهرترین نماینده خدمات مشتری نیز محدودیت دارد. در برخی زمینهها، ماشینها مشکل دارند، که در اینجا RAG وارد عمل میشود.
اتصال یک دستیار مجازی به RAG به آنها دسترسی به اطلاعات بلادرنگ مانند شرایط آب و هوا یا وضعیت موجودی میدهد. ادغام RAG در جریان کاری دستیار مجازی مشابه سایر ادغامهای API است — تنها نیاز است یک لایه API تولیدکننده برای تعامل با دستیار مجازی اضافه شود. در این مثال، کاربر یک پرسش عادی را وارد میکند. این پرسش از طریق مدل RAG با استفاده از یک بازیاب سفارشی API اجرا میشود، که نتایج را بر اساس زمینه پرسش ارائه میدهد. بازیاب سفارشی سپس نتایج را در قالب مناسب بازمیگرداند.
۲. توصیههای شخصیسازیشده برای لیدها
اپلیکیشنها میتوانند از RAG برای کمک به تولید و توصیه لیدها استفاده کنند. برای مثال، Telescope یک پلتفرم اتوماسیون فروش است که لیدهای بلادرنگ به مشتریان ارائه میدهد. این شامل ادغام با نرمافزار CRM موجود مشتری است تا از صحت و مفید بودن دادهها اطمینان حاصل شود.
در این سناریو، یک API دادههای دقیق را به یک مدل یادگیری ماشین میفرستد. کاربران میتوانند این مدلها را با دادههای فروش اضافی شخصیسازی کنند، مانند اینکه آیا یک ارائه فروش موفق بوده است یا نه، که لیدهای مفیدتری تولید میکند. بهتر از آن، RAG میتواند برای تولید محتوای فروش بهتر نیز استفاده شود و محتوای فروش را با بررسی املا و دستور زبان از دیکشنریهای آنلاین تجزیه و تحلیل کرده و پیشنهادات بهبود ارائه دهد.
۳. جذب نیرو
زمینه دیگر جذب نیرو است. برای مثال، Assembly یک پلتفرم HR برای پاسخدهی به پرسشهای بلادرنگ است. این پلتفرم به عنوان یک لایه تولیدکننده بین فرد پرسشکننده و دادههای داخلی شرکت عمل میکند. این مفید است برای دریافت پرسشها از کاربران به زبان طبیعی و بازگرداندن بهترین پاسخ. این پلتفرم را برای جذب بهترین کاندیداها بسیار مفید میکند، زیرا اطلاعات دقیق به صورت بلادرنگ ارائه میشود.
با استفاده از Assembly، متقاضیان جالب همچنین میتوانند به فرصتهای شغلی مرتبط هدایت شوند، باز هم با استفاده از زبان طبیعی. این میتواند دامنه کاندیداهای بالقوه را به طور قابل توجهی گسترش دهد، زیرا محدود به کلمات کلیدی یا عبارات خاص نیستید. سیستمهای RAG حتی میتوانند سایتهای خاصی را مرور کنند تا مدل دادههای استخدامی مفیدتری ایجاد کنند.
۴. مشاوره پزشکی
هوش مصنوعی به طور فزایندهای برای تشخیص و مشاوره پزشکی استفاده میشود، که پیچیدگیها و فرصتهای خاص خود را دارد. تشخیص صحیح یک بیمار شامل دسترسی به تاریخچه پزشکی بیمار و آخرین تحقیقات پزشکی است، که پیامدهای قانونی در پی دارد، مانند HIPAA در ایالات متحده و GDPR در اروپا. سیستمهای RAG میتوانند به یک LLM اجازه دهند به دادههای پزشکی مرتبط و آخرین تحقیقات دسترسی پیدا کند، که میتواند به شکل قابل فهمی خلاصه شود و سپس در قالب مناسب بازگردانده شود.
چه زمانی نباید از APIهای RAG استفاده کرد
اگرچه سیستمهای RAG که از API استفاده میکنند دامنه کاربرد گستردهای دارند، اما برای همه موقعیتها مناسب نیستند. آنها همیشه از API استفاده نمیکنند، بنابراین در برخی موارد ممکن است نیاز به پیادهسازی رویکرد ترکیبی باشد.
مثال پزشکی که ذکر شد را در نظر بگیرید. اشتراکگذاری اطلاعات بیمار به صورت بینالمللی مشکلات و پیچیدگیهای قانونی ایجاد میکند، بنابراین دادهها باید به صورت محلی ذخیره شوند تا با HIPAA و GDPR مطابقت داشته باشند. در این شرایط، سیستم RAG نیازی به فراخوانی API ندارد، زیرا آن دادهها مانند داده آموزشی عمل میکنند.
برخی دیگر معتقدند که RAG برای بهرهوری، زمینه زیادی را حذف میکند. کارشناس یادگیری ماشین Phoebe Klett هشدار میدهد که RAG هنوز نمیتواند مشخص کند کدام متنها برای تولید پاسخ استفاده شدهاند. او همچنین هشدار میدهد که اسناد مرجع گاهی بزرگتر از مدل آموزشی خود هستند.
به جای استفاده از RAG برای هر موقعیت، Klett توصیه میکند از چیزی که او آن را “تبدیلکنندههای ذهن گسترشیافته” مینامد، استفاده شود، جایی که سیستم بهطور منظم با یک سیستم ذخیرهسازی خارجی تعامل دارد، که به عنوان یک نوع حافظه عمل میکند. این یکی دیگر از زمینههایی است که RAG ضعف دارد، زیرا شامل حافظه داخلی نیست که برای ایجاد زمینه واقعی ضروری است. این موضوع RAG را در معرض برخی از کاستیهای آشکار LLMها قرار میدهد — تمایل به تولید اطلاعات غلط وقتی پاسخ را نمیداند.
RAG محدودیتهای دیگری نیز دارد، بسیاری از آنها ناشی از محدودیتهای ذاتی LLMها هستند. بسیاری از LLMها برای هر تراکنش هزینه دارند. گنجاندن RAG در هر فراخوانی API میتواند به سرعت بسیار پرهزینه شود، چه برسد به اینکه کند و دشوار باشد. همچنین امنترین راهحل نیست، زیرا بسیاری از LLMها میتوانند کد اجرا کنند و دادهها را بازیابی کنند. ارائه امکان اجرای برنامههای هوش مصنوعی در شبکه شما برای هر کسی میتواند فاجعهآمیز باشد. به طور خلاصه، RAG در بسیاری از شرایط فوقالعاده است اما باید با دقت پیادهسازی شود.
نتیجهگیری درباره APIهای RAG
تولید تقویتشده با بازیابی پتانسیل حذف بسیاری از محدودیتهای ذاتی LLMها را دارد، اما هنوز راهحل همهجانبه برای هر مشکل نیست. APIهای RAG هنوز باید به دادههای خارجی مناسب متصل شوند تا مفید باشند، که آنها را شبیه سایر مدلهای یادگیری ماشین میکند. در غیر این صورت، همانند هر LLM دیگری، پاسخهای نادرست تولید خواهند کرد.
همچنین مسائل مربوط به رعایت قوانین دادهها در مرزهای بینالمللی مطرح میشود، همانطور که در مثالهای پزشکی دیدیم. توسعهدهندگان و معماران داده باید تصمیم بگیرند چگونه دادهها را برای نیازهای خاص خود مستقر کنند. در نهایت، APIهای RAG میتوانند ناکارآمد و پرهزینه شوند اگر با دقت پیادهسازی نشوند.
راهاندازی صحیح RAG بهترین امکانات را ارائه میدهد:
-
تعامل بلادرنگ با کاربران با زبان طبیعی و محاورهای
-
دسترسی به بهترین دادهها به صورت بلادرنگ
اگر شما در حال ایجاد راهحلهای مشتریمحور هستید، حداقل باید RAG را به عنوان یک گزینه در نظر بگیرید.
