بهینه‌سازی دقت LLM

به حداکثر رساندن صحت و رفتار سازگار هنگام کار با مدل‌های زبانی بزرگ (LLMs).

مقدمه

بهینه‌سازی LLM‌ها به چند دلیل کلیدی چالش‌برانگیز است:

• دانستن چگونگی شروع بهینه‌سازی دقت
• چه زمانی از چه روش بهینه‌سازی استفاده کنیم
• چه سطحی از دقت برای تولید کافی است

این راهنما یک مدل ذهنی برای بهینه‌سازی LLM‌ها برای دقت و رفتار ارائه می‌دهد و روش‌هایی مانند مهندسی پرامپت، تولید مبتنی بر بازیابی (RAG)، evalها، انتخاب مدل و برنامه‌ریزی تنظیم دقیق را بررسی می‌کند.

برای اپلیکیشن‌های AvalAI، کار روی دقت را به‌عنوان یک چرخه انتشار ببینید، نه یک بازنویسی یک‌باره prompt:

1. شکست قابل مشاهده برای کاربر و هزینه تجاری آن شکست را تعریف کنید.
2. یک eval set کوچک با promptهای نماینده، رفتار مورد انتظار و پاسخ‌های غیرقابل قبول بسازید.
3. تشخیص دهید failure از کمبود context، رفتار ناسازگار مدل یا flow ناامن ابزار/retrieval می‌آید.
4. هر بار فقط یک اهرم را تغییر دهید و پیش از ship کردن همان evalها را دوباره اجرا کنید.

چرخه بهینه‌سازی در AvalAI

راهنمای model optimization در OpenAI کار روی کیفیت را یک چرخه پیوسته از eval، مهندسی prompt و fine-tuning می‌بیند. در AvalAI همین چرخه را به کار ببرید، اما فرض‌های مربوط به training میزبانی‌شده و eval میزبانی‌شده را وابسته به route بدانید:

1. با eval خط پایه بسازید: پیش از تغییر prompt، model، retrieval یا schema ابزار، یک eval محلی یا CI اجرا کنید.
2. درخواست را بهتر کنید: دستورهای developer را دقیق‌تر کنید، فقط context لازم را اضافه کنید و وقتی رفتار مطلوب سخت توضیح داده می‌شود از مثال‌های few-shot استفاده کنید.
3. مدل و endpoint را مقایسه کنید: /v1/responses، /v1/chat/completions و routeهای بومی provider را فقط جایی تست کنید که مدل انتخابی از آن‌ها پشتیبانی می‌کند.
4. داده training را فقط بعد از شواهد eval آماده کنید: مثال‌های input/output باکیفیت و ردیف‌های hold-out جمع کنید، اما تا وقتی AvalAI routeهای پشتیبانی‌شده را منتشر نکرده، fine-tuning میزبانی‌شده را در دسترس فرض نکنید.
5. شکست‌های production را وارد چرخه کنید: هر failure مهم باید قبل از تغییر بعدی prompt یا routing به یک ردیف eval تبدیل شود.

با این روش، بهینه‌سازی از «یک prompt بهتر امتحان کنیم» به یک چرخه شواهد تبدیل می‌شود: dataset → baseline → یک تغییر → مقایسه → تصمیم rollout.

زمینه بهینه‌سازی LLM

به جای دیدن بهینه‌سازی به عنوان یک فرآیند خطی، مفیدتر است که آن را به عنوان ماتریسی با دو بعد کلیدی در نظر بگیریم:

• بهینه‌سازی زمینه: زمانی که مدل فاقد دانش است، اطلاعات قدیمی دارد یا به داده‌های اختصاصی نیاز دارد را برطرف می‌کند. این دقت پاسخ را به حداکثر می‌رساند.
• بهینه‌سازی LLM: نتایج ناسازگار، مشکلات قالب‌بندی، لحن/سبک نادرست یا استدلال ناسازگار را برطرف می‌کند. این سازگاری رفتار را به حداکثر می‌رساند.

در عمل، بهینه‌سازی به یک فرآیند تکراری ارزیابی، فرضیه، کاربرد و ارزیابی مجدد تبدیل می‌شود.

