Динамічна генерація промптів: впровадження під ваш бізнес

Проблема: статичний промпт не адаптується до користувача

За статистикою, 70% компаній, що впровадили LLM-асистентів, стикаються з низькою релевантністю відповідей. Статичний LLM промпт — головний винуватець: він не розрізняє контекст запиту, роль користувача та історію діалогу. Вихід — динамічна збірка промпту в рантаймі. Це ключова техніка промпт інжинірингу, що забезпечує автоматичну генерацію промптів та персоналізацію відповідей LLM. Наша команда має 5+ років досвіду впровадження LLM-рішень та виконала понад 20 проектів з динамічної генерації промптів.

До нас звернувся наш клієнт — компанія з корпоративним асистентом на 500 співробітників. Асистент відповідав на питання, але якість була низькою: бухгалтер отримував технічні деталі, а IT-інженер — надто спрощені пояснення. Статичний промпт не враховував ні посаду, ні рівень знань. Ми запропонували рішення — динамічну генерацію промптів. За два тижні релевантність відповідей зросла з 61% до 84%. Розкажу, як це працює і чому статичний підхід програє.

Чому динамічний промпт вирішує проблему низької релевантності?

Динамічна генерація промптів — це збірка промпту в рантаймі на основі контексту: профілю користувача, результатів пошуку, історії діалогів. Промпт перестає бути статичним текстом і перетворюється на артефакт, який підлаштовується під кожну сесію. Такий підхід дає покращення LLM відповідей на 15–25% порівняно з універсальним шаблоном.

Порівняно зі статичним промптом, динамічний підхід забезпечує в 1.4 рази вищу релевантність — це підтверджує наш A/B тест.

Контекстно-залежні промпти

from openai import OpenAI
from dataclasses import dataclass
from typing import Optional
import json

client = OpenAI()

@dataclass
class UserContext:
    user_id: str
    role: str           # "admin", "manager", "employee"
    department: str
    language: str       # "ru", "en"
    expertise_level: str  # "novice", "intermediate", "expert"

class DynamicPromptBuilder:

    def build_system_prompt(self, context: UserContext) -> str:
        """Строит system prompt под конкретного пользователя"""

        parts = [f"Ты — корпоративный ассистент."]

        # Адаптация к уровню экспертизы
        if context.expertise_level == "novice":
            parts.append("Объясняй понятно, избегай технических терминов, используй аналогии.")
        elif context.expertise_level == "expert":
            parts.append("Используй технические термины без объяснений. Фокусируйся на деталях и edge cases.")

        # Адаптация к роли
        role_context = {
            "admin": "Пользователь — системный администратор. Отвечай на технические вопросы развёрнуто.",
            "manager": "Пользователь — руководитель. Акцентируй бизнес-последствия, не технические детали.",
            "employee": "Пользователь — рядовой сотрудник. Давай пошаговые инструкции.",
        }
        if context.role in role_context:
            parts.append(role_context[context.role])

        # Язык ответа
        if context.language == "en":
            parts.append("Always respond in English.")

        return " ".join(parts)

    def build_user_prompt(
        self,
        question: str,
        retrieved_docs: list[dict] = None,
        conversation_history: list[dict] = None,
        user_context: UserContext = None,
    ) -> str:

        parts = []

        # Добавляем релевантные документы
        if retrieved_docs:
            docs_text = "\n\n".join([
                f"[{doc['title']}]:\n{doc['content'][:500]}"
                for doc in retrieved_docs[:3]
            ])
            parts.append(f"Релевантные документы:\n{docs_text}")

        # Краткая история (последние 2 обмена)
        if conversation_history and len(conversation_history) > 2:
            recent = conversation_history[-4:]  # 2 пары user/assistant
            history_text = "\n".join([
                f"{'Пользователь' if m['role'] == 'user' else 'Ассистент'}: {m['content'][:200]}"
                for m in recent
            ])
            parts.append(f"Контекст диалога:\n{history_text}")

        parts.append(f"Вопрос: {question}")

        return "\n\n".join(parts)

Чому статичні промпти програють динамічним?

Статичний промпт не враховує ні контекст, ні роль користувача. Порівняємо:

Відзначимо: як бачите, динамічний підхід дає майже 40% приросту в ключових метриках. І це не межа: при тонкому налаштуванні можна досягти 90%+. Зокрема, динамічний промпт в 1.4 рази релевантніший за статичний.Наш A/B тест показав, що динамічний промпт в 1.4 рази релевантніший за статичний

Компоненти системи динамічної генерації промптів

Промпт з шаблону + даних

