مدل‌های زبانی بزرگ یا LLMها هسته اصلی بسیاری از ابزارهای امروزی هوش مصنوعی هستند. چت‌بات‌ها، دستیارهای برنامه‌نویسی، ابزارهای تولید محتوا، موتورهای جست‌وجوی هوشمند، سیستم‌های خلاصه‌سازی، Agentها و بسیاری از قابلیت‌های هوش مصنوعی سازمانی بر پایه همین مدل‌ها ساخته می‌شوند.

اما LLM دقیقاً چیست؟ آیا مدل زبانی یک پایگاه داده بسیار بزرگ است؟ چگونه سؤال فارسی را دریافت و پاسخ تولید می‌کند؟ توکن، پارامتر، Transformer، Context Window، Fine-Tuning و Inference چه معنایی دارند؟ چرا یک مدل گاهی پاسخ دقیقی ارائه می‌دهد و گاهی دچار توهم می‌شود؟

در این مقاله، مدل‌های زبانی بزرگ را از مفاهیم پایه تا معماری، آموزش، انتخاب مدل و استفاده عملی از API بررسی می‌کنیم.

LLM چیست؟

LLM مخفف Large Language Model و به‌معنای «مدل زبانی بزرگ» است. مدل زبانی بزرگ نوعی مدل یادگیری ماشین است که روی حجم زیادی از داده‌های متنی آموزش می‌بیند تا الگوهای زبان را یاد بگیرد و براساس متن ورودی، خروجی مناسب تولید کند.

LLM می‌تواند کارهایی مانند موارد زیر را انجام دهد:

• پاسخ‌گویی به سؤال
• تولید و بازنویسی متن
• خلاصه‌سازی
• ترجمه
• استخراج اطلاعات
• دسته‌بندی متن
• تحلیل احساسات
• تولید کد
• توضیح کد
• ساخت خروجی JSON
• پاسخ‌گویی براساس اسناد
• فراخوانی ابزارها
• انجام برخی وظایف استدلالی
• مشارکت در Workflowهای Agentic

واژه «بزرگ» معمولاً به ترکیبی از این عوامل اشاره دارد:

• تعداد زیاد پارامترها
• حجم زیاد داده آموزشی
• هزینه محاسباتی قابل‌توجه
• ظرفیت مدل برای یادگیری الگوهای متنوع
• گستردگی وظایفی که مدل می‌تواند انجام دهد

با این حال، تعداد پارامتر بیشتر همیشه به‌معنای مدل بهتر نیست. کیفیت داده، معماری، روش آموزش، طول Context، Alignment، ابزارها و نحوه ارزیابی نیز اهمیت زیادی دارند.

مدل زبانی چگونه متن تولید می‌کند؟

در ساده‌ترین توضیح، مدل زبانی تلاش می‌کند توکن بعدی را براساس توکن‌های قبلی پیش‌بینی کند.

فرض کنید ورودی چنین باشد:

پایتخت ایران شهر

مدل احتمال توکن‌های مختلف را محاسبه می‌کند:

تهران: 0.92
اصفهان: 0.03
شیراز: 0.02
است: 0.01
سایر گزینه‌ها: 0.02

سپس یکی از گزینه‌ها براساس تنظیمات Sampling انتخاب می‌شود. این فرایند برای توکن بعدی دوباره تکرار می‌شود تا پاسخ کامل شکل بگیرد.

برای مثال:

پایتخت ایران شهر تهران است.

مدل پاسخ را یک‌باره از پایگاه داده بیرون نمی‌آورد؛ بلکه آن را مرحله‌به‌مرحله و توکن‌به‌توکن تولید می‌کند.

آیا LLM فقط کلمه بعدی را حدس می‌زند؟

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

• دستور زبان
• ارتباط مفهومی واژه‌ها
• ساختار متن
• سبک‌های نوشتاری
• الگوهای استدلال
• روابط میان موجودیت‌ها
• ساختار کد
• قالب داده
• ارتباط سؤال و پاسخ
• الگوی استفاده از ابزار

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

تفاوت مدل زبانی و چت‌بات چیست؟

مدل زبانی یک Model است، اما چت‌بات یک Application محسوب می‌شود.

یک چت‌بات ممکن است از اجزای زیر تشکیل شود:

رابط کاربری
مدل زبانی
System Prompt
تاریخچه گفتگو
Database
سیستم احراز هویت
RAG
ابزارها و Functionها
حافظه
سیستم مدیریت هزینه
فیلتر و Validation
Logging و Monitoring

بنابراین LLM فقط یکی از اجزای محصول نهایی است.

درواره نیز یک چت‌بات عمومی نیست؛ بلکه زیرساخت API برای اتصال نرم‌افزارها به مدل‌های هوش مصنوعی است. توسعه‌دهنده می‌تواند با استفاده از API درواره، چت‌بات، دستیار، Agent یا قابلیت هوشمند موردنظر خود را بسازد.

توکن چیست؟

مدل زبانی متن را مستقیماً به شکل کلمات کامل پردازش نمی‌کند. متن ابتدا توسط Tokenizer به واحدهایی به نام Token تبدیل می‌شود.

یک توکن ممکن است:

• یک کلمه کامل باشد.
• بخشی از یک کلمه باشد.
• یک نشانه نگارشی باشد.
• یک عدد باشد.
• بخشی از کد باشد.
• ترکیبی از چند کاراکتر باشد.

برای مثال، عبارت زیر:

هوش مصنوعی در برنامه‌نویسی

ممکن است براساس Tokenizer مدل به چند Token مختلف تقسیم شود. تعداد دقیق توکن‌ها میان مدل‌ها یکسان نیست.

متن فارسی ممکن است در برخی Tokenizerها نسبت به انگلیسی به تعداد توکن بیشتری تبدیل شود. عواملی مانند نیم‌فاصله، اعداد، حروف فارسی و عربی، کلمات ترکیبی و متن دوزبانه روی Tokenization اثر می‌گذارند.

چرا تعداد توکن اهمیت دارد؟

توکن روی موارد زیر اثر مستقیم دارد:

• هزینه API
• طول ورودی
• طول پاسخ
• سرعت پردازش
• ظرفیت Context Window
• مقدار حافظه موردنیاز
• امکان پردازش سند بلند

اگر یک درخواست شامل این بخش‌ها باشد:

System Prompt
تاریخچه گفتگو
پیام فعلی کاربر
متن اسناد RAG
خروجی ابزارها
پاسخ مدل

تمام این محتوا می‌تواند در مصرف توکن نقش داشته باشد.

Tokenizer چیست؟

Tokenizer متن را به Token ID تبدیل می‌کند:

متن
↓
Tokenization
↓
Token IDها
↓
ورودی شبکه عصبی

نمونه مفهومی:

"مدل زبانی"
↓
["مدل", " زبان", "ی"]
↓
[1842, 7321, 91]