پیش از افزودن پیچیدگی، از این جدول تصمیم استفاده کنید:

نشانه	اولین اهرم	پیاده‌سازی در AvalAI
مدل به facts خصوصی، جدید یا domain-specific دسترسی ندارد	بهینه‌سازی context	RAG، ورودی فایل، ابزارهای وب/جستجو یا reference text صریح اضافه کنید.
مدل facts را دارد اما قالب، لحن یا سبک پاسخ اشتباه است	بهینه‌سازی رفتار LLM	instructionها، مثال‌ها، schemaها و در صورت استفاده از /v1/responses مقدارهای reasoning.effort / text.verbosity را بهتر کنید.
یک اشتباه در ورودی‌های مشابه بارها تکرار می‌شود	فعلا مثال‌های قوی‌تر؛ بعدا برنامه‌ریزی fine-tuning	مثال‌های شبیه production جمع کنید، few-shot/schema guidance را قوی‌تر کنید و یک eval set نگه‌داشته‌شده برای training میزبانی‌شده آینده داشته باشید.
context طولانی باعث گم شدن facts مهم می‌شود	retrieval و چیدمان context	اندازه context و موقعیت chunkها را تست کنید؛ فرض نکنید پنجره context بزرگ‌تر همیشه دقت را حل می‌کند.

مهندسی پرامپت

مهندسی پرامپت معمولا بهترین نقطه شروع است. برای موارد استفاده مانند خلاصه‌سازی، ترجمه و تولید کد، ممکن است تنها روش مورد نیاز برای رسیدن به دقت سطح تولید باشد.

شروع با مهندسی پرامپت شما را مجبور می‌کند تا تعریف کنید که دقت برای مورد استفاده خاص شما به چه معناست. با ارائه یک ورودی و ارزیابی اینکه آیا خروجی انتظارات شما را برآورده می‌کند، بینش‌هایی در مورد بهینه‌سازی‌های بیشتر مورد نیاز به دست می‌آورید.

استراتژی‌های بهینه‌سازی

• دستورالعمل‌های واضح بنویسید: در مورد قالب خروجی مورد نظر، لحن و محدودیت‌ها مشخص باشید.
• وظایف پیچیده را به زیروظایف ساده‌تر تقسیم کنید: استدلال پیچیده را به فرآیندهای مرحله به مرحله تقسیم کنید.
• به LLM‌ها زمان "فکر کردن" بدهید: مدل را تشویق کنید تا به طور منظم مشکلات را حل کند.
• تغییرات را به طور سیستماتیک آزمایش کنید: تغییرات کنترل شده ایجاد کنید و تاثیر آنها را اندازه‌گیری کنید.
• متن مرجع ارائه دهید: در صورت نیاز، اطلاعات مربوطه را در پرامپت قرار دهید.
• از ابزارهای خارجی استفاده کنید: از ابزارها برای محاسبات، بازیابی داده یا تایید استفاده کنید.

مثال: وظیفه تصحیح زبان

افزودن نمونه‌های few-shot به یک پرامپت پایه برای تصحیح جمله ایسلندی، امتیازات BLEU را از 62 به 70 بهبود بخشید، که ارزش نشان دادن مثال‌هایی از رفتار مورد نظر به مدل را نشان می‌دهد.

ارزیابی

یک مجموعه ارزیابی خوب با سؤالات و پاسخ‌های صحیح قبل از رفتن به روش‌های بهینه‌سازی پیشرفته‌تر ضروری است. وقتی 20+ مثال دارید و می‌دانید چرا شکست‌ها رخ می‌دهند، یک خط پایه قوی برای بهینه‌سازی بیشتر دارید.

خودکارسازی ارزیابی را با موارد زیر در نظر بگیرید:

• معیارهایی مانند ROUGE یا BERTScore برای مقایسه‌های سریع
• استفاده از یک مدل داور قوی با rubric امتیازدهی که با مثال‌های human-reviewed کالیبره شده باشد

الگوی کالیبراسیون مدل داور