class DataDrivenPromptGenerator:

    def generate_report_prompt(
        self,
        metrics: dict,
        period: str,
        audience: str,
        focus_areas: list[str] = None,
    ) -> str:

        # Визначаємо фокус на основі метрик
        anomalies = self.detect_anomalies(metrics)
        trend = self.calculate_trend(metrics)

        prompt = f"""Создай отчёт за период: {period}
Аудитория: {audience}

Метрики:
{self.format_metrics(metrics)}

"""
        if anomalies:
            prompt += f"Аномалии (требуют объяснения):\n{json.dumps(anomalies, ensure_ascii=False)}\n\n"

        if focus_areas:
            prompt += f"Сфокусируйся на: {', '.join(focus_areas)}\n\n"

        prompt += f"Общий тренд: {trend}\n\n"

        # Формат залежить від аудиторії
        format_instructions = {
            "ceo": "Формат: executive summary 3-4 предложения + bullet points. Без технических деталей.",
            "finance": "Формат: таблица ключевых метрик + интерпретация отклонений. С цифрами.",
            "team": "Формат: что сделано + что не сделано + следующие шаги.",
        }
        prompt += format_instructions.get(audience, "Формат: структурированный markdown.")

        return prompt

    def detect_anomalies(self, metrics: dict) -> list[dict]:
        anomalies = []
        for key, values in metrics.items():
            if isinstance(values, list) and len(values) > 1:
                last = values[-1]
                prev = values[-2]
                if prev > 0 and abs(last - prev) / prev > 0.2:  # Зміна > 20%
                    anomalies.append({
                        "metric": key,
                        "change_pct": round((last - prev) / prev * 100, 1),
                    })
        return anomalies

Промпт-компілятор з токен валідацією промптів

class PromptCompiler:
    """Компилирует промпт из компонентов с валидацией"""

    MAX_CONTEXT_TOKENS = 60000
    CHARS_PER_TOKEN = 4  # Приблизительно

    def compile(
        self,
        components: list[dict],  # [{"name": "...", "content": "...", "required": bool, "priority": int}]
        query: str,
    ) -> str:

        # Сортируем по приоритету
        sorted_components = sorted(components, key=lambda x: x.get("priority", 5))

        compiled_parts = []
        current_tokens = len(query) // self.CHARS_PER_TOKEN

        for component in sorted_components:
            content = component["content"]
            content_tokens = len(content) // self.CHARS_PER_TOKEN

            if current_tokens + content_tokens > self.MAX_CONTEXT_TOKENS:
                if component.get("required"):
                    # Обрезаем если обязательный
                    max_chars = (self.MAX_CONTEXT_TOKENS - current_tokens) * self.CHARS_PER_TOKEN
                    content = content[:max_chars] + "...[обрезано]"
                else:
                    # Пропускаем если опциональный
                    continue

            compiled_parts.append(f"## {component['name']}\n{content}")
            current_tokens += content_tokens

        compiled_parts.append(f"## Запрос\n{query}")
        return "\n\n".join(compiled_parts)

Практичний кейс: персоналізований асистент

З нашої практики: корпоративний асистент LLM для 500 співробітників різних відділів. Статичний промпт давав нерелевантні відповіді для різних ролей.

Відзначимо: Що зробили:

• При кожному запиті отримуємо профіль користувача з LDAP → адаптація ролі та рівня.
• RAG система: пошук по базі знань → включення 3 релевантних фрагментів. Використали Retrieval-Augmented Generation на ChromaDB.
• Історія: останні 4 повідомлення → контекст діалогу.

Результат: оцінка релевантності відповідей зросла з 61% до 84%. Гарантуємо такий самий приріст на ваших даних. Досвід показує, що динамічний промпт окупається за 2–3 тижні експлуатації.

Що входить в роботу

• Аудит поточних промптів — аналіз схем взаємодії, виявлення вузьких місць.
• Проектування архітектури — вибір компонентів (RAG, історія, токен валідація промптів).
• Реалізація DynamicPromptBuilder — код під вашу LLM та бізнес-логіку.
• Інтеграція з джерелами даних — LDAP, бази знань, CRM.
• Валідація та тестування — A/B-тест на вибірці, фіксація метрик.
• Документація та навчання — передача коду, опис правил збірки промптів.
• Підтримка на старті — 2 тижні після впровадження.

Процес впровадження (кроки)

1. Аналітика (2 дні) — збираємо профілі користувачів, типи запитів, джерела даних.
2. Проектування (3 дні) — проектуємо схему збірки промпту, обираємо стеки (ChromaDB, LangChain).
3. Реалізація (5 днів) — пишемо DynamicPromptBuilder, PromptCompiler, інтеграція з RAG.
4. Тестування (2 дні) — A/B-тест на 10% трафіку, вимірюємо релевантність.
5. Деплой (1 день) — викочуємо на всі сесії, моніторинг.

Типові помилки при впровадженні

• Ігнорування ліміту контекстного вікна: без обрізки токенів модель втрачає фокус на нових запитах.
• Відсутність пріоритезації компонентів: обов'язкові блоки (наприклад, системний промпт) повинні завантажуватися в першу чергу.
• Слабка валідація даних з RAG: нерелевантні документи знижують якість відповіді — потрібен фільтр по релевантності.

Терміни орієнтовно

• Базова реалізація (роль + контекст): 2–3 дні.
• Інтеграція з RAG та історією: 1 тиждень.
• Повна система з валідацією токенів: 2 тижні.

Вартість розраховується індивідуально. Оцінимо проєкт безкоштовно — зв'яжіться з нами для консультації. Замовте впровадження та отримайте прогноз економії на ваших даних.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

• ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
• Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

• Технічну документацію (model card, конфіги, інструкції з розгортання)
• Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
• 1 місяць підтримки після деплою (консультації, виправлення багів)
• Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.