Автоматические метрики редко совпадают с тем, как качество ощущает пользователь. Рабочая схема строится на трёх уровнях: быстрые проверки на регрессиях, офлайн-наборы с эталонными ответами и постоянный сбор сигналов из продукта. Без этого спор о качестве превращается в спор о вкусах.

Это не конкурирующие опции, а инструменты под разные условия. Дообучение требует размеченных данных и переобучения при каждом обновлении знаний. Поиск с генерацией быстрее запускается и легче обновляется, но качество ответа сильно зависит от поиска и нарезки документов. Выбор диктуют частота изменений и требования к стилю ответа.

Задержка, стоимость вычислений и надёжность тянут в разные стороны. Квантование и дистилляция снижают стоимость, но могут ухудшить ответы. Батчинг и кэш помогают под нагрузкой, но усложняют логику. Решение принимается под конкретный сценарий, а не «вообще».

Что можно отправлять во внешнюю модель, что нельзя и как это контролировать технически — вопросы, на которые нужен ответ до первой интеграции. Маскирование, псевдонимизация, локальные модели для чувствительных сценариев и журналирование доступа — это инженерные меры, а не пункты в регламенте.

Устойчивая команда ИИ-продукта включает исследователя или ML-инженера, инженера данных, платформенного специалиста и продакт-менеджера. Когда зоны ответственности размыты, качество модели, инфраструктура и метрики продукта начинают спорить друг с другом вместо того, чтобы складываться.

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