LLM-as-judge برای کیفیت subjective، safety، helpfulness و امتیازدهی partial-credit مفید است، اما می‌تواند position bias، verbosity bias و drift در rubric ایجاد کند. فقط وقتی checkهای ساده‌تر کیفیت را نمی‌سنجند از آن استفاده کنید:

1. وقتی پاسخ مورد انتظار deterministic است، ابتدا از string، enum، JSON schema یا بررسی argument ابزار استفاده کنید.
2. پیش از درخواست امتیاز از judge model، rubric را با معیارهای pass/fail یا pairwise بنویسید.
3. روی مجموعه‌ای با label انسانی کالیبره کنید و نمونه‌های اختلاف را ثبت کنید.
4. در مقایسه‌های pairwise ترتیب پاسخ‌ها را بچرخانید و طول پاسخ‌ها را کنترل کنید تا judge به‌صورت پیش‌فرض پاسخ بلندتر را ترجیح ندهد.
5. برای هر اجرای eval، مدل داور، rubric، temperature و نسخه prompt را ثابت نگه دارید؛ اگر هرکدام تغییر کرد، baseline تولیدی را دوباره اجرا کنید.

برای workflowهای production در AvalAI، evalها را نزدیک به اجرای واقعی اپلیکیشن نگه دارید:

• همان قالب context بازیابی‌شده، خروجی ابزار، schema و محدودیت‌های ایمنی production را وارد کنید.
• دلیل pass/fail را ثبت کنید، نه فقط یک امتیاز کلی، تا هر failure به یک اهرم مشخص وصل شود.
• هر failure واقعی production را پیش از تغییر prompt به eval set اضافه کنید.
• روی هر تغییر مدل، prompt، retrieval یا routing یک smoke eval سریع اجرا کنید و پیش از launch suite کامل‌تری بگیرید.
• برای هر اجرای eval، شناسه مدل، endpoint (/v1/responses، /v1/chat/completions یا route بومی provider)، temperature، تنظیمات retrieval و قانون routing را ثبت کنید.

درک ابزارها

وقتی مهندسی پرامپت کافی نیست، تشخیص دهید که آیا با یک مشکل حافظه درون متنی یا آموخته شده مواجه هستید:

• مشکلات حافظه درون متنی: مدل فاقد اطلاعات لازم برای پاسخ صحیح است. با RAG و افزودن زمینه مرتبط حل کنید.
• مشکلات حافظه آموخته شده: مدل به الگوهای رفتاری سازگار نیاز دارد. در AvalAI امروز ابتدا با instructionهای روشن‌تر، مثال‌ها، structured output، محدودیت ابزار و routing مدل حل کنید؛ مثال‌های باکیفیت را برای fine-tuning میزبانی‌شده آینده، وقتی AvalAI routeهای پشتیبانی‌شده را اعلام کند، نگه دارید.

این رویکردها افزودنی هستند، نه انحصاری - می‌توانند برای عملکرد بهینه ترکیب شوند.

تولید مبتنی بر بازیابی (RAG)

RAG محتوای مرتبط را بازیابی می‌کند تا پرامپت LLM شما را قبل از تولید پاسخ تقویت کند و به مدل دسترسی به زمینه خاص دامنه را می‌دهد.

برنامه‌های RAG می‌توانند در دو حوزه شکست بخورند:

1. مشکلات بازیابی: ارائه زمینه نادرست یا نامربوط
2. مشکلات LLM: مدل از زمینه صحیح سو استفاده می‌کند

بهینه‌سازی RAG نیازمند تنظیم هم سیستم بازیابی و هم دستورالعمل‌های LLM است.

برنامه‌ریزی تنظیم دقیق (Fine-Tuning)

تنظیم دقیق، آموزش یک LLM را روی یک مجموعه داده کوچکتر و خاص دامنه ادامه می‌دهد تا:

• دقت مدل را در وظایف خاص بهبود بخشد
• کارایی را بهبود بخشد (همان دقت با توکن‌های کمتر یا مدل‌های کوچکتر)