این اعداد فقط نمونه‌اند و Token ID واقعی هر مدل متفاوت است.

در مرحله خروجی نیز مدل Token IDها را تولید می‌کند و Tokenizer آن‌ها را دوباره به متن قابل‌خواندن تبدیل می‌کند.

Embedding در مدل زبانی چیست؟

Token ID به‌تنهایی معنای زبانی ندارد. هر Token به یک بردار عددی یا Embedding تبدیل می‌شود.

نمونه ساده و غیرواقعی:

توکن "کتاب"
↓
[0.12, -0.44, 0.87, 0.03, ...]

در مدل واقعی، ابعاد این بردار بسیار بیشتر است.

Embedding به مدل اجازه می‌دهد روابط میان واژه‌ها، مفاهیم و Context را در فضای عددی نمایش دهد. بردار یک Token ثابت باقی نمی‌ماند؛ نمایش آن هنگام عبور از لایه‌های Transformer و براساس Context تغییر می‌کند.

برای مثال، مفهوم واژه «شیر» در دو جمله زیر یکسان نیست:

شیر را داخل لیوان ریخت.
شیر در جنگل زندگی می‌کند.

مدل با استفاده از Context باید معنای مناسب را تشخیص دهد.

پارامتر در LLM چیست؟

پارامترها مقادیر عددی داخلی مدل هستند که در فرایند آموزش تنظیم می‌شوند. این مقادیر تعیین می‌کنند ورودی چگونه در لایه‌های مختلف پردازش شود.

پارامتر را نباید با Fact موجود در Database یکسان دانست. مدل معمولاً اطلاعات را به‌شکل ردیف‌های قابل‌بازیابی ذخیره نمی‌کند؛ بلکه الگوها در تعداد بسیار زیادی وزن عددی توزیع می‌شوند.

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

پژوهش Chinchilla نشان داد برای بودجه محاسباتی ثابت، تعادل میان اندازه مدل و تعداد توکن‌های آموزشی اهمیت دارد و بزرگ کردن مدل بدون افزایش متناسب داده آموزشی الزاماً بهترین نتیجه را ایجاد نمی‌کند. جزئیات این پژوهش در مقاله Training Compute-Optimal Large Language Models ارائه شده است.

Transformer چیست؟

بیشتر مدل‌های زبانی مدرن بر پایه معماری Transformer ساخته شده‌اند. Transformer در مقاله معروف Attention Is All You Need معرفی شد.

پیش از Transformer، بسیاری از مدل‌های پردازش زبان از معماری‌هایی مانند RNN و LSTM استفاده می‌کردند. Transformer با تکیه بر Attention امکان پردازش موازی‌تر توالی و یادگیری ارتباط میان بخش‌های مختلف متن را فراهم کرد.

اجزای مهم Transformer عبارت‌اند از:

• Token Embedding
• Positional Information
• Self-Attention
• Multi-Head Attention
• Feed-Forward Network
• Normalization
• Residual Connection

تمام LLMها دقیقاً معماری یکسانی ندارند، اما Transformer پایه بسیاری از آن‌هاست.

Attention چیست؟

Attention به مدل کمک می‌کند هنگام پردازش هر Token، بخش‌های مرتبط Context را وزن‌دهی کند.

جمله زیر را در نظر بگیرید:

سارا کتاب را به مریم داد چون او فردا امتحان داشت.

برای درک ضمیر «او»، مدل باید ارتباط آن را با بخش‌های قبلی جمله بررسی کند. Attention برای محاسبه میزان ارتباط Tokenها با یکدیگر استفاده می‌شود.

به‌صورت مفهومی، هر Token سه نمایش ایجاد می‌کند:

• Query
• Key
• Value

مدل با مقایسه Query یک Token با Key سایر Tokenها، وزن توجه را محاسبه می‌کند و سپس ترکیبی وزن‌دار از Valueها می‌سازد.

نمای ساده:

Query × Key
↓
Attention Score
↓
Softmax
↓
ترکیب وزن‌دار Valueها

این توضیح ساده‌شده است، اما ایده اصلی را نشان می‌دهد.

Multi-Head Attention چیست؟

به‌جای یک الگوی Attention، Transformer از چند Head استفاده می‌کند. هر Head می‌تواند نوع متفاوتی از ارتباط را یاد بگیرد:

• ارتباط دستوری
• وابستگی دوربرد
• ارتباط موجودیت‌ها
• ارتباط سؤال و پاسخ
• ساختار کد
• ارتباط ضمیر و مرجع

خروجی Headها با یکدیگر ترکیب می‌شود و نمایش غنی‌تری از Context ایجاد می‌کند.

مدل چگونه ترتیب کلمات را می‌فهمد؟

Attention به‌تنهایی از ترتیب Tokenها آگاه نیست. به همین دلیل اطلاعات موقعیت یا Position به نمایش Tokenها اضافه می‌شود.

روش‌های مختلفی برای نمایش Position وجود دارد:

• Positional Encoding
• Learned Position Embedding
• Relative Position
• Rotary Position Embedding یا RoPE
• روش‌های توسعه‌یافته برای Context بلند

نوع Position Encoding بر توانایی مدل در پردازش توالی‌های بلند اثر می‌گذارد.

Context Window چیست؟

Context Window حداکثر مقدار اطلاعاتی است که مدل در یک درخواست می‌تواند پردازش کند. این مقدار معمولاً با Token اندازه‌گیری می‌شود.

Context می‌تواند شامل موارد زیر باشد:

• System Prompt
• پیام‌های قبلی گفتگو
• سؤال فعلی
• اسناد بازیابی‌شده
• مثال‌ها
• خروجی Toolها
• تصویر یا داده چندوجهی
• پاسخ تولیدشده

اگر حجم کل از ظرفیت مدل بیشتر شود، باید یکی از این کارها را انجام دهید:

• حذف پیام‌های قدیمی
• خلاصه‌سازی تاریخچه
• کاهش تعداد اسناد
• انتخاب Chunkهای مرتبط‌تر
• استفاده از مدل دارای Context بزرگ‌تر
• تقسیم کار به چند درخواست
• ذخیره حافظه خارج از Context
• محدود کردن طول خروجی

Context Window بزرگ به‌تنهایی تضمین نمی‌کند مدل تمام بخش‌های متن را با دقت یکسان استفاده کند. کیفیت بازیابی و چیدمان اطلاعات همچنان اهمیت دارد.

مراحل آموزش یک LLM

آموزش مدل زبانی معمولاً از چند مرحله تشکیل می‌شود. روش دقیق در هر خانواده مدل متفاوت است.

مرحله اول: جمع‌آوری و آماده‌سازی داده

داده آموزشی ممکن است از منابع متنوعی تشکیل شود:

• صفحات وب
• کتاب
• مقاله
• کد
• مستندات
• گفتگو
• داده دارای مجوز
• Datasetهای عمومی
• داده تولیدشده یا پالایش‌شده

قبل از آموزش، داده‌ها ممکن است:

• پاک‌سازی شوند.
• موارد تکراری حذف شوند.
• براساس کیفیت فیلتر شوند.
• اطلاعات نامناسب کاهش یابد.
• به Token تبدیل شوند.
• میان زبان‌ها و حوزه‌ها متعادل شوند.

کیفیت Dataset نقش مهمی در قابلیت‌ها، زبان‌ها، دانش و خطاهای مدل دارد.

مرحله دوم: Pretraining

در Pretraining، مدل روی حجم بزرگی از متن آموزش می‌بیند تا Token بعدی را پیش‌بینی کند.

نمونه:

ورودی:
هوش مصنوعی می‌تواند به توسعه‌دهندگان

هدف:
کمک

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

این فرایند بارها و روی تعداد زیادی Token تکرار می‌شود.

خروجی Pretraining معمولاً Base Model نام دارد.

مرحله سوم: Supervised Fine-Tuning

Base Model لزوماً دستور کاربر را به‌شکل مطلوب دنبال نمی‌کند. در Supervised Fine-Tuning یا SFT، نمونه‌هایی از دستور و پاسخ مناسب به مدل داده می‌شود.

نمونه:

{
  "instruction": "این متن را خلاصه کن",
  "input": "متن طولانی...",
  "output": "خلاصه دقیق..."
}

مدل یاد می‌گیرد:

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

مرحله چهارم: آموزش ترجیحات و Alignment

در این مرحله تلاش می‌شود رفتار مدل با ترجیحات انسانی یا اهداف تعریف‌شده هماهنگ‌تر شود.

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

• RLHF
• Reward Modeling
• PPO
• DPO
• روش‌های Preference Optimization
• بازخورد هوش مصنوعی
• داده‌های انتخاب پاسخ بهتر و بدتر

پژوهش InstructGPT نشان داد Fine-Tuning با بازخورد انسانی می‌تواند Instruction Following و کیفیت ترجیحی خروجی را نسبت به Base Model بهبود دهد. مقاله اصلی در Training Language Models to Follow Instructions with Human Feedback منتشر شده است.

مرحله پنجم: ارزیابی و بهبود

مدل در حوزه‌های مختلف ارزیابی می‌شود:

• دانش
• استدلال
• ریاضی
• کدنویسی
• زبان
• ترجمه
• Instruction Following
• Factuality
• Tool Calling
• خروجی ساختاریافته
• طول Context
• سرعت
• هزینه
• پایداری پاسخ

Benchmark عمومی مفید است، اما برای انتخاب مدل در محصول واقعی باید Dataset اختصاصی همان محصول نیز ساخته شود.

Base Model و Instruct Model چه تفاوتی دارند؟

Base Model

مدل پایه بیشتر برای ادامه دادن متن آموزش دیده است.

ورودی:

برای کاهش هزینه API بهتر است

ممکن است صرفاً متن را ادامه دهد.

Instruct Model

مدل Instruction-Tuned برای دنبال کردن دستور و مکالمه آماده‌تر است.

ورودی:

پنج روش کاهش هزینه API را فهرست کن.

خروجی مورد انتظار:

۱. کاهش Context غیرضروری
۲. انتخاب مدل اقتصادی‌تر
۳. استفاده از Prompt Caching
۴. محدود کردن طول خروجی
۵. Batch Processing

برای چت‌بات و بیشتر برنامه‌های کاربردی، معمولاً مدل Instruct یا Chat مناسب‌تر از Base Model است.

مدل Reasoning چیست؟

مدل Reasoning برای وظایفی طراحی یا بهینه شده که به تحلیل چندمرحله‌ای بیشتری نیاز دارند:

• حل مسئله
• برنامه‌ریزی
• کدنویسی پیچیده
• تحلیل ساختاریافته
• ریاضیات
• مقایسه چند گزینه
• اجرای Workflow چندمرحله‌ای

مدل Reasoning همیشه بهترین گزینه نیست. برای دسته‌بندی ساده، استخراج فیلد یا پاسخ کوتاه، یک مدل سریع‌تر و ارزان‌تر ممکن است نتیجه کافی ارائه دهد.

زمان و هزینه بیشتر نیز الزاماً صحت کامل را تضمین نمی‌کند.

مدل Multimodal چیست؟

مدل چندوجهی می‌تواند علاوه بر متن، انواع دیگری از ورودی یا خروجی را پردازش کند:

• تصویر
• صوت
• ویدئو
• فایل
• نمودار
• اسکرین‌شات

برای مثال، یک Vision-Language Model می‌تواند تصویر فاکتور را دریافت و اطلاعات آن را استخراج کند یا اسکرین‌شات رابط کاربری را تحلیل کند.

باید بررسی کنید مدل انتخاب‌شده دقیقاً از کدام Modalities پشتیبانی می‌کند. وجود واژه Multimodal به‌معنای پشتیبانی از تمام انواع ورودی و خروجی نیست.

Mixture of Experts چیست؟

Mixture of Experts یا MoE معماری‌ای است که در آن فقط بخشی از شبکه برای هر Token فعال می‌شود.

در یک مدل Dense، معمولاً تمام پارامترهای لایه‌های مربوط در هر مرحله محاسبه مشارکت دارند. در مدل MoE، یک Router تعدادی Expert را انتخاب می‌کند.

نمای ساده:

Token ورودی
↓
Router
↓
انتخاب چند Expert
↓
ترکیب خروجی Expertها

مزیت احتمالی MoE این است که مدل می‌تواند تعداد پارامتر کل زیادی داشته باشد، اما برای هر Token فقط بخشی از آن‌ها فعال شوند. با این حال Routing، Load Balancing، حافظه و توزیع مدل پیچیدگی‌های خود را دارند.

Inference چیست؟

Inference مرحله‌ای است که مدل آموزش‌دیده برای تولید خروجی استفاده می‌شود.

جریان ساده:

Prompt
↓
Tokenization
↓
اجرای مدل
↓
تولید Token بعدی
↓
تکرار تا پایان پاسخ
↓
Decode کردن Tokenها
↓
متن خروجی

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

تفاوت Training و Inference

Fine-Tuning نیز نوعی Training اضافی روی مدل موجود است.

Prompt چیست؟

Prompt ورودی یا دستور ارسالی به مدل است. Prompt می‌تواند شامل بخش‌های زیر باشد:

• نقش مدل
• هدف
• Context
• سؤال
• محدودیت‌ها
• مثال‌ها
• قالب خروجی
• معیار کیفیت

Prompt ساده:

این متن را خلاصه کن.

Prompt دقیق‌تر:

متن زیر را در حداکثر پنج نکته خلاصه کن.

