Як насправді працюють LLM
Не треба знати трансформер на рівні рівнянь. Треба знати достатньо, щоб ставити правильні запитання технічним командам — і не дозволяти їм відмахнутись від ризиків. Цей модуль дає вам робочу ментальну модель LLM, що достатня для CAIO-розмов з engineering, vendor evaluation та risk assessment.
Що ви опануєте
- Що означають token, context window, parameters
- Чому LLM "галюцинує" — і чому це не баг
- Різниця між fine-tuning, prompting, RAG
- Топ-провайдери foundation models + їхні різниці
Концепція 1: Tokens — фундамент усього
Token — фрагмент тексту, на якому працює LLM. Приблизно ¾ слова в англійській, інколи 2-3 токени на слово у морфологічно багатих мовах (українська, російська).
Все, що бачить модель — це послідовність токенів. Не слова, не речення, не "ідеї" — токени.
Що це означає практично:
- Pricing у токенах: $X / 1M input tokens, $Y / 1M output tokens. Bud price model.
- Limit context — фізична межа того, скільки модель може обробити одночасно.
- Tokenization різна для різних мов — українські тексти "коштують" більше токенів за англійські.
Українська мова має приблизно 1.5-2× більше токенів на слово за англійську. Це означає вищі costs для українських prompts та обмеженіший effective context window. Для критичних кейсів — врахуйте у budget calculations.
Концепція 2: Context Window — обсяг "пам'яті"
Context window — скільки токенів модель тримає одночасно. Це найважливіший практичний параметр.
| Модель | Context window | Що поміщається |
|---|---|---|
| GPT-3.5 (старий) | 4K | ~3000 слів |
| GPT-4 | 32K | ~24,000 слів |
| GPT-4o | 128K | ~96,000 слів = середня книга |
| Claude 3.5 Sonnet | 200K | ~150,000 слів |
| Gemini 2.0 | 1M+ | Багатотомна документація одночасно |
Чому це матиме значення для CAIO:
- RAG-додаток з малим context — режиме перерізає документи дрібно, втрачає контекст.
- Великий context не безкоштовний — більше токенів = вища ціна + повільніша відповідь.
- Прискіпливе питання до vendor: "які моделі ви pop-up'ите за default? З яким context?"
Концепція 3: Temperature — контроль креативності
Temperature контролює, наскільки модель випадкова у відповідях:
| Temperature | Поведінка | Use case |
|---|---|---|
| 0.0 | Детерміновано, завжди той самий output | Юридичні документи, code generation, medical |
| 0.2 | Майже детерміновано з малим variation | Analytics, structured tasks |
| 0.7 | Збалансовано | General productivity, summarization |
| 1.0 | Дуже креативно | Creative writing, brainstorming |
| >1.0 | Хаотично | Майже завжди погано |
Для production AI-додатків — використовуйте 0.0–0.2. Це робить behavior відтворюваним, що critically для testing та debugging.
Концепція 4: System Prompt — головний governance-важіль
System prompt — інструкції, що задає розробник (не користувач). Це основа поведінки моделі для всіх запитів.
Приклад system prompt для HR-помічника:
You are an HR-помічник для ДП НАІС.
- Відповідайте тільки на питання про HR-процеси.
- Якщо питання — про юридичні консультації, рекомендуйте звернутись до Legal.
- Не давайте порад про конкретні salaries чи promotions.
- Завжди українською мовою.
Чому це найбільший governance-важіль:
- Все, що там написано, моделює поведінку моделі для всіх користувачів.
- Зміна system prompt миттєво змінює behavior без re-training.
- Уразлива до prompt injection — якщо attacker може його extract'ити, він знає як обходити.
Концепція 5: Fine-tuning vs Prompting vs RAG
Три способи "налаштувати" модель під ваш use case:
| Метод | Що робить | Вартість | Коли використовувати |
|---|---|---|---|
| Prompting | Examples в context | Безкоштовно | Прості задачі, маленькі datasets |
| RAG | Retrieve docs під час query | Помірно | Domain knowledge, що змінюється |
| Fine-tuning | Тренувати модель на нових даних | Дорого | Style/format, що важко описати prompt'ом |
Правило для CAIO:
- Спробуйте prompting спершу. 70% задач вирішується.
- RAG для domain-specific знань. 25% задач.
- Fine-tuning — останній резерв. 5% задач, з ML-командою.
Дані змінюються постійно. RAG оновлюється коли ви оновлюєте документи. Fine-tuning стає застарілим за тижні і потребує re-training за тижні + $$$.
Концепція 6: Топ-провайдери foundation models
Топ-5 foundation model-провайдерів (станом на 2026):
| Провайдер | Топ-модель | Спеціалізація |
|---|---|---|
| OpenAI | GPT-4o, GPT-5 (anticipated) | Найкраще general purpose, найбільший ecosystem |
| Anthropic | Claude 3.5/4 Sonnet | Reasoning, coding, safety-focused |
| Gemini 2.0 | Multimodal, найбільший context window | |
| Meta | Llama 3.3 | Best open-weight, можна self-host |
| xAI | Grok | Twitter-context, real-time data |
Усі різні за:
- Безпекою (Anthropic — лідер у safety research).
- Цінами (Llama безкоштовний для self-host, OpenAI найдорожчий за tokens).
- Обмеженнями (Gemini має найбільший context, Claude — найкращий reasoning).
Не локайтесь на одного. Multi-vendor стратегія = більший leverage у переговорах + resilience при vendor failures.
Концепція 7: Чому LLM "галюцинує"
Це не баг — це архітектурна особливість. LLMs прогнозують next token на основі patterns у тренувальних даних. Вони не "знають" факти — вони pattern-match.
Без зовнішнього "якоря" (RAG, structured outputs, citation engines) модель компенсує невпевненість впевненими вигадками.
Що це означає для CAIO:
- AI-додатки для high-stakes рішень обов'язково потребують fact-checking layer.
- "AI hallucinated" — це системний дизайн ваш, не "наша помилка".
- Citations + confidence scores + human-in-the-loop — це обов'язкові для regulated use cases.
Глибше у джерелах
Підсумок
Технічна грамотність CAIO — не про код, а про правильні запитання. "Скільки токенів обробить ваш RAG?" — це питання CAIO, не CTO. "Який system prompt і чи захищений він від injection?" — теж CAIO. 7 концепцій вище — це 80% розмов з vendors та engineering за наступний рік.
Наступний модуль: RAG Architecture для enterprise — найпоширеніший pattern у enterprise AI.