Управление галлюцинациями и параметрами

Галлюцинация — это не баг, а фича. LLM — это машина для автодополнения, которая всегда стремится продолжить текст, даже если фактов не хватает. Инженеру нужно уметь «закручивать гайки» этой вероятности.

1. Математика хаоса: Temperature и Top-P

Эти параметры управляют тем, как модель выбирает следующий токен из распределения вероятностей.

Temperature (0.0 — 2.0)

Влияет на «сглаживание» вероятностей.

• Temp = 0: Модель всегда выбирает токен с максимальной вероятностью (ArgMax). Ответ детерминирован.

  • Применять для: Извлечения данных, SQL-генерации, классификации.

• Temp > 1: Модель начинает выбирать менее вероятные токены.

  • Применять для: Брейншторма, написания фикшна.

Top-P (Nucleus Sampling)

Отсекает «хвост» низковероятных токенов.

• Top-P = 0.1: Рассматриваем только топ-10% самых вероятных вариантов.

• Правило: Не меняйте Temp и Top-P одновременно. Это вносит непредсказуемость. Для инженерных задач обычно ставят Temp = 0.1 или 0.

2. Паттерн Self-Consistency (Самосогласованность)

Если вы зададите модели сложную логическую задачу один раз, она может ошибиться. Если зададите 5 раз — большинство ответов будут верными (при Temp > 0.5).

Алгоритм:

1. Отправляем один и тот же промпт 3–5 раз (параллельно).

2. Собираем ответы.

3. Выбираем самый частый ответ (Majority Vote).

Это дорого по токенам, но критически важно для задач, где ошибка недопустима (например, генерация конфигов инфраструктуры).

3. Паттерн «Критик» (Actor-Critic)

Одиночная модель плохо ищет свои ошибки. Но она отлично ищет чужие.

Архитектура:

1. Actor (Agent A): Генерирует код/ответ.

2. Critic (Agent B): Получает на вход задачу + ответ Агента А.

   • Промпт Критика: «Ты — Senior QA. Найди уязвимости и логические ошибки в этом коде. Если ошибок нет, верни "OK". Если есть — опиши их».

3. Если Критик нашел ошибки -> возвращаем их Агенту А на исправление (Loop).

# Псевдокод архитектуры Критика
code = model.generate(task="Напиши функцию подключения к БД", temp=0.2)
review = model.generate(
    system="Ты строгий код-ревьюер.", 
    user=f"Проверь этот код на утечки памяти: {code}"
)

if "OK" not in review:
    final_code = model.generate(
        user=f"Исправь код согласно замечаниям: {review}. Исходный код: {code}"
    )

Задание

Проведите лабораторную работу с любой доступной LLM.

1. Возьмите задачу, требующую точного ответа (например, "Реши квадратное уравнение x^2 - 5x + 6 = 0").

2. Сделайте 5 запросов с Temperature = 1.5. Запишите, сколько раз модель выдала бред.

3. Сделайте 5 запросов с Temperature = 0. Сравните стабильность.

4. (Для продвинутых) Реализуйте простой скрипт на Python, который генерирует SQL-запрос, а вторым вызовом просит модель объяснить этот запрос (проверка на галлюцинации: если объяснение не совпадает с логикой кода — это алерт).

Краткие итоги

1. Temperature = 0 для всего, что связано с кодом и фактами. Оставьте креативность маркетологам.

2. Одна голова хорошо, а две — валидация. Используйте паттерн «Критик», чтобы модель сама вычищала свои баги перед тем, как отдать результат вам.

3. Self-Consistency спасает в сложной логике. Лучше потратить в 3 раза больше токенов, чем уронить прод из-за глупой ошибки в сгенерированном конфиге.