مدل‌های زبانی بزرگ یا Large Language Models (LLMs) هسته بسیاری از سیستم‌های هوش مصنوعی مدرن هستند؛ از ChatGPT و دستیارهای برنامه‌نویسی گرفته تا Agentهای هوشمند، سیستم‌های پشتیبانی مشتری و CRMهای مبتنی بر هوش مصنوعی.

برای استفاده حرفه‌ای از LLM لازم نیست ابتدا وارد تمام جزئیات ریاضی آن شوید؛ اما باید بدانید مدل چه کاری انجام می‌دهد، چه محدودیت‌هایی دارد و چگونه باید آن را داخل یک نرم‌افزار واقعی کنترل کرد.

در این مقاله پنج مفهوم اصلی را یاد می‌گیریم:

1. Transformer
2. Prompting
3. Context Window
4. Hallucination
5. Tool Use

1. ابتدا LLM دقیقاً چیست؟

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

برای مثال اگر ورودی این باشد:

The capital of France is

مدل احتمال زیادی می‌دهد که توکن بعدی Paris باشد.

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

نکته بسیار مهم این است که LLM ذاتاً یک پایگاه داده حقیقت نیست. مدل معمولاً پاسخ را از یک جدول اطلاعاتی بازیابی نمی‌کند؛ بلکه ادامه‌ای محتمل برای ورودی تولید می‌کند. همین موضوع منشأ بسیاری از توانایی‌ها و در عین حال خطاهای LLM است.

2. Token چیست؟

LLM متن را مستقیماً به شکل کلمه نمی‌بیند. متن ابتدا به قطعات کوچکی به نام Token تبدیل می‌شود.

مثلاً عبارت:

Artificial Intelligence

ممکن است به چند Token تقسیم شود.

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

اهمیت Token در پروژه واقعی بسیار زیاد است، زیرا موارد زیر معمولاً براساس تعداد Token محاسبه می‌شوند:

• اندازه Context Window
• هزینه استفاده از API
• سرعت پاسخ
• حداکثر اندازه ورودی و خروجی

بنابراین وقتی می‌گوییم یک مدل Context Window برابر با مثلاً 128K Token دارد، منظور تعداد کاراکتر یا کلمه نیست؛ بلکه تعداد Tokenهایی است که مدل می‌تواند در یک درخواست در نظر بگیرد.

3. Transformer چیست؟

Transformer معماری اصلی اکثر LLMهای امروزی است.

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

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

Embedding

کامپیوتر نمی‌تواند مستقیماً معنی کلمات را پردازش کند. بنابراین هر Token به مجموعه‌ای از اعداد تبدیل می‌شود که به آن Embedding می‌گوییم.

می‌توان Embedding را تقریباً مختصات معنایی یک Token در یک فضای چندبعدی تصور کرد.

Self-Attention

مهم‌ترین ایده Transformer مفهوم Attention است.

فرض کنید جمله زیر را داریم:

Sara gave Mina the book because she needed it.

برای فهمیدن she، مدل باید بررسی کند که این کلمه بیشتر به Sara مربوط است یا Mina.

Attention به مدل اجازه می‌دهد هنگام پردازش هر Token، میزان اهمیت Tokenهای دیگر را محاسبه کند.

فرمول معروف Attention به صورت زیر است:

Attention(Q,K,V) = softmax(QKᵀ / √dₖ)V

لازم نیست برای استفاده از LLM این فرمول را حفظ کنید. چیزی که باید بدانید این است:

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

Query، Key و Value

در Attention هر Token به سه نمایش تبدیل می‌شود:

• Query یا Q
• Key یا K
• Value یا V

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

• Query می‌پرسد: دنبال چه اطلاعاتی هستم؟
• Key می‌گوید: چه اطلاعاتی دارم؟
• Value محتوایی است که در صورت مرتبط بودن منتقل می‌شود.

Multi-Head Attention

Transformer معمولاً فقط یک Attention ندارد.

چند Attention مختلف به صورت هم‌زمان اجرا می‌شوند که به آن Multi-Head Attention می‌گوییم.

هر Head ممکن است رابطه متفاوتی را یاد بگیرد؛ مثلاً:

• ارتباط دستوری
• ارتباط معنایی
• وابستگی بین ضمیر و اسم
• ارتباط قسمت‌های دور از یکدیگر

سپس نتایج این Headها با هم ترکیب می‌شوند.

Positional Information

اگر فقط Tokenها را داشته باشیم، ترتیب کلمات مشخص نیست.

جملات زیر Tokenهای مشابهی دارند اما معنی متفاوت است:

Dog bites man

Man bites dog

بنابراین Transformer باید اطلاعات مربوط به موقعیت Tokenها را نیز دریافت کند.

