Реалізація Prompt Engineering для AI-системи
Впровадили LLM у чат-бот підтримки — і отримали 40% галюцинацій? Знайома ситуація. Один із наших клієнтів, fintech-стартап, витратив місяць на розробку чат-бота для кредитних консультацій. Промпт писав стажер за годину — результат: 40% відповідей містили невірні дані про відсоткові ставки та терміни. Ми за два тижні спроектували багаторівневий промпт з анти-галюцинаційною інструкцією, верифікацією через chain-of-verification та few-shot прикладами. Галюцинації знизилися до 3%, точність підвищилася з 55% до 94%, а p95 latency зменшився у 2 рази. За 5 років роботи з AI-системами ми виробили підхід, який дає передбачуваний p95 latency і точність >95% на production-навантаженнях.
Prompt Engineering — дисципліна конструювання вхідних даних для LLM з метою отримання передбачуваних, якісних результатів. Включає структурування запитів, керування контекстом, вибір технік (CoT, Few-Shot, ReAct), налаштування параметрів та ітеративне калібрування.
Чому стандартні промпти не працюють у production?
Часта помилка — промпти, написані розробником за десять хвилин. Вони дають прийнятну відповідь на 2–3 ручних тестах, але провалюються на реальному навантаженні. Основні проблеми:
- Hallucination — модель домислює те, чого немає в контексті. Без анти-галюцинаційних інструкцій до 30% відповідей містять хибні факти.
- Контекстна чутливість — маленька зміна формулювання змінює відповідь повністю. Температура та top-p, не прив'язані до типу завдання, створюють невідтворюваність.
- Відсутність обробки помилок — при відсутності даних модель не каже «не знаю», а вигадує відповідь.
Ми прибираємо ці проблеми через структуровані шаблони, верифікацію та A/B тести.
Як знизити відсоток галюцинацій у LLM?
Ключовий прийом — chain-of-verification: модель спочатку генерує відповідь, потім перевіряє кожне твердження на відповідність контексту. Ми додаємо системний промпт, який забороняє домислювати і вводить поріг впевненості. Додатково використовуємо few-shot приклади з граничними кейсами. У production це дає зниження hallucination rate з 20% до 2–3%. Згідно з рекомендаціями OpenAI, структуровані промпти знижують кількість галюцинацій на 30–50%.
ANTI_HALLUCINATION_ADDENDUM = """ ВАЖЛИВО: Відповідай лише на основі наданого контексту. Якщо інформації немає в контексті — скажи: "У мене немає даних з цього питання." Не домислюй і не роби припущень. Якщо впевнен < 80% — вкажи ступінь невизначеності. """ async def answer_with_verification(question: str, context: str) -> dict: answer = query_llm( f"Контекст:\n{context}\n\nПитання: {question}", system=f"Ти — аналітик. {ANTI_HALLUCINATION_ADDENDUM}", ) verification = query_llm( f"Вихідна відповідь: {answer}\n\nПитання: Чи всі твердження у відповіді підтверджені контекстом? Дай відповідь JSON: {{\"verified\": bool, \"unsupported_claims\": [...]}}", temperature=0, ) return {"answer": answer, "verification": json.loads(verification)} Як ми проектуємо промислові промпти
Процес починається не з коду, а з аналізу очікувань: що повинен робити промпт, які граничні випадки, як вимірювати якість. Збираємо 100–200 репрезентативних запитів, розмічаємо ідеальну відповідь. Тільки потім пишемо перший baseline.
Рольова модель і контекст
Системний промпт будується за схемою: «Ти — [роль]. Завдання — [мета]. Контекст — [умови, дані]. Правила — [що можна, що не можна]. Формат виведення — [явний формат]». Для RAG додаємо вказівник на джерело. Приклад:
SYSTEM_PROMPT = """Ти — {role}. Завдання: {task_description} Правила: {rules} Формат відповіді: {output_format}""" A/B тестування і метрики
Кожен варіант промпту перевіряємо на eval-сеті за допомогою LLM-as-judge. Порівнюємо за точністю, повнотою, стилем. Приклад класу для тестів:
class PromptABTest: def __init__(self, variants: dict[str, str]): self.variants = variants self.results = {name: [] for name in variants} def run_test(self, test_inputs: list[str], judge_prompt: str) -> dict: for input_text in test_inputs: outputs = {} for name, prompt in self.variants.items(): output = query_llm(input_text, system=prompt) outputs[name] = output comparison = query_llm( f"""Порівняй дві відповіді на запит: "{input_text}" Варіант A: {outputs[list(outputs.keys())[0]]} Варіант B: {outputs[list(outputs.keys())[1]]} {judge_prompt} Поверни JSON: {{\"winner\": \"A\"|\"B\"|\"tie\", \"reason\": \"...\"}}""", temperature=0, ) result = json.loads(comparison) winner = result["winner"] if winner != "tie": winning_name = list(self.variants.keys())[0 if winner == "A" else 1] self.results[winning_name].append(1) return {name: sum(wins) / len(test_inputs) for name, wins in self.results.items()} Покрокова інструкція з калібрування промпту
- Визначте мету та метрики: точність, повнота, latency, hallucination rate.
- Зберіть eval-сет: 100–200 реальних запитів з еталонними відповідями.
- Створіть baseline: простий промпт з рольовою моделлю та базовими правилами.
- Ітеративно покращуйте: для кожної проблеми додавайте інструкції, few-shot приклади, перевірки.
- A/B тестування: порівняйте variant vs control на тіньовому трафіку, оберіть кращий.
Порівняння технік prompt engineering
| Техніка | Застосування | Ефект |
|---|---|---|
| Few-Shot | Додавання 3–5 прикладів у промпт | Покращення точності на 15–25% |
| Chain-of-Thought | Покрокове міркування | Підвищення якості складних завдань на 30% |
| Self-Consistency | Множинні генерації + голосування | Зниження variance, зростання надійності |
| Chain-of-Verification | Перевірка фактів після відповіді | Зниження hallucination rate у 5–10 разів |
Що входить у роботу
Після калібрування ви отримуєте:
- Шаблони промптів у форматі JSON/YAML з коментарями.
- Eval-сет із 200+ прикладів з еталонними відповідями.
- Звіт з метриками: точність, recall, hallucination rate, latency p99.
- A/B тестування на тіньовому трафіку (опціонально).
- Навчання команди: 2–4 години воркшопу з підтримки та доопрацювання промптів.
- Гарантію стабільності: якщо після впровадження якість падає, ми безкоштовно коригуємо промпт протягом місяця.
Порівняння підходів: One-shot vs Iterative
| Характеристика | One-shot (ручний) | Iterative (з eval) | З A/B тестуванням |
|---|---|---|---|
| Час до production | 1 день | 3–5 днів | 5–10 днів |
| Точність на тестовому сеті | 30–50% | 60–80% | 90–95% |
| Latency стабільність | Низька (p99 зростає) | Середня | Висока (p99 фікс) |
| Ризик галюцинацій | Високий (>15%) | Середній (5–10%) | Низький (<3%) |
Iterative підхід з метриками у 2–3 рази ефективніший за одноразове написання — це підтверджено на 50+ проектах.
Терміни та результати
- Базовий промпт для конкретного use case: 1–3 дні.
- A/B тестування з eval-сетом: 3–5 днів.
- Production-промпт з верифікацією та документацією: 7–10 робочих днів.
Вартість розраховується індивідуально — залежить від складності завдання та кількості промптів. Типовий проект коштує від $1500 до $4000. Економія на виправленні галюцинацій може сягати $10 000 на місяць. Оцінка займає 1 день: ви описуєте юзкейс, ми аналізуємо та пропонуємо план.
Хочете стабільну роботу LLM? Зв'яжіться з нами, щоб ми проаналізували ваш поточний промпт та запропонували покращення за 1 день. Замовте аудит промпту — отримайте детальний звіт з метриками та рекомендаціями. Отримайте консультацію щодо вашого промпту вже сьогодні.