قواعد:
- پاسخ فارسی باشد.
- اعداد مهم حفظ شوند.
- اطلاعاتی خارج از متن اضافه نشود.
- هر نکته حداکثر دو جمله باشد.

متن:
...

Prompt دقیق‌تر معمولاً خروجی قابل‌کنترل‌تری ایجاد می‌کند، اما هیچ Promptی تضمین کامل برای صحت پاسخ ایجاد نمی‌کند.

System Prompt چیست؟

System Prompt رفتار کلی مدل را تعریف می‌کند:

{
  "role": "system",
  "content": "شما یک دستیار فارسی برای پاسخ‌گویی براساس مستندات محصول هستید."
}

پیام کاربر:

{
  "role": "user",
  "content": "چگونه API Key بسازم؟"
}

System Prompt می‌تواند موارد زیر را مشخص کند:

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

System Prompt جایگزین Validation، احراز هویت یا کنترل Backend نیست. کاربر نباید فقط با دستور متنی از دسترسی غیرمجاز منع شود؛ سطح دسترسی باید در کد برنامه کنترل شود.

Zero-Shot، One-Shot و Few-Shot چیست؟

Zero-Shot

فقط دستور ارائه می‌شود:

احساس این نظر را به مثبت، منفی یا خنثی دسته‌بندی کن:

«کیفیت خوب بود اما ارسال دیر انجام شد.»

One-Shot

یک نمونه ارائه می‌شود:

نمونه:
«محصول عالی بود.» → مثبت

اکنون:
«کیفیت خوب بود اما ارسال دیر انجام شد.» →

Few-Shot

چند نمونه ارائه می‌شود:

«عالی بود.» → مثبت
«اصلاً راضی نبودم.» → منفی
«قابل‌قبول بود.» → خنثی

اکنون:
«کیفیت خوب بود اما ارسال دیر انجام شد.» →

پژوهش Language Models are Few-Shot Learners نشان داد مدل‌های زبانی بزرگ می‌توانند بسیاری از وظایف را با دستور و چند نمونه داخل Context انجام دهند، بدون اینکه وزن‌های مدل برای همان وظیفه تغییر کند.

تنظیمات مهم تولید پاسخ

API مدل زبانی معمولاً چند پارامتر برای کنترل خروجی دارد. پشتیبانی دقیق هر پارامتر به مدل و API وابسته است.

Temperature

Temperature میزان تنوع Sampling را کنترل می‌کند.

مقدار پایین‌تر:

• خروجی باثبات‌تر
• مناسب استخراج و پاسخ واقع‌محور
• تنوع کمتر

مقدار بالاتر:

• خروجی متنوع‌تر
• مناسب ایده‌پردازی
• احتمال نوسان بیشتر

نمونه:

{
  "temperature": 0.2
}

Temperature پایین صحت را تضمین نمی‌کند و فقط نحوه Sampling را تغییر می‌دهد.

Top P

Top P از Nucleus Sampling استفاده می‌کند. مدل مجموعه‌ای از Tokenها را انتخاب می‌کند که مجموع احتمال آن‌ها به آستانه مشخص برسد.

{
  "top_p": 0.9
}

معمولاً بهتر است بدون ارزیابی، Temperature و Top P را هم‌زمان به‌شدت تغییر ندهید.

Top K

Top K انتخاب را به K توکن دارای بیشترین احتمال محدود می‌کند:

{
  "top_k": 40
}

تمام مدل‌ها یا Endpointها از top_k پشتیبانی نمی‌کنند.

Max Tokens

حداکثر طول خروجی را کنترل می‌کند:

{
  "max_tokens": 500
}

نام دقیق این پارامتر ممکن است میان مدل‌ها یا APIها متفاوت باشد.

مقدار بسیار کم می‌تواند پاسخ را ناقص کند و مقدار بسیار زیاد ممکن است هزینه و Latency را افزایش دهد.

Stop Sequence

Stop Sequence تولید را هنگام مشاهده یک عبارت مشخص متوقف می‌کند:

{
  "stop": [
    "END"
  ]
}

برای قالب‌های متنی خاص مفید است، اما در خروجی JSON بهتر است در صورت پشتیبانی مدل از Structured Output استفاده شود.

مدل زبانی چه کاربردهایی دارد؟

تولید محتوا

• پیش‌نویس مقاله
• توضیحات محصول
• کپشن
• ایمیل
• سناریو
• عنوان
• بازنویسی

خروجی باید از نظر واقعیت، لحن برند و اصالت بررسی شود.

خلاصه‌سازی

• گزارش
• جلسه
• مقاله
• سند
• مکالمه
• تیکت پشتیبانی

برای سند بلند باید Chunking، Context و حفظ ارجاع‌ها مدیریت شود.

استخراج اطلاعات

متن:

نام مشتری: سارا احمدی
مبلغ سفارش: ۲٬۵۰۰٬۰۰۰ تومان
وضعیت: ارسال‌شده

خروجی:

{
  "customer_name": "سارا احمدی",
  "amount_toman": 2500000,
  "status": "shipped"
}

برای این کاربرد، Structured Output و Validation اهمیت زیادی دارند.

دسته‌بندی

• موضوع تیکت
• احساس مشتری
• اولویت پیام
• نوع سند
• Intent کاربر
• دسته محصول

برنامه‌نویسی

• تولید کد
• تکمیل کد
• توضیح خطا
• Refactoring
• نوشتن Test
• تولید Documentation
• تبدیل زبان برنامه‌نویسی

کد تولیدشده باید Build، Test و Review شود.

RAG

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

Agent

مدل می‌تواند براساس هدف، ابزار مناسب را انتخاب کند:

دریافت درخواست
↓
تصمیم‌گیری
↓
فراخوانی Tool
↓
بررسی نتیجه
↓
ادامه فرایند
↓
پاسخ نهایی

پردازش چندوجهی

مدل‌های Multimodal می‌توانند برای تحلیل تصویر، صوت، فایل یا ویدئو استفاده شوند.

محدودیت‌های LLM

توهم هوش مصنوعی

مدل ممکن است پاسخ نادرست یا بدون منبع تولید کند. برای کاهش آن می‌توان از RAG، Citation، Verification، Tool و Evals استفاده کرد.

دانش قدیمی یا ناکافی

مدل لزوماً از آخرین اطلاعات آگاه نیست. داده فعلی باید از API، Search، Database یا اسناد بروزشده دریافت شود.

محدودیت Context

مدل نمی‌تواند حجم نامحدودی از اطلاعات را در یک درخواست پردازش کند.

حساسیت به Prompt

تغییر کوچک در دستور یا ترتیب اطلاعات ممکن است خروجی را تغییر دهد.

محاسبات غیرقطعی

برای محاسبات دقیق بهتر است از Calculator، Code یا ابزار قطعی استفاده شود.

سوگیری داده

مدل می‌تواند الگوها و سوگیری‌های موجود در داده آموزشی را بازتاب دهد.