مدل‌های مختلف برای این موضوع از روش‌هایی مانند Positional Encoding یا Rotary Position Embedding استفاده می‌کنند.

Feed Forward Network

بعد از Attention، اطلاعات هر Token وارد یک شبکه عصبی کوچک‌تر به نام Feed Forward Network می‌شود.

به صورت بسیار ساده می‌توان Transformer را این‌طور تصور کرد:

Tokens → Embeddings → Attention → Feed Forward → چندین بار تکرار → Prediction

یک LLM بزرگ ممکن است ده‌ها یا حتی صدها لایه Transformer داشته باشد.

4. مدل چگونه متن تولید می‌کند؟

فرض کنیم Prompt زیر را ارسال کنیم:

Explain machine learning in simple words.

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

مثلاً:

• Machine: 30%
• It: 25%
• Learning: 10%
• Imagine: 8%

یکی از Tokenها انتخاب می‌شود. سپس همین فرآیند دوباره با Token جدید انجام می‌شود.

بنابراین تولید پاسخ در واقع به شکل زیر است:

Prompt → token → token → token → token ...

این فرآیند تا رسیدن به پایان پاسخ ادامه پیدا می‌کند.

5. Temperature چیست؟

Temperature روی میزان تصادفی بودن انتخاب Token تأثیر می‌گذارد.

Temperature پایین

پاسخ معمولاً قابل پیش‌بینی‌تر و پایدارتر است.

مناسب برای:

• استخراج اطلاعات
• تحلیل داده
• تولید JSON
• عملیات Agent

Temperature بالاتر

تنوع خروجی افزایش پیدا می‌کند.

مناسب برای:

• ایده‌پردازی
• تولید متن خلاقانه
• داستان‌نویسی

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

6. Prompting چیست؟

Prompt فقط یک سؤال نیست. Prompt در یک سیستم حرفه‌ای در واقع رابط بین نرم‌افزار شما و مدل است.

Prompt خوب باید مشخص کند:

• مدل چه نقشی دارد؟
• وظیفه چیست؟
• چه اطلاعاتی در اختیار دارد؟
• چه محدودیت‌هایی وجود دارد؟
• خروجی باید چه فرمتی داشته باشد؟

مثال ضعیف:

Analyze this customer.

مثال بهتر:

Analyze the customer information below. Identify the churn risk as low, medium or high. Explain the three most important reasons. Do not invent missing information.

Zero-shot Prompting

فقط وظیفه را توضیح می‌دهیم.

مثال:

Classify this message as complaint, question or purchase request.

Few-shot Prompting

چند نمونه نیز به مدل می‌دهیم.

مثلاً:

I want a refund → complaint

How much is the product? → question

I want to order 10 units → purchase_request

سپس پیام جدید را برای طبقه‌بندی ارسال می‌کنیم.

Few-shot برای وظایفی که فرمت یا تعریف خاصی دارند بسیار مفید است.

7. System Prompt و User Prompt

در APIهای LLM معمولاً پیام‌ها نقش دارند.

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

مثلاً:

You are a CRM assistant. Never create or modify customer data without explicit authorization.

User Prompt درخواست فعلی کاربر است.

مثلاً:

Change Acme's opportunity status to Won.

این جداسازی در سیستم‌های Agentic بسیار مهم است، زیرا قوانین اصلی سیستم نباید صرفاً داخل متن کاربر قرار داشته باشند.

8. Structured Output

در پروژه واقعی معمولاً نمی‌خواهیم مدل یک متن آزاد تولید کند.

برای مثال Backend ممکن است انتظار داشته باشد:

{
  "risk": "high",
  "confidence": 0.81,
  "reason": "Customer reported repeated service failures"
}

Structured Output باعث می‌شود خروجی LLM راحت‌تر توسط برنامه پردازش و اعتبارسنجی شود.

قانون مهم:

خروجی LLM را حتی اگر JSON است مستقیماً قابل اعتماد فرض نکنید. آن را Validate کنید.

9. Context Window چیست؟

Context Window مقدار اطلاعاتی است که مدل می‌تواند در یک درخواست ببیند.

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

• System Prompt
• سابقه Conversation
• درخواست جدید
• اسناد بازیابی‌شده
• نتایج Toolها
• نمونه‌ها
• پاسخ تولیدی

بنابراین Context Window را می‌توان تقریباً حافظه کاری فعلی مدل در نظر گرفت.

اما Context Window حافظه دائمی نیست.

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

مشکل Context بزرگ

این تصور اشتباه است که هرچه اطلاعات بیشتری به مدل بدهیم، نتیجه بهتر می‌شود.

Context بیش از حد می‌تواند باعث شود:

• اطلاعات مهم میان متن گم شود
• هزینه افزایش پیدا کند
• Latency بیشتر شود
• اطلاعات متناقض وارد مدل شود