در حال حاضر data/models.json تنظیم دقیق میزبانی‌شده AvalAI را برای مدل‌های پایه منتشر نمی‌کند. این بخش را راهنمای آماده‌سازی بدانید: dataset، eval و معیار rollout را اکنون بسازید، اما تا وقتی AvalAI مدل‌های پایه و routeهای پشتیبانی‌شده را اعلام نکرده، fine-tuning را به عنوان مسیر اجرایی AvalAI معرفی نکنید.

بهترین شیوه‌های تنظیم دقیق شامل:

• شروع با مهندسی پرامپت برای ایجاد یک خط پایه
• تمرکز بر کیفیت به جای کمیت (شروع با 50+ مثال با کیفیت بالا)
• اطمینان از اینکه نمونه‌های آموزشی نماینده ورودی‌های دنیای واقعی هستند
• از «prompt baking» استفاده کنید: promptها و خروجی‌های pilot را log کنید، آن‌ها را به مثال‌های آموزشی واقعی تبدیل کنید و secretها یا موارد کم‌کیفیت را حذف کنید.
• یک hold-out set برای ارزیابی نگه دارید تا بهتر شدن training score، overfitting را پنهان نکند.

اگر fine-tuning میزبانی‌شده فعال شد و flow تولیدی شما از RAG استفاده می‌کند، context مربوط به RAG را در مثال‌های fine-tuning هم بیاورید. در غیر این صورت مدل task ساده‌تری از task واقعی production یاد می‌گیرد.

رویکردهای ترکیبی

این تکنیک‌ها روی هم قرار می‌گیرند. مزایای ترکیب رویکردها شامل:

• استفاده از promptهای کوتاه، schemaها و مثال‌ها برای کاهش توکن‌های تکراری instruction
• آموزش رفتار پیچیده با مثال‌های prompt در حال حاضر، و با fine-tuning فقط وقتی route پشتیبانی‌شده AvalAI وجود داشته باشد
• استفاده از RAG، context فایل، جستجو و ابزارها برای تزریق اطلاعات خصوصی، جدید یا task-specific

مطالعه موردی تصحیح ایسلندی OpenAI برای مدل ذهنی مفید است، نه به‌عنوان recipe اجرایی AvalAI: مثال‌های few-shot رفتار را بهتر کردند، fine-tuning در آن setup تاریخی OpenAI سازگاری را افزایش داد و افزودن RAG امتیاز را کاهش داد، چون task بیشتر به رفتار آموخته‌شده نیاز داشت تا context اضافی. برای AvalAI این درس را به انتخاب eval-first تبدیل کنید: RAG را فقط وقتی failure از کمبود context می‌آید به کار ببرید، و وقتی failure از رفتار ناسازگار می‌آید از prompt قوی‌تر، schema، routing یا fine-tuning آینده استفاده کنید.

چه میزان دقت برای تولید "کافی است"؟

هنگام تصمیم‌گیری در مورد آمادگی راه‌حل LLM شما برای تولید، عوامل تجاری و فنی را در نظر بگیرید:

ملاحظات تجاری

• شناسایی موارد اصلی موفقیت و شکست با هزینه‌های مرتبط
• محاسبه دقت نقطه سر به سر بر اساس این هزینه‌ها
• اندازه‌گیری آمارهای تجربی (مانند امتیازات CSAT، دقت تصمیم‌گیری، زمان حل مشکل)

رویکردهای فنی

• طراحی سیستم برای مدیریت مناسب شکست‌ها
• در نظر گرفتن مصالحه بین دقت، تجربه کاربر و هزینه‌های عملیاتی
• وقتی confidence پایین است یا هزینه پاسخ اشتباه زیاد است، clarification بخواهید یا به انسان hand off کنید.
• برای اقدام‌های پراثر مانند پرداخت، تصمیم پزشکی/حقوقی/امنیتی یا write برگشت‌ناپذیر، assistant mode را به automation کامل ترجیح دهید.

منابع مرتبط

• مهندسی پرامپت
• انتخاب مدل
• تنظیم دقیق
• ارزیابی‌ها
• راهنمای Model Optimization در OpenAI
• بهترین شیوه‌های Evaluation در OpenAI