هزینه و Latency

مدل قوی‌تر ممکن است گران‌تر یا کندتر باشد. انتخاب مدل باید براساس نیاز واقعی انجام شود.

نبود تضمین ساختاری

اگر خروجی باید JSON معتبر باشد، Prompt ساده کافی نیست. در صورت پشتیبانی مدل، Structured Output و سپس Schema Validation استفاده کنید.

تفاوت Prompt Engineering، RAG و Fine-Tuning

چه زمانی Prompt کافی است؟

• دستور ساده است.
• دانش عمومی مدل کافی است.
• چند مثال داخل Context جواب می‌دهد.
• قالب خروجی پیچیده نیست.

چه زمانی RAG مناسب است؟

• پاسخ باید از اسناد داخلی بیاید.
• اطلاعات مرتب بروزرسانی می‌شود.
• Citation لازم است.
• داده نباید وارد Training شود.
• تعداد اسناد زیاد است.

چه زمانی Fine-Tuning مناسب است؟

• رفتار مشخص بارها تکرار می‌شود.
• سبک یا ساختار خروجی باید پایدارتر شود.
• Dataset آموزشی باکیفیت وجود دارد.
• Prompt بسیار طولانی و تکراری شده است.
• Base Model در وظیفه تخصصی عملکرد کافی ندارد.

Fine-Tuning راه استانداردی برای اضافه کردن اطلاعات لحظه‌ای نیست؛ برای دانش در حال تغییر معمولاً RAG مناسب‌تر است.

چگونه مدل مناسب انتخاب کنیم؟

به‌جای انتخاب صرفاً براساس نام یا تعداد پارامتر، این معیارها را بررسی کنید:

نوع وظیفه

• چت عمومی
• کدنویسی
• استدلال
• ترجمه
• استخراج داده
• پردازش تصویر
• تولید محتوا
• Tool Calling

کیفیت زبان فارسی

مدل را با سؤال‌ها و متن‌های واقعی فارسی آزمایش کنید:

• دستور رسمی
• متن محاوره‌ای
• اعداد فارسی
• نیم‌فاصله
• اصطلاحات فنی
• متن دوزبانه
• نام‌های فارسی

Context Window

اگر اسناد بلند یا تاریخچه گفتگو دارید، Context کافی اهمیت دارد؛ اما Context بزرگ‌تر معمولاً می‌تواند هزینه بیشتری نیز ایجاد کند.

سرعت

برای رابط چت، زمان شروع پاسخ و سرعت تولید Token مهم است.

هزینه

هزینه Input، Output، Tool Call، تصویر و سایر قابلیت‌ها را جداگانه بررسی کنید.

Structured Output

اگر خروجی وارد Database یا Workflow می‌شود، پشتیبانی از JSON Schema ارزشمند است.

Tool Calling

برای Agent و اتصال به سیستم‌های بیرونی، توانایی Function Calling مهم است.

قابلیت Multimodal

مشخص کنید مدل چه نوع ورودی و خروجی را واقعاً پشتیبانی می‌کند.

پایداری

مدل باید روی یک مجموعه تست ثابت چند بار اجرا و نرخ موفقیت آن اندازه‌گیری شود.

نسبت کیفیت به هزینه

بهترین مدل عمومی لزوماً بهترین مدل اقتصادی برای وظیفه شما نیست.

ساخت Dataset ارزیابی مدل

قبل از انتخاب مدل، حداقل ۵۰ تا ۱۰۰ نمونه واقعی جمع‌آوری کنید:

{
  "id": "case-001",
  "input": "متن ورودی",
  "expected": {
    "category": "support",
    "priority": "high"
  },
  "criteria": [
    "خروجی JSON معتبر باشد",
    "category صحیح باشد",
    "priority صحیح باشد"
  ]
}

دسته‌های مختلف اضافه کنید:

• حالت عادی
• ورودی ناقص
• ورودی مبهم
• متن طولانی
• فارسی و انگلیسی ترکیبی
• عدد و تاریخ
• داده نامعتبر
• سؤال بدون پاسخ
• سناریوی مرزی

سپس مدل‌ها را با Prompt و تنظیمات یکسان مقایسه کنید.

معیارهای ارزیابی LLM

• Accuracy
• Factuality
• Relevance
• Completeness
• Instruction Following
• JSON Validity
• Citation Accuracy
• Refusal Quality
• Latency
• Time to First Token
• Tokens per Second
• Cost per Request
• Cost per Successful Task
• Tool Call Success Rate
• Human Preference

برای محصول واقعی، «هزینه هر وظیفه موفق» از هزینه خام هر Token معنی‌دارتر است.

اگر مدل ارزان‌تر در ۳۰ درصد موارد شکست بخورد و Retry نیاز داشته باشد، ممکن است هزینه نهایی آن از مدل دقیق‌تر بیشتر شود.

محاسبه تقریبی هزینه درخواست

اگر قیمت مدل بر حسب یک میلیون Token باشد:

هزینه ورودی =
تعداد توکن ورودی
تقسیم بر ۱٬۰۰۰٬۰۰۰
ضرب‌در قیمت یک میلیون توکن ورودی

هزینه خروجی =
تعداد توکن خروجی
تقسیم بر ۱٬۰۰۰٬۰۰۰
ضرب‌در قیمت یک میلیون توکن خروجی

هزینه کل =
هزینه ورودی + هزینه خروجی

مثال فرضی:

توکن ورودی: ۲۰٬۰۰۰
توکن خروجی: ۲٬۰۰۰

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

اتصال به LLM با API درواره و Python

ابتدا Requests را نصب کنید:

pip install requests

Environment Variable:

export DARVAREH_API_KEY="YOUR_DARVAREH_API_KEY"
export DARVAREH_MODEL_ID="YOUR_MODEL_ID"

در Windows PowerShell:

$env:DARVAREH_API_KEY="YOUR_DARVAREH_API_KEY"
$env:DARVAREH_MODEL_ID="YOUR_MODEL_ID"

کد Python:

import os

import requests


API_URL = (
    "https://api.darvareh.ir/v1/"
    "chat/completions"
)

api_key = os.environ.get(
    "DARVAREH_API_KEY"
)

model_id = os.environ.get(
    "DARVAREH_MODEL_ID"
)

if not api_key:
    raise RuntimeError(
        "DARVAREH_API_KEY is missing"
    )

if not model_id:
    raise RuntimeError(
        "DARVAREH_MODEL_ID is missing"
    )

response = requests.post(
    API_URL,
    headers={
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json",
    },
    json={
        "model": model_id,
        "messages": [
            {
                "role": "system",
                "content": (
                    "شما یک دستیار دقیق فارسی هستید. "
                    "اگر اطلاعات کافی ندارید، "
                    "صریحاً اعلام کنید."
                ),
            },
            {
                "role": "user",
                "content": (
                    "مدل زبانی بزرگ را "
                    "در سه نکته توضیح بده."
                ),
            },
        ],
        "temperature": 0.2,
    },
    timeout=45,
)

response.raise_for_status()

data = response.json()

answer = (
    data.get("choices", [{}])[0]
    .get("message", {})
    .get("content", "")
)

if not answer:
    raise RuntimeError(
        "Model returned an empty response"
    )

print(answer)

نکات مهم:

• کلید API داخل کد قرار نگرفته است.
• برای درخواست Timeout تعریف شده است.
• خطای HTTP با raise_for_status مدیریت می‌شود.
• وجود پاسخ بررسی می‌شود.
• Model ID از Environment Variable خوانده می‌شود.

اتصال به LLM با JavaScript و Node.js

در Node.js جدید می‌توان از fetch داخلی استفاده کرد:

const apiKey =
  process.env.DARVAREH_API_KEY

const modelId =
  process.env.DARVAREH_MODEL_ID

if (!apiKey) {
  throw new Error(
    'DARVAREH_API_KEY is missing'
  )
}

if (!modelId) {
  throw new Error(
    'DARVAREH_MODEL_ID is missing'
  )
}

const controller = new AbortController()

const timeoutId = setTimeout(() => {
  controller.abort()
}, 45_000)

try {
  const response = await fetch(
    'https://api.darvareh.ir/v1/chat/completions',
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${apiKey}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        model: modelId,
        messages: [
          {
            role: 'system',
            content:
              'شما یک دستیار دقیق فارسی هستید.'
          },
          {
            role: 'user',
            content:
              'LLM را با یک مثال ساده توضیح بده.'
          }
        ],
        temperature: 0.2
      }),
      signal: controller.signal
    }
  )

  if (!response.ok) {
    const errorBody = await response.text()

    console.error(
      'Model request failed',
      response.status,
      errorBody.slice(0, 500)
    )

    throw new Error(
      `Request failed: ${response.status}`
    )
  }

  const data = await response.json()

  const answer =
    data.choices?.[0]?.message?.content

  if (!answer) {
    throw new Error(
      'Model returned an empty response'
    )
  }

  console.log(answer)
} finally {
  clearTimeout(timeoutId)
}

کلید API نباید در JavaScript سمت مرورگر، Repository عمومی یا متغیر دارای پیشوند عمومی قرار گیرد. درخواست باید از Backend ارسال شود.

نمونه ساخت تابع قابل‌استفاده مجدد

from typing import Any

import requests


class LLMClient:
    def __init__(
        self,
        api_key: str,
        model_id: str,
    ) -> None:
        self.api_key = api_key
        self.model_id = model_id
        self.base_url = (
            "https://api.darvareh.ir/v1"
        )

    def chat(
        self,
        messages: list[dict[str, str]],
        temperature: float = 0.2,
    ) -> str:
        response = requests.post(
            f"{self.base_url}/chat/completions",
            headers={
                "Authorization": (
                    f"Bearer {self.api_key}"
                ),
                "Content-Type": (
                    "application/json"
                ),
            },
            json={
                "model": self.model_id,
                "messages": messages,
                "temperature": temperature,
            },
            timeout=45,
        )

        response.raise_for_status()

        data: dict[str, Any] = (
            response.json()
        )

        try:
            content = data["choices"][0][
                "message"
            ]["content"]
        except (
            KeyError,
            IndexError,
            TypeError,
        ) as error:
            raise RuntimeError(
                "Unexpected API response"
            ) from error

        if not isinstance(content, str):
            raise RuntimeError(
                "Response content is not a string"
            )

        return content.strip()

استفاده:

import os


client = LLMClient(
    api_key=os.environ[
        "DARVAREH_API_KEY"
    ],
    model_id=os.environ[
        "DARVAREH_MODEL_ID"
    ],
)

answer = client.chat(
    messages=[
        {
            "role": "system",
            "content": (
                "پاسخ را به زبان فارسی "
                "و در قالب فهرست بنویس."
            ),
        },
        {
            "role": "user",
            "content": (
                "سه کاربرد LLM در "
                "توسعه نرم‌افزار چیست؟"
            ),
        },
    ]
)

print(answer)

در محیط Production موارد زیر را نیز اضافه کنید:

• Retry با Backoff
• Rate Limiting
• Logging ساختاریافته
• ثبت مصرف Token
• محدودیت بودجه
• Validation پاسخ
• Fallback
• Monitoring
• Circuit Breaker
• شناسه Request
• مدیریت خطای 429 و 5xx

تاریخچه گفتگو چگونه ارسال می‌شود؟

مدل معمولاً حافظه دائمی داخلی از کاربران API ندارد. برنامه باید پیام‌های لازم را در درخواست ارسال کند:

{
  "messages": [
    {
      "role": "system",
      "content": "شما یک دستیار فارسی هستید."
    },
    {
      "role": "user",
      "content": "نام من سارا است."
    },
    {
      "role": "assistant",
      "content": "خوشحالم سارا."
    },
    {
      "role": "user",
      "content": "نام من چیست؟"
    }
  ]
}

با طولانی شدن گفتگو، تعداد Token افزایش می‌یابد. راهکارها:

• نگهداری تعداد محدودی پیام اخیر
• خلاصه‌سازی گفتگو
• استخراج Factهای مهم
• ذخیره حافظه در Database
• بازیابی حافظه مرتبط
• حذف پیام‌های بی‌اثر

حافظه برنامه با Context Window مدل یکسان نیست.

LLM چگونه به اطلاعات اختصاصی متصل می‌شود؟

مدل پایه معمولاً اسناد خصوصی سازمان را نمی‌شناسد. چند روش وجود دارد:

قرار دادن مستقیم Context

برای متن کوتاه:

براساس متن زیر پاسخ بده:

[متن سند]

سؤال:
...

RAG

برای مجموعه اسناد بزرگ:

سؤال
↓
Embedding
↓
Vector Search یا Hybrid Search
↓
Reranking
↓
Context مرتبط
↓
LLM

Tool Calling

برای اطلاعات زنده یا عملیات:

مدل
↓
فراخوانی get_order_status
↓
Backend
↓
نتیجه واقعی
↓
مدل
↓
پاسخ کاربر

Fine-Tuning

برای تغییر رفتار، قالب یا وظیفه تخصصی تکرارشونده.

Structured Output چیست؟

اگر پاسخ باید وارد برنامه شود، متن آزاد همیشه مناسب نیست.

Prompt:

نام، ایمیل و موضوع پیام را استخراج کن.

خروجی آزاد ممکن است چنین باشد:

نام کاربر سارا است و موضوع پیام او پشتیبانی است.

اما برنامه به JSON نیاز دارد:

{
  "name": "سارا",
  "email": "sara@example.com",
  "topic": "support"
}

در صورت پشتیبانی مدل، از Structured Output یا JSON Schema استفاده کنید. سپس خروجی را در Backend با Zod، Pydantic یا ابزار مشابه اعتبارسنجی کنید.

حتی JSON معتبر می‌تواند محتوای نادرست داشته باشد؛ بنابراین Validation ساختاری با Fact Verification متفاوت است.

Function Calling و Tool Calling چیست؟

Tool Calling به مدل اجازه می‌دهد به‌جای حدس زدن نتیجه، درخواست اجرای یک ابزار را ایجاد کند.

تعریف ابزار مفهومی:

{
  "name": "get_weather",
  "description": "دریافت وضعیت آب‌وهوا",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      }
    },
    "required": [
      "city"
    ]
  }
}

مدل ممکن است چنین خروجی‌ای تولید کند:

{
  "name": "get_weather",
  "arguments": {
    "city": "تهران"
  }
}

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

نکته مهم: مدل نباید مستقیماً اجازه اجرای عملیات مهم را داشته باشد. Backend باید:

• نام ابزار را بررسی کند.
• Argumentها را Validate کند.
• سطح دسترسی کاربر را کنترل کند.
• Timeout تعیین کند.
• نتیجه را ثبت کند.
• برای عملیات مهم تأیید بگیرد.
• تعداد Loopهای Agent را محدود کند.

RAG بهتر است یا مدل دارای Context بزرگ؟

این دو جایگزین کامل یکدیگر نیستند.

Context بزرگ

مناسب برای:

• تحلیل یک سند بلند
• مقایسه چند فایل محدود
• نگهداری تاریخچه بیشتر
• پردازش کد نسبتاً بزرگ

RAG

مناسب برای:

• مجموعه اسناد بسیار بزرگ
• دانش بروزشونده
• جست‌وجوی هدفمند
• Citation
• کاهش Context غیرضروری
• کنترل هزینه

حتی اگر مدل Context بسیار بزرگی داشته باشد، ارسال تمام اسناد در هر درخواست معمولاً از نظر هزینه و دقت بهینه نیست.

چگونه کیفیت Prompt را افزایش دهیم؟

یک ساختار عملی:

ROLE:
نقش مدل

TASK:
وظیفه دقیق

CONTEXT:
اطلاعات لازم

RULES:
محدودیت‌ها

OUTPUT FORMAT:
قالب پاسخ

EXAMPLES:
نمونه‌های لازم

USER INPUT:
ورودی کاربر

نمونه:

ROLE:
شما تحلیل‌گر بازخورد مشتری هستید.

TASK:
موضوع و احساس پیام را مشخص کن.

RULES:
- اطلاعاتی خارج از پیام اضافه نکن.
- اگر موضوع نامشخص است، category را unknown قرار بده.
- sentiment فقط یکی از positive، neutral یا negative باشد.

OUTPUT:
فقط JSON معتبر با فیلدهای category و sentiment.

USER INPUT:
کیفیت محصول خوب بود اما ارسال خیلی دیر انجام شد.

چگونه هزینه LLM را کاهش دهیم؟

• Context غیرضروری را حذف کنید.
• Promptهای تکراری را کوتاه و استاندارد کنید.
• برای وظایف ساده مدل اقتصادی‌تر انتخاب کنید.
• طول خروجی را محدود کنید.
• تاریخچه گفتگو را خلاصه کنید.
• Retrieval دقیق‌تر انجام دهید.
• از Reranking برای کاهش Chunkهای نامرتبط استفاده کنید.
• پاسخ‌های قابل‌استفاده مجدد را Cache کنید.
• درخواست‌های غیرضروری را حذف کنید.
• Retry را فقط برای خطاهای مناسب انجام دهید.
• هزینه هر قابلیت را جداگانه پایش کنید.
• مدل را براساس دشواری درخواست Route کنید.

Model Routing چیست؟

در Model Routing، تمام درخواست‌ها به یک مدل واحد ارسال نمی‌شوند.

نمونه:

دسته‌بندی ساده
↓
مدل سریع و اقتصادی

کدنویسی پیچیده
↓
مدل Coding

تحلیل چندمرحله‌ای
↓
مدل Reasoning

تحلیل تصویر
↓
مدل Multimodal

Routing می‌تواند براساس این عوامل انجام شود:

• نوع Task
• طول ورودی
• نیاز به تصویر
• بودجه کاربر
• Latency مورد انتظار
• سطح پیچیدگی
• نیاز به Tool Calling
• کیفیت موردنیاز

برای طراحی Routing، ابتدا باید Evals داشته باشید. انتخاب مدل بدون اندازه‌گیری می‌تواند هزینه را کاهش دهد اما نرخ خطا را افزایش دهد.

Fallback چیست؟

اگر مدل اصلی با خطا مواجه شود، سیستم می‌تواند مدل دیگری را امتحان کند:

درخواست
↓
مدل اصلی
↓
خطا یا Timeout
↓
مدل جایگزین

Fallback باید با احتیاط طراحی شود:

• مدل جایگزین قابلیت لازم را داشته باشد.
• Context Length کافی داشته باشد.
• Structured Output سازگار باشد.
• Tool Calling آن بررسی شده باشد.
• Retry Loop نامحدود ایجاد نشود.
• هزینه حداکثری تعیین شود.
• تفاوت رفتار مدل‌ها ثبت شود.

LLM در Production به چه اجزایی نیاز دارد؟

یک درخواست ساده API برای Demo کافی است؛ اما محصول Production معمولاً به اجزای بیشتری نیاز دارد:

Client
↓
Backend API
↓
Authentication
↓
Rate Limiting
↓
Validation
↓
Prompt Builder
↓
Model Router
↓
LLM API
↓
Output Validation
↓
Logging و Usage
↓
Response

قابلیت‌های تکمیلی:

• RAG
• Cache
• Queue
• Streaming
• Retry
• Fallback
• Evals
• Moderation متناسب با محصول
• Feedback کاربر
• Cost Monitoring
• Observability
• Human Review
• Versioning برای Prompt

اشتباهات رایج در استفاده از LLM

انتخاب یک مدل برای تمام وظایف

مدل مناسب تولید محتوا ممکن است برای Coding یا استخراج JSON بهترین گزینه نباشد.

قرار دادن کلید API در Frontend

کلید باید در Backend و Environment Variable نگهداری شود.

اعتماد کامل به پاسخ

خروجی مدل می‌تواند نادرست باشد. ادعاهای واقعی، عدد، Citation و کد باید بررسی شوند.

ارسال تمام Database به Context

این کار هزینه را افزایش می‌دهد و ممکن است دقت را کاهش دهد. Retrieval هدفمند بهتر است.

استفاده از Prompt به‌جای کنترل دسترسی

System Prompt نمی‌تواند جایگزین Authorization در Backend شود.

نداشتن Evals

بدون Dataset ثابت نمی‌توان کیفیت نسخه‌های مختلف Prompt و مدل را مقایسه کرد.

نداشتن Timeout

درخواست مدل ممکن است طولانی شود. Timeout و مدیریت خطا ضروری است.

Retry برای تمام خطاها

برای خطای Validation یا Authentication نباید Retry کورکورانه انجام شود.

Log کردن اطلاعات حساس

Prompt و پاسخ ممکن است اطلاعات خصوصی داشته باشند. سیاست Logging و نگهداری داده باید مشخص باشد.

تصور اینکه مدل بزرگ‌تر همیشه بهتر است

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

استفاده از Benchmark به‌عنوان تنها معیار

Benchmark عمومی لزوماً عملکرد روی داده فارسی و کاربرد اختصاصی شما را نشان نمی‌دهد.

چک‌لیست انتخاب و استفاده از LLM

انتخاب مدل

• نوع وظیفه چیست؟
• زبان فارسی چقدر اهمیت دارد؟
• Context موردنیاز چقدر است؟
• Latency قابل‌قبول چیست؟
• بودجه هر درخواست چقدر است؟
• آیا Tool Calling لازم است؟
• آیا Structured Output لازم است؟
• آیا ورودی تصویر یا صوت وجود دارد؟
• آیا مدل روی Dataset واقعی تست شده است؟

طراحی Prompt

• نقش مشخص است؟
• هدف دقیق است؟
• Context کافی است؟
• محدودیت‌ها تعریف شده‌اند؟
• قالب خروجی مشخص است؟
• مثال لازم ارائه شده است؟
• امکان اعلام ندانستن وجود دارد؟

Backend

• کلید API در سرور است؟
• ورودی Validate می‌شود؟
• Rate Limit وجود دارد؟
• Timeout تعریف شده است؟
• Retry کنترل‌شده است؟
• خروجی Validate می‌شود؟
• مصرف ثبت می‌شود؟
• خطاها بدون Secret ثبت می‌شوند؟

کیفیت

• Dataset ارزیابی وجود دارد؟
• پاسخ‌های بدون منبع بررسی می‌شوند؟
• Hallucination اندازه‌گیری می‌شود؟
• نسخه Prompt ثبت می‌شود؟
• مدل‌های جایگزین مقایسه شده‌اند؟
• Feedback کاربر جمع‌آوری می‌شود؟

پرسش‌های متداول درباره LLM

LLM مخفف چیست؟

LLM مخفف Large Language Model و به‌معنای مدل زبانی بزرگ است.

آیا ChatGPT همان LLM است؟

ChatGPT یک محصول گفتگو‌محور است که از مدل‌های زبانی و اجزای نرم‌افزاری دیگر استفاده می‌کند. LLM خود مدل پایه تولید و پردازش زبان است.

آیا LLM یک Database است؟

خیر. مدل زبانی اطلاعات را مانند ردیف‌های یک Database نگهداری و بازیابی نمی‌کند. دانش و الگوها در پارامترهای مدل توزیع شده‌اند.

آیا LLM اینترنت دارد؟

خود مدل الزاماً به اینترنت متصل نیست. دسترسی به Search یا داده زنده باید توسط ابزار و معماری برنامه فراهم شود.

آیا LLM همیشه پاسخ درست می‌دهد؟

خیر. مدل ممکن است دچار توهم، خطای استدلالی یا اطلاعات قدیمی شود.

آیا تعداد پارامتر بیشتر همیشه بهتر است؟

خیر. کیفیت داده، روش آموزش، معماری، Alignment و تناسب با وظیفه اهمیت دارند.

Context Window چیست؟

حداکثر حجم اطلاعاتی است که مدل در یک درخواست می‌تواند پردازش کند و معمولاً برحسب Token بیان می‌شود.

تفاوت LLM و هوش مصنوعی مولد چیست؟

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

آیا برای استفاده از LLM باید مدل را آموزش دهیم؟

خیر. در بیشتر پروژه‌ها می‌توان از مدل آماده از طریق API استفاده کرد. Training یا Fine-Tuning فقط برای نیازهای خاص لازم است.

چگونه به یک LLM متصل شویم؟

می‌توانید از API استفاده کنید. درواره یک API یکپارچه برای اتصال نرم‌افزار به مدل‌های مختلف هوش مصنوعی ارائه می‌دهد.

Model ID را از کجا پیدا کنیم؟

فهرست مدل‌ها و Model IDهای درواره در صفحه مدل‌های درواره قرار دارد.

جمع‌بندی

LLM یا مدل زبانی بزرگ، مدلی است که روی حجم زیادی از داده متنی آموزش می‌بیند تا الگوهای زبان را یاد بگیرد و پاسخ را به‌صورت توکن‌به‌توکن تولید کند.

معماری Transformer و مکانیزم Attention پایه بسیاری از مدل‌های زبانی مدرن را تشکیل می‌دهند. مدل ابتدا در مرحله Pretraining الگوهای زبان را می‌آموزد و سپس ممکن است با SFT، بازخورد انسانی و روش‌های Alignment برای دنبال کردن بهتر دستورها آماده شود.

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

1. انتخاب مدل مناسب
2. Prompt Engineering
3. مدیریت Context
4. Validation ورودی و خروجی
5. RAG برای دانش اختصاصی
6. Tool Calling برای داده زنده
7. کنترل توهم
8. مدیریت هزینه
9. Evals
10. Monitoring
11. Retry و Fallback
12. نگهداری امن کلید API

برای آزمایش و استفاده از مدل‌های مختلف می‌توانید در درواره ثبت‌نام کرده و Model ID مناسب را از فهرست مدل‌های درواره انتخاب کنید.

مقالات مرتبط

• راهنمای کامل مدل‌های هوش مصنوعی
• هوش مصنوعی چیست؟ راهنمای جامع Artificial Intelligence
• Inference چیست؟ راهنمای اجرای مدل هوش مصنوعی
• توکن در API هوش مصنوعی چیست؟
• Context Window چیست؟
• Temperature در هوش مصنوعی چیست؟
• Top P در هوش مصنوعی چیست؟
• Top K در هوش مصنوعی چیست؟
• Max Tokens چیست؟
• RAG چیست؟ آموزش Retrieval-Augmented Generation
• Fine-Tuning مدل‌های زبانی با LoRA و QLoRA
• راهنمای ارزیابی مدل هوش مصنوعی و Evals
• راهنمای کامل API هوش مصنوعی

منابع تکمیلی

• مقاله Attention Is All You Need
• مقاله Language Models are Few-Shot Learners
• مقاله Training Compute-Optimal Large Language Models
• مقاله Training Language Models to Follow Instructions with Human Feedback

برای مطالعه شرایط استفاده و محدودیت‌های مسئولیت، صفحه «سلب مسئولیت» را مشاهده کنید.