Про фейл с моделью Чего сегодня рассказали, делюсь с разрешения 🙂 В общем, небольшой региональный банк, выдает кредиты, они в конце прошлого/начале этого года решили попробовать пропилотировать использование LLM модели для оценки заемшиков. В целом как пилот и затевалось, но мало ли, думали что может что-то из этого выйдет. Взяли подрядчика, подрядчик решил пойти по пути файнтьюна как я понял, не понял зачем, но ок. Дообучили на исторических данных, на всем корпусе данных что было, на приемке на синтентических данных показало 90-95% точности. В целом круто, конечно. В прод выводить не стали, страшно, но каждую заявку стали отдельно отправлять в модельку и потом сравнивать модель и какое решение система/аналитик приняли. В общем, точность у них упала до 60-70%, начали разбираться почему, разобраться - отдельный челлендж, непонятно же почему такие решения, а модель попробуй допроси. И на самом деле они там до сих пор не уверены в своих выводах, но основной вывод был такой, что дообучали на всех заявках, а заявки поступали и решения принимались в разные периоды времени - были и кризисы и рост и разный кредитный портфель по объему и риску, то есть куча факторов, которые влияли на скоринг не только с учетом риск-профиля заявителя, но и кредитных аппетитов и рисков банка (к слову вот этот контекст восстановить полностью так и не удалось, получается нужно вычислить «дифференциал» в каждой точке принятия решений по кредиту, ну или на каком-то отрезке, в течение которого условия были стабильными, до изменений, а кто эти изменения фиксирует, попробуй выясни, что там поменялось). А поделиться я захотел, потому что сам все время указывают на потребность в качественных данных и качественном представлении этих данных для того, чтобы модели могли нормально работать, но вот этот кейс завел меня в тупик. Получается, что мало самих данных, нужны и условия в которых эти данные были сформированы, а как это получить - большой вопрос. У меня только два варианта как можно решить такую проблемы: • Сегментация данных по периодам стабильности (как написал в тексте выше), однако надо их как-то определить и определить точки перехода • Версионирование самих политик, без них как сегментировать не совсем понятно, в целом стоит видимо фиксировать под контролем версий все изменения в рамках принятых решений, чтобы собрать полный актуальный контекст в точке времени и в прошлом • Дополнять внешним контекстом (макроконтекстом) по отношению к компании, который имел влияние на принятие решения В Event Storming есть такая связка, что данные – это следствие решений, а не описание реальности само по себе. Получается, что модель, обученная только на данных, теряет причины, которые эти следствия сформировали, а это и есть та база, которая нужна модели, чтобы мы могли ее подпустить к принятию решений. Кстати, пока писал, подумал, что конкретно в решениям по кредитам это может быть решено (может кто-то так и делает), если вместе с заявкой, данными и решением сразу же сохранять в условном json весь тот контекст (условия), которыми руководствовались при принятии решения, хотя опять же, далеко не все доступно, макроситуация недоступна например. Ну и проблема не нова, в безопасности уже много лет система просто блокирует переводы, доступы, а почему - даже сам банк порой не знает и иногда не может узнать, но то безопасноть, совсем другое дело - операционные бизнес-процессы.