Интеграция ИИ
Когда добавлять 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 за границу безопасности. Не сделаю вид, что прототип выходных — интеграция. Если вам нужно именно это, есть более дешёвые вендоры.
Коротко
- Модель — для остаточной неоднозначности, не вместо продуктовой проработки.
- Границу данных и цену ошибки решите до вендора.
- Для фактов лучше схема плюс поиск, чем дообучение.
- Лучше процесс плюс один вызов модели, чем безграничный агент.
- Без оценок и запасного пути вы ничего не выпустили.