Перевод с разбором · для Вани

Чтобы модель не выдумывала (галлюцинации)

Зачем тебе это нужно

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

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

Базовые стратегии

1. Явно разреши сказать «не знаю»

Если данных для поля нет — ставь null. Не пытайся угадать.
Если заявка бессмысленна — верни {"parse_error": "причина"}.

Что здесь происходит: одна строчка снимает с модели внутреннее давление «я должна что-то ответить». В парсере заявок это убирает 80% выдуманных длин и материалов.

2. Заземляй на данных из БД

Никогда не давай модели считать цены или нормы «из головы». Передавай прайс и правила явно внутрь промпта:

<prices>
  oak_board_40mm: 3500 руб/м²
  pine_board_40mm: 1200 руб/м²
  stainless_screw_6x80: 15 руб/шт
  lacquer_matte_10l: 4200 руб/шт
</prices>

Считай смету только по этим ценам. Если нужной позиции нет в прайсе —
поставь unit_cost_rub: null.

Что здесь происходит: модель теперь «видит» реальный прайс и знает, что всё остальное — запретная зона. Прайс в твоей системе лежит в Postgres — достал SELECT-ом, подставил в промпт.

3. Не доверяй LLM арифметику

Современные модели умеют считать, но иногда ошибаются на умножениях, округлениях, процентах. Для смет это неприемлемо. Правильный подход: LLM возвращает список позиций с количествами, арифметику делает Kotlin-код:

val lineItems = parseModelOutput(response)  // массив {material, qty, unit}
val total = lineItems.sumOf { item ->
    val price = priceRepo.getUnitPrice(item.material)
        ?: return@sumOf BigDecimal.ZERO
    price * item.qty.toBigDecimal()
}

Что здесь происходит: модель указывает «нужно 12 м² дуба», твой код умножает на цену из БД. Никакой BigDecimal не выходит из Kotlin — LLM его даже не видит.

Продвинутые приёмы

• Chain-of-thought с верификацией. Попроси модель расписать рассуждение в <thinking> перед ответом. Увидишь в логах, где она «перешла к выдумкам».
• Two-stage verification. Второй промпт (с другой моделью) ревьюит результат первой: «найди непоследовательности». Годится для критичных документов (сметы, финальные спецификации).
• Ограничь «внешние знания». В system prompt прямо: «опирайся только на данные из тега <order> и <prices>».

Что это значит для твоей системы

• В каждый LLM-вызов подкладывай только тот минимум данных, который нужен для задачи (прайс, нормы, заказ). Всё остальное — не включай.
• Любая арифметика — в Kotlin, не в промпте. LLM возвращает «сколько и чего», код считает «по какой цене».
• Параметры, которые нельзя выдумывать (тип дерева, цены, артикулы), держи в enum-ах. В промпте перечисляй допустимые значения. В Kotlin валидируй перед записью в БД.
• Всегда проверяй выход на «разумность»: если сумма сметы больше чем стоимость дома — что-то сломалось. Заложи санити-чеки в код, не только в промпт.

Полная версия — в docs/reduce-hallucinations.html.