Проблема: модель посчитала, а бизнес всё ещё ждёт ответа
Числовой прогноз редко приходит один. Вместе с ним аналитик получает десятки признаков, веса факторов, интервалы, сравнение со средним и несколько графиков. Для специалиста это рабочий материал. Для клиента, руководителя или контролёра — коробка с деталями, к которой забыли приложить понятную инструкцию.
Итальянская финтех-компания Axyon AI столкнулась именно с таким узким местом. Её модели уже формировали прогнозы и интерпретируемые признаки для инвестиционной аналитики, но подготовка ясных и единообразных пояснений оставалась ручной работой. Аналитики тратили время на комментарии и обоснования, а комплаенсу требовался текст, который можно проверить и сохранить.
Задачу легко сформулировать как «пусть LLM красиво перескажет цифры». Это тот редкий момент, когда слово «красиво» лучше сразу убрать из технического задания. Нужен не литературный кружок при модели, а проверяемый перевод из структурированных данных в деловой текст.
Что сделал проект Axyon AI
По данным опубликованного FFplus кейса, Axyon AI и лаборатория UNIMORE–AImageLab построили специализированный финансовый языковой модуль. На вход ему передавались:
- прогнозные сигналы;
- значения SHAP и другие атрибуции факторов;
- метаданные актива;
- рыночный контекст;
- структурированные результаты количественной модели.
Команда сравнила 15 открытых и коммерческих моделей через единый контур оценки. Затем выбранные открытые модели среднего размера дообучили параметрически эффективными методами, включая LoRA, смешанную точность и оптимизацию памяти. Для экспериментов использовали 48 000 GPU-часов EuroHPC; прототип встроили в продукт Axyon IRIS.
FFplus сообщает об улучшении качества объяснений до 55% относительно базовых моделей и оценивает экономию примерно в один человеко-месяц на клиента в год. Это результаты, заявленные участниками кейса, а не универсальная гарантия для любого процесса. Метод измерения и состав тестовой выборки на публичной странице раскрыты не полностью, поэтому переносить проценты в собственный бизнес-план без пилота нельзя.
Почему одного SHAP недостаточно
SHAP объясняет вклад признаков в конкретный результат относительно базового значения. Это полезный технический сигнал, но он не является готовым управленческим объяснением и тем более не доказывает причинность.
Например, система может показать, что рост одного показателя поднял прогноз, а другой фактор его снизил. Пользователю всё равно нужно понять:
- какой период и объект анализировались;
- насколько свежи исходные данные;
- велик ли эффект относительно обычного разброса;
- есть ли конфликтующие сигналы;
- какие ограничения есть у модели;
- кто и когда подтвердил итоговый текст.
Если просто выгрузить таблицу атрибуций в LLM, она охотно добавит связный сюжет. Иногда слишком связный: три числа уже познакомились, поженились и объяснили квартальную выручку. Поэтому языковая модель должна оформлять доказательства, а не изобретать связь между ними.
Практическая архитектура: рассказчик, а не второй прогнозист
Для малого и среднего бизнеса полезно разделить систему на пять слоёв.
1. Числовой источник истины
Прогноз, скоринг или классификация остаются в исходной модели или аналитическом сервисе. Там же рассчитываются факторы, доверительные интервалы и технические метрики. LLM не должна пересчитывать результат «на глаз» и менять знак влияния ради гладкой фразы.
2. Контракт объяснения
Между аналитикой и LLM нужен машинно-проверяемый объект, например JSON со строгой схемой:
- идентификатор модели и версии;
- момент расчёта;
- итоговый прогноз и единицы измерения;
- базовое значение;
- ведущие положительные и отрицательные факторы;
- величина вклада каждого фактора;
- интервал неопределённости;
- предупреждения о качестве данных;
- разрешённые формулировки и обязательные оговорки.
Такой контракт делает вход воспроизводимым. Если цифры изменились, можно понять, что изменилось в источнике, а что — только в формулировке.
3. Локальный языковой рассказчик
Для регулярных коротких пояснений часто достаточно модели среднего размера, работающей в защищённом контуре. Ей не нужен доступ ко всей корпоративной базе. Нужны только разрешённый структурированный пакет, шаблоны и словарь терминов.
Локальный запуск особенно уместен, если в объяснении встречаются клиентские позиции, персональные данные, коммерческие показатели или внутренние риск-оценки. При этом «локально» не означает «без контроля»: сервису нужны журнал запросов, версионирование модели, ограничение доступа и отдельный контур тестов.
4. Детерминированный валидатор
После генерации программа должна извлечь из текста все числа и фактические утверждения и сверить их с контрактом. Минимальные проверки:
- в тексте нет числа, которого не было во входе;
- знак и порядок факторов не изменены;
- проценты и единицы измерения совпадают;
- обязательная оговорка присутствует;
- запрещённые причинные формулировки не появились;
- ссылка на версию расчёта сохранена в журнале.
Если проверка не пройдена, текст не чинит сам себя бесконечным диалогом. Он возвращается на повторную генерацию с причиной либо уходит человеку.
5. Человеческое утверждение
В финансовых, кадровых, кредитных и иных чувствительных процессах финальный текст должен оставаться проектом до подтверждения уполномоченным сотрудником. Интерфейс лучше строить не как чат, а как карточку: исходный результат, факторы, версия данных, черновик, замечания и кнопка утверждения.
Как измерять качество без конкурса красноречия
Оценка «звучит убедительно» опасна: наиболее гладкий текст может точнее всех маскировать ошибку. Тестовый набор должен проверять несколько независимых свойств.
- **Верность числам:** все значения и знаки совпадают с источником.
- **Полнота:** упомянуты обязательные факторы и ограничения.
- **Отсутствие лишних выводов:** нет причинности, советов или фактов, которых не было во входе.
- **Понятность роли:** текст подходит аналитику, клиенту или руководителю, для которого он создан.
- **Стабильность:** одинаковый вход не порождает противоположные выводы.
- **Труд редактора:** сколько минут и исправлений требуется до утверждения.
NIST отдельно подчёркивает, что объяснение следует адаптировать к роли, знаниям и навыкам пользователя. Один универсальный абзац для инженера, клиента и проверяющего — экономия только на макете; потом каждый всё равно попросит свою версию.
Экономика: считать не токены, а снятую ручную работу
В кейсе основная ценность возникла не от замены прогнозной модели, а от сокращения труда вокруг неё. Для собственного расчёта нужны четыре величины:
- число объяснений в месяц;
- среднее время ручной подготовки и проверки;
- стоимость часа аналитика или эксперта;
- доля черновиков, принятых после минимальной правки.
Из экономии следует вычесть стоимость интеграции, тестового корпуса, вычислений, сопровождения и обязательной проверки. Локальная модель становится выгоднее не потому, что «токены бесплатные», а когда поток стабилен, данные чувствительны и сервер загружен полезной работой.
Для пилота достаточно одного типа отчёта и 100–300 исторических примеров. Сначала измеряют время человека и частоту смысловых ошибок, затем сравнивают базовый шаблон, LLM без дообучения и выбранную локальную модель. Большой GPU-кластер на старте не нужен: в кейсе HPC использовали для разработки и отбора, а не как обязательное условие каждого промышленного ответа.
Ограничения, о которых удобно забыть
SHAP и похожие методы описывают поведение модели, а не устройство реального мира. Сильный вклад признака не доказывает, что именно он вызвал событие. Языковой слой способен сделать эту ошибку убедительнее, поэтому причинные глаголы нужно запрещать правилами и тестами.
Второй риск — устаревший контекст. Корректное объяснение вчерашнего прогноза может быть бесполезным после обновления данных. Вместе с текстом следует хранить версии модели, признаков и исходного расчёта.
Третий риск — ложное ощущение аудита. Красивый абзац без сохранённого структурированного входа невозможно воспроизвести. Журналировать нужно не только промпт, но и контракт, результат проверок, правки человека и финальную версию.
Следующий шаг
Выберите один повторяемый отчёт, где эксперт регулярно переводит цифры на человеческий язык: прогноз спроса, отклонение качества, скоринг заявки, причины простоя или объяснение цены. Зафиксируйте входную схему, пять запрещённых типов утверждений и критерии приёмки. Проведите теневой пилот без отправки текста клиентам.
Если система сокращает время редактора, не меняет числа и честно сообщает ограничения, её можно подключать к рабочему процессу поэтапно. Если она только делает отчёт длиннее, робот-стажёр снова принёс стопку бумаг — теперь хотя бы известно, какой лимит поставить.