# Когда добавлять LLM в существующий продукт — и когда не стоит

Большинство программ с LLM ломаются по скучной причине: задача никогда не была достаточно неоднозначной, чтобы оправдать вероятностный компонент. Модель просят делать то, что уже делают форма, запрос или очередь — только медленнее, дороже и с новым классом ошибок. Это фильтр, который я ставлю до выбора вендора.

## Единственная хорошая причина добавить модель

Языковая модель полезна, когда вход грязный, а нужный выход — структурированный артефакт, который может съесть нижестоящая система: классификация, извлечение, черновик, ответ с опорой на поиск, вызов инструмента. Она не полезна, когда вход уже схема. «Сожми этот PDF» может быть задачей модели. «Пометь счёт оплаченным, когда Stripe так сказал» — нет.
Если задачу нельзя описать без слов «умный» или «магия», задачи ещё нет. Есть желание.

## Семь вопросов, которые убивают большинство предложений

1. Задача неоднозначна — или просто не автоматизирована? Если младший сотрудник по чек-листу будет прав в 99% случаев, пишите ПО. Не арендуйте модель изображать чек-лист.
2. Сколько стоит неверный ответ? Неверный тон в черновике дешёвый. Неверный возврат, неверное право или медицински смежная подсказка — нет. Дорогие ошибки требуют валидаторов и человеческих ворот. Промпт «будь осторожен» — не контроль.
3. Могут ли данные покинуть контур? Если нет, hosted API не стартуют, пока нет VPC или on-prem. Качество модели здесь вторично.
4. Где живут факты? Если в документах и тикетах — нужны поиск и цитаты. Дообучение не угонится за политикой прошлого вторника. Если факты в базе — запросите базу.
5. Каков контракт выхода? Продакшен не парсит «ощущение». JSON-схема, аргументы инструмента или закрытое перечисление. Спроектируйте путь отказа и починки.
6. Каковы задержка и стоимость? Фоновые задачи терпят секунды и центы. Загрузка страницы — нет. Frontier-модель на горячем пути — как инференс становится самой большой строкой счёта.
7. Кто владеет оценками после запуска? Если ответ «стажёр, который написал промпт», вы не выпускаете компоненту продукта. Вы выпускаете демо, которое сгниёт.

## RAG, дообучение и ни то ни другое

Поиск с генерацией — для фактов, которые должны быть актуальными и атрибутируемыми. У него свои отказы: плохая нарезка, найденный, но проигнорированный контекст, цитаты, которые выглядят как доказательства. Нужен набор оценок качества поиска, не только финальной прозы.
Дообучение — для формата, тона и следования задаче на меньшей модели. Это плохая база знаний. Если команда дообучает, чтобы модель «знала наш продукт», остановитесь и положите продукт в поиск или в приложение.
Удивительно много полезных интеграций не нужно ни то ни другое: ограниченная схема, несколько примеров и валидатор. Начните отсюда. Ошибаться дешевле.

## Агенты — последняя архитектура, не первая

Агент — это цикл с инструментами. У циклов есть стоимость, задержка и способность сделать не то дважды. Если можете нарисовать блок-схему — реализуйте её и поставьте модель на один грязный шаг. Если не можете, возможно, задача агентная — с потолками, правами в слое инструментов и человеческим коммитом необратимых действий.

## Чем я не помогу

Не поставлю неограниченный chat completion на путь записи в продакшен-системы. Не приму chain-of-thought за границу безопасности. Не сделаю вид, что прототип выходных — интеграция. Если вам нужно именно это, есть более дешёвые вендоры.

## Коротко
- Модель — для остаточной неоднозначности, не вместо продуктовой проработки.
- Границу данных и цену ошибки решите до вендора.
- Для фактов лучше схема плюс поиск, чем дообучение.
- Лучше процесс плюс один вызов модели, чем безграничный агент.
- Без оценок и запасного пути вы ничего не выпустили.

Canonical: https://ihar-ivaniuk.com/ru/insights/when-to-add-an-llm
Author: Игорь Иванюк