اصل مهم:

به مدل اطلاعات کافی بدهید، نه تمام اطلاعات موجود را.

10. RAG چه ارتباطی با Context دارد؟

فرض کنید یک شرکت 100 هزار سند دارد.

نمی‌توان همه اسناد را داخل Prompt قرار داد.

در معماری Retrieval-Augmented Generation یا RAG ابتدا اسناد مرتبط با سؤال پیدا می‌شوند و فقط بخش‌های مرتبط وارد Context می‌شوند.

معماری ساده:

User Question → Search/Retrieval → Relevant Documents → LLM → Answer

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

11. Hallucination چیست؟

Hallucination زمانی اتفاق می‌افتد که مدل اطلاعاتی تولید کند که ظاهراً منطقی و مطمئن است اما واقعیت ندارد.

مثلاً ممکن است:

• مقاله‌ای را اختراع کند
• آمار غیرواقعی ارائه دهد
• نام API موجود را اشتباه بگوید
• ویژگی محصولی را بسازد
• اطلاعات مشتری را حدس بزند

چرا؟

چون هدف پایه LLM تولید ادامه محتمل متن است، نه تضمین حقیقت.

12. چگونه Hallucination را کاهش دهیم؟

هیچ روش واحدی Hallucination را کاملاً حذف نمی‌کند، اما می‌توان احتمال آن را بسیار کاهش داد.

1. Grounding

اطلاعات معتبر را در اختیار مدل قرار دهید.

2. RAG

اطلاعات مرتبط را از منبع واقعی بازیابی کنید.

3. Tool Use

برای اطلاعاتی مثل قیمت، موجودی، وضعیت سفارش یا اطلاعات مشتری از API واقعی استفاده کنید.

4. Prompt مناسب

مثلاً:

If the required information is not available, say that it is unknown. Do not guess.

5. Structured Output

مدل را مجبور کنید اطلاعات مورد نیاز را در قالب مشخص ارائه دهد.

6. Validation

Backend باید خروجی را بررسی کند.

7. Human Approval

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

13. Tool Use چیست؟

LLM به تنهایی معمولاً نمی‌تواند کار واقعی در دنیای بیرون انجام دهد.

برای مثال خودش نمی‌تواند:

• وضعیت سفارش را از Database بگیرد
• ایمیل ارسال کند
• مشتری ایجاد کند
• موجودی انبار را تغییر دهد
• پرداخت انجام دهد

برای این کار باید به Tool متصل شود.

Tool می‌تواند یک Function، API یا سرویس خارجی باشد.

مثلاً:

get_customer(customer_id)

create_lead(data)

send_email(to, subject, body)

get_order_status(order_id)

14. Function Calling چگونه کار می‌کند؟

فرض کنید کاربر می‌گوید:

وضعیت سفارش 5421 را بررسی کن.

مدل خودش وضعیت سفارش را نمی‌داند.

فرآیند صحیح این است:

1. کاربر درخواست می‌دهد.
2. LLM تشخیص می‌دهد که به Tool نیاز دارد.
3. مدل درخواست اجرای get_order_status(5421) را تولید می‌کند.
4. Backend پارامترها را Validate می‌کند.
5. Backend API واقعی را اجرا می‌کند.
6. نتیجه Tool به LLM داده می‌شود.
7. مدل نتیجه را به زبان طبیعی توضیح می‌دهد.

معماری:

User → LLM → Tool Request → Backend → API/Database → Tool Result → LLM → User

این همان نقطه‌ای است که یک Chatbot ساده می‌تواند به یک Agent تبدیل شود.

15. یک اشتباه خطرناک در Tool Use

هیچ‌گاه اجازه ندهید LLM مستقیماً و بدون کنترل عملیات حساس را اجرا کند.

مثلاً اگر مدل تولید کرد:

delete_customer(218)

Backend نباید صرفاً چون LLM آن را درخواست کرده عملیات را اجرا کند.

قبل از اجرای Tool باید موارد زیر بررسی شود:

• Authentication
• Authorization
• Schema Validation
• Business Rules
• Risk Level
• User Confirmation

اصل بسیار مهم:

LLM تصمیم پیشنهادی تولید می‌کند؛ Backend باید مرجع نهایی اجرای عملیات باشد.

16. مثال عملی: Agent داخل CRM

فرض کنید کاربر می‌گوید:

آخرین وضعیت مشتری Acme را بررسی کن و اگر Opportunity آماده بود آن را Won کن.

یک سیستم ضعیف ممکن است همه چیز را مستقیماً به LLM بسپارد.

اما معماری حرفه‌ای چنین است:

مرحله 1: Intent Detection

مدل تشخیص می‌دهد کاربر می‌خواهد:

• اطلاعات مشتری را بررسی کند
• احتمالاً Opportunity را تغییر دهد

مرحله 2: Retrieval

Tool زیر اجرا می‌شود:

get_account('Acme')

مرحله 3: Analysis

LLM اطلاعات واقعی CRM را تحلیل می‌کند.

مرحله 4: Decision

ممکن است Agent نتیجه بگیرد اطلاعات کافی وجود ندارد.

در این حالت باید سؤال بپرسد، نه اینکه حدس بزند.

مرحله 5: Action

اگر قرار باشد Opportunity تغییر کند، Tool مناسب درخواست می‌شود.

مرحله 6: Validation

Backend بررسی می‌کند کاربر مجوز تغییر Opportunity را دارد یا نه.

مرحله 7: Confirmation

برای عملیات حساس می‌توان از کاربر تأیید گرفت.

مرحله 8: Execution

سپس تغییر واقعی در CRM انجام می‌شود.

این معماری تفاوت بین یک Demo جذاب و یک سیستم قابل اعتماد Production است.

17. معماری پیشنهادی یک پروژه LLM

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

Frontend

↓

Backend / Agent Controller

↓

LLM

↓

Tool Router

↓

CRM / Database / Search / External APIs

Backend یا Agent Controller وظایفی مانند این‌ها را مدیریت می‌کند:

• Authentication
• Context construction
• Prompt management
• Tool permissions
• Validation
• Logging
• Retry
• Rate limiting
• Risk control

LLM نباید مسئول تمام این موارد باشد.

18. چه چیزی را داخل Prompt و چه چیزی را داخل Code قرار دهیم؟

قاعده کاربردی:

Prompt مناسب است برای:

• توضیح وظیفه
• سبک پاسخ
• سیاست‌های رفتاری
• نحوه تحلیل
• فرمت خروجی

Code مناسب است برای:

• Permission
• Authentication
• Validation
• محاسبات قطعی
• محدودیت مالی
• Business Rules حساس
• اجرای عملیات

اگر قانونی برای امنیت سیستم حیاتی است، فقط به Prompt اعتماد نکنید.

19. Debugging سیستم‌های LLM

وقتی سیستم LLM اشتباه می‌کند، فقط Prompt را تغییر ندهید.

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

1. Prompt اشتباه
2. Context نامناسب
3. Retrieval ضعیف
4. Tool description مبهم
5. Tool result اشتباه
6. Validation ناکافی
7. مدل نامناسب
8. Temperature نامناسب
9. اطلاعات متناقض

بنابراین Log کردن مراحل Agent اهمیت بسیار زیادی دارد.

در سیستم Production بهتر است بتوانید ببینید:

User Request → Retrieved Context → Model Decision → Tool Call → Tool Result → Final Response

20. چک‌لیست ساخت اولین پروژه LLM

قبل از انتشار پروژه بررسی کنید:

• آیا هدف LLM دقیقاً مشخص است؟
• آیا System Prompt واضح است؟
• آیا خروجی ساختاریافته است؟
• آیا Context فقط اطلاعات مرتبط دارد؟
• آیا اطلاعات واقعی از Tool یا RAG گرفته می‌شوند؟
• آیا احتمال Hallucination کنترل شده است؟
• آیا ورودی Toolها Validate می‌شود؟
• آیا Permission در Backend بررسی می‌شود؟
• آیا عملیات حساس Confirmation دارد؟
• آیا تمام Tool Callها Log می‌شوند؟
• آیا Error و Timeout مدیریت شده‌اند؟
• آیا خروجی مدل قبل از استفاده حساس Validate می‌شود؟

جمع‌بندی ذهنی

اگر بخواهیم تمام این مقاله را در چند خط خلاصه کنیم:

LLM یک موتور پیش‌بینی Token است.

Transformer ساختاری است که کمک می‌کند مدل روابط میان Tokenها را بفهمد.

Prompt مشخص می‌کند مدل چه کاری انجام دهد.

Context Window اطلاعاتی است که مدل در همان لحظه می‌تواند ببیند.

Hallucination یعنی مدل ممکن است پاسخ plausible ولی غلط تولید کند.

Tool Use به مدل اجازه می‌دهد به اطلاعات و عملیات واقعی نرم‌افزار متصل شود.

و مهم‌تر از همه:

یک LLM خوب به تنهایی یک سیستم هوشمند قابل اعتماد نمی‌سازد. سیستم قابل اعتماد از ترکیب LLM، Context صحیح، Toolهای کنترل‌شده، Validation، Permission و معماری نرم‌افزاری مناسب ساخته می‌شود.

اگر این مفاهیم را به‌خوبی درک کنید، پایه لازم برای ورود به مباحث بعدی مانند AI Agents، ReAct، Planning، Memory، Reflection، Agentic AI، RAG و Adaptive Autonomy را خواهید داشت.