Как меняется система, когда меняются условия
Адаптация редко означает переписать всё заново. Чаще достаточно пересобрать один слой — оценку качества, оркестрацию пайплайнов или способ инференса. Ниже — четыре среза, по которым видно, что именно сдвигается и что при этом остаётся неизменным.
Когда ответ должен приходить заметно быстрее, первым делом пересматривается баланс между дообучением и поиском с генерацией. Дообученная модель отвечает стабильнее по стилю, но её обновление — отдельная процедура. Контур поиска с генерацией обновляется легче, зато добавляет шаг поиска в цепочку. Решение принимается по частоте изменений в базе знаний и по допустимой задержке, а не по одному показателю качества.
Если в поток попадают сведения, которые нельзя отправлять во внешние сервисы, меняется не модель, а маршрут данных. Часть сценариев уходит на локальные модели, остальное проходит через маскирование и псевдонимизацию до отправки. Параллельно обновляется журналирование доступа — иначе невозможно доказать, что политика соблюдается, а не просто описана в регламенте.
Переезд на другие мощности или сокращение бюджета на вычисления затрагивает в первую очередь инференс. Здесь работают квантование, батчинг запросов и кэширование повторяющихся вызовов. Отдельно стоит пересмотреть очереди и поведение сервиса под нагрузкой: деградация должна быть предсказуемой, а не внезапным отказом в час пик.
Автоматические метрики редко совпадают с ощущением качества у пользователя. Если расхождение стало заметным, меняется сам контур оценки: быстрые проверки на регрессиях, офлайн-наборы с эталонными ответами и постоянный сбор сигналов от пользователей. Версию промпта фиксируют вместе с версией модели — иначе сравнение результатов теряет смысл.
