صورتحساب هوش مصنوعی شما مشکل مدل نیست؛ مشکل معماری است.
اگر هزینههای LLM شما در حال افزایش است، احتمالاً میخواهید آن را با یک مدل ارزانتر جایگزین کنید. ممکن است از GPT-4 به GPT-4-mini مهاجرت کنید. این کار کمک کمی میکند، اما بهندرت مشکل اصلی را حل میکند.
مشکل اصلی، گردش کار (workflow) شماست. بیشتر افراد هر مرحله را از طریق یک LLM عبور میدهند. آنها از استدلال زبانی برای کارهایی استفاده میکنند که نیازی به آن ندارند.
هر گردش کار هوش مصنوعی چهار بخش دارد:
• Trigger (محرک): کار را شروع میکند. هزینه آن نزدیک به صفر است. • Deterministic ML: دادهها را طبقهبندی یا امتیازدهی میکند. این روش ارزان است. • LLM: میخواند، مینویسد و استدلال میکند. این بخش گران است. • Tool/API: دادهها را فراخوانی یا ذخیره میکند. این روش ارزان است.
فاصله بین Deterministic ML و یک LLM بسیار زیاد است. هزینه یک LLM میتواند ۱۰۰ تا ۱۰۰۰ برابر بیشتر از یک طبقهبندیکننده (classifier) ساده باشد. اگر برای هر مرحله ابزار مناسب را انتخاب نکنید، بهطور پیشفرض سراغ گرانترین گزینه میروید.
یک سیستم تیکت پشتیبانی را در نظر بگیرید.
یک ساختار ضعیف، کل تیکت را به یک LLM میفرستد. از LLM میخواهد که قصد کاربر را طبقهبندی کند، تیکت را هدایت کند، پاسخ را پیشنویس کند و CRM را بهروزرسانی کند. این کار بسیار پرهزینه است. طبقهبندی نیازی به LLM ندارد؛ بلکه به یک مدل ساده برای نگاشت متن به یک دستهبندی نیاز دارد.
یک ساختار بهتر به این صورت است:
- Trigger: یک تیکت میرسد.
- Deterministic ML: یک مدل سریع و ارزان تصمیم میگیرد که آیا تیکت مربوط به صورتحساب است، فنی است یا اسپم.
- LLM: فقط برای پیشنویس پاسخ به تیکتهای معتبر استفاده میشود.
- Tool/API: سیستم، CRM را بهروزرسانی میکند.
در این نسخه، تیکتهای اسپم هرگز به LLM نمیرسند. شما دیگر بابت کارهای بیهوده، «مالیات LLM» را پرداخت نمیکنید.
اگر معماری خود را بهدرستی هدایت کنید، حتی قبل از تغییر مدلها، گرانترین فراخوانیها را حذف میکنید.
برای کاهش هزینههای خود، این مراحل را دنبال کنید:
- گردش کار خود را ترسیم کنید. مشخص کنید کدام مراحل نیاز به استدلال واقعی دارند و کدامها صرفاً طبقهبندی یا استخراج هستند.
- مراحل قطعی (deterministic) را از prompt خارج کنید. از روشهای سریعتر و ارزانتر برای هدایت و امتیازدهی استفاده کنید.
- برای دسترسی به LLM محدودیت (Gate) بگذارید. برای کارهایی که نیازی به آنها ندارند، پاسخ تولید نکنید.
- اندازه مدل را در آخرین مرحله ارزیابی کنید. تنها زمانی که معماری شما بهینه و سبک شد، برای مرحله تولید (generation) یک مدل کوچکتر انتخاب کنید.
بحث درباره اینکه کدام مدل در هر token ارزانتر است را متوقف کنید. شروع به ساخت معماریهایی کنید که از موتور گرانقیمت تنها در زمان ضرورت استفاده میکنند.
Source: https://dev.to/bakshiyogesh/your-ai-bill-isnt-a-model-problem-its-an-architecture-problem-1ole
Optional learning community: https://t.me/GyaanSetuAi
