Как мы вкатывались в генеративный ИИ и куда катимся дальше

Всем привет!

Сегодня я хочу рассказать о внедрении финансового генеративного чат-бота в маркетплейс Выберу.ру и о том опыте, который был приобретен за время запуска этого проекта. Эта статья написана с целью объяснить концепции и трудности, с которыми мы с командой столкнулись, поэтому постараюсь обойтись без особого погружения в технические детали.

Приступим.

Зачем это нужно?

Генеративная модель с финансовым уклоном могла бы оптимизировать ряд процессов внутри проекта. При этом обучить модели классического или глубокого обучения для таких задач не получится, так как банально нет размеченных данных. Что же касается финансового генеративного чат-бота — здесь еще больше больше неопределенности. Направленность любого финансового маркетплейса быть для пользователя не просто агрегатором, а скорее тем местом, где пользователь сможет воплотить свои идеи и найти решение своим финансовым трудностям. Из этого вытекает обобщенная и очень грубая задача — понять, что хочет пользователь и как можно ему помочь.

Достаточно давно у нас был реализован раздел вопросов и ответов, где эксперты сайта могли бы взаимодействовать с пользователями. Но пользователей приходит все больше и больше. При этом становится просто физически сложно оперативно покрывать такое число запросов. Здесь и появилась мысль задействовать генеративный ИИ.

Череда обсуждений, согласований бюджетов, и вот уже есть свой локальный сервер с видеопамятью, но что с этим делать?

Стоит отметить, что ранее в эру GPT-3.5 и дообученных Сбером моделей GPT-2, я проводил эксперименты с текстовыми генерациями и параллельными хардкодными диалоговыми графами, но в те времена и модели были другими, и пользователи были не особо в теме, поэтому эксперименты зафиксировал и сфокусировался на более формализованных задачах. Тем не менее, некоторое понимание, с чего начинать, уже имелось.

Часть 1 - Выберу ИИ. Построение ядра ИИ-системы. Тестовый запуск

Этап 1 - Выбор модели

Ни для кого не секрет, что рынок моделей сейчас просто огромен на любой вкус и цвет, оставалось учесть только 2 критерия:

1. Ограничения видеопамяти. Я упомянул, что мы собрали локальный сервер, а не суперкомпьютер, поэтому 24ГБ — наш потолок.

2. Нативная поддержка русского языка.

Удивительно совпало, что на момент начала описываемых экспериментов и исследований генеративного ИИ на нашем проекте, коллеги по цеху из Т-Банка выложили в свободный доступ модели T-Lite и T-Pro первых версий на базе актуальной для того времени Qwen2.5-Instruct. .

Легкая версия модели на 7 миллиардов параметров влезает в нашу видеокарту без проблем, а про-версия уже только квантованная, причем в 4 бита. Тем не менее, решил исследовать обе.

Этап 2 - Файнтюнинг

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

Хорошо, нужно затюнить модели. Для этого понадобятся данные. В итоге были выбраны следующие:

• База наших новостей — около 20 тыс на момент обучения;

• Датасет вопросно-ответных пар от наших экспертов — около 5 тыс.

Да, в масштабах LLM это как капля в море, но для файнтюнинга и некоторого смещения весов модели в домен сайта не так уж и мало.

Для тюнинга мы с командой изучили самые последние и наиболее актуальные подходы, но тем не менее остановились на классических: LoRA и QLoRA для легкой и про-версий соответственно. Сильно погружаться в детали самого тюнинга не буду, лишь сделаю оговорку, что этапа тюнинга было два:

1. На сырых данных новостей.

2. На размеченных данных вопросно-ответных пар.

Хорошо это или плохо сказать однозначно трудно, но я посчитал, что так будет правильнее.

Экспериментов с тюнингом было много. А вот опыта в оценке таких экспериментов, мягко говоря, не очень. Поэтому поставил базовый минимум оценить, что не сломались:

• Знания модели о мире;

• Логические способности;

• Возможность следовать инструкциям.

Ниже я прикрепил таблицу замеров качества для финальных конфигураций LoRA и QLoRA для бенчмарка MERA, чтобы сделать статью более технической.

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

Какие выводы можно сделать на этом этапе? Если грубо, то показатели деградации качества невелики и где-то вовсе отсутствуют. А это уже свидетельствует о том, что модель не испорчена , по крайней мере насколько могла быть.

Оставалось только понять — стала ли модель лучше?

Для этой задачи уже бенчмарков недостаточно, нужно что-то более специфическое связанное с доменом непосредственно нашего сайта. Для себя определил три направления, которые показались наиболее интересными:

1. Смещение в сторону российского сегмента – модель понимает, что пользователь интересуется тем или иным вопросом, связанным с российскими законами, правилами и т.д.

2. Понимание цели вопроса – модель понимает обрывистые пользовательские вопросы в отрыве от контекста, а, следовательно, понимает его желания.

3. Углубленное понимание финансового сектора и смежных тем – более глубокое понимание порядка взаимодействия с государственными и частными организациями, знание порядка оказания услуг и пр.

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

1. Она в несколько раз больше легковесной, а следовательно, у нее есть более устойчивые паттерны в знаниях;

2. Увеличение QLoRA матриц при обучении приводило к переполнению памяти, поэтому использовал достаточно консервативные конфигурации.

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

Также дополнительно мы с командой еще прогнали бенчмарк LIBRA, по старинке написав код запуска и оценки своими силами. Чтобы не перегружать статью таблицами, отмечу, что здесь ситуация плюс-минус похожа на ситуацию с MERA, где-то незначительно лучше, где-то незначительно хуже, в общем, работает — не трожь.

С чувством некоторого облегчения, что в той или иной степени получилось сместить модельку в сторону домена сайта, я приступил к следующему этапу.

Этап 3 - База знаний

Очевидно, что полностью обучить модель каким-то нашим статьям или ссылкам не представлялось возможным, да оно и не было нужно. Все четкие инструкции по тем или иным узким вопросам можно хранить в какой-нибудь векторной базе и получать данные при необходимости. Касаемо выбора эмбеддинг-модели проблем не возникло, поскольку примерно в то же время коллеги из Сбера выложили FRIDA, к качеству которой вопросов практически не было, а приятным бонусом была длина контекстного окна 512 токенов.

Соответственно, я выделил наборы данных, которые хотел бы использовать. Причем практически сразу было принято решение хранить все это в отдельных коллекциях, поскольку могли бы быть хорошие документы как в условной группе вопросов-ответов, так и в группе наших сервисов.

Для наглядности приведу в пример данную схему, которую составлял к техническому отчету для Сколково во время первых этапов внедрения базы знаний.

К сожалению, все шутки про то, что RAG-системы возвращают, все что угодно кроме нужной информации, оказались совсем не шутками... Соответственно, далее пришлось плотно засесть за оптимизацию формата хранимых документов и настройку параметров пороговых значений при получении этих самых документов.

Спустя время стало очевидно, что на плотных ретриверах далеко не уедешь, а порогами перестраховываться уже не получалось. Соответственно пришлось настроить гибридный поиск с использованием плотных ретриверов в связке с разреженными. Такая система дала бОльшую гибкость в логике и контроле получаемых документов.

Опытный читатель мог бы заметить, что в описанном подходе ничего не сказано про переранжирование получаемой информации. В этой схеме не объединяются данные, полученные разными алгоритмами, а делается префетч с помощью BM25 на заранее выбранных коллекциях, на которых были замечены проблемы при поиске с плотным ретривером, а далее уже ранжируются результаты с помощью FRIDA. Плюсом ко всему, финальное переранжирование делается кросс-энкодерами, а это новые задержки по времени, которое я и так ужимал как мог, чтобы поймать баланс между скоростью и качеством.

Вообще, я уже упомянул BM25, но так же есть BM42 и Splade модели, почему же их не использовал? Проблема в отсутствии нативной поддержки русского языка — на момент написания статьи в токенизаторе нет русских n-грамм, только буквы. В сети есть мультиязыковые модели подобного плана, но запускаются они с использованием дополнительных библиотек, так что решил, что для текущих задач нам пока хватает BM25.

Хорошо, есть генеративное ядро, и подразумеваем, что нагрузка плюс-минус релевантная и полезная. Далее нужно было грамотно объединить все это воедино. Причем недостаточно просто дать модели запрос и документы из базы знаний в надежде, что она сама поймет, что нужно получить на выходе. Тут мы с вами переходим наверно к самой монотонной и нудной части запуска.

Этап 4 - Промптинг

Разово решить задачу, написав промпт в условный промышленный чат-бот дело не супер тяжелое. Сделать, чтобы этот промпт работал стабильно на разных запросах и разных входных данных с различной структурой — реально рокет сайнс.

На старте была допущена ошибка, я начал реализовывать одну общую универсальную инструкцию на все случаи с мыслью, что поддерживать один промпт на первых порах будет легче, чем несколько — уже чувствуется подвох, да? Суммарно не одни день был потрачен на написание этого супер-промпта, так он еще и работал через раз, и вызывал всякие побочные эффекты, на которые тоже требовался дополнительный анализ. Плюс изменения одной части промпта могли отломать ключевые инструкции другой части. Но время потрачено, надо запускать проект, а как улучшать уже непонятно.

Только спустя время я все-таки решился разбить эту логику на части, и сделать возможно более хардкодное разделение на разные промпты, но зато стабилизировать поведение модели.

Если до сих пор не до конца ясно, почему в проекте уделяется столь пристальное внимание промптингу, приведу пример. Вместе с документами для модели прописано использовать ссылки в своем ответе. Как думаете, что делает наша модель, если в объемном промпте есть инструкция: "Выведи точную ссылку на ресурс"?

а) Выведет ссылку, которая указана в контексте;

б) Придумает свою ссылку;

в) Модифицирует ссылку из контекста.

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

Стоит сразу отметить, этот пример касается только нашей модели с нашей структурой промптов, остальные модели могут работать иначе.

Этап 5 - Запуск

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

И в этом нет ничего удивительного, понимаете, для выделения ресурсов на продакшн стенды необходимо по крайней мере минимальное понимание ценности продукта и возможности его монетизации хотя бы в перспективе. Поскольку подобных решений именно в нашей области мало, то в принципе сложно понять, готов к этому пользователь или не готов, да и до конца не ясно, что он вообще ожидает от такой системы. Как оказалось, не готов…Точнее сработал ряд факторов.

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

Часть 2 - Выберу ИИ. Чат-бот

Несмотря на подавляющее большинство нерелевантных запросов к модели, прослеживался один важный момент. Пользователь не хочет обращаться к модели в качестве вопросно-ответной системы. Ему нужен как бы собеседник, который на каждом этапе беседы помнит тему прошлых сообщений.

Вроде бы звучит не сложно, нужно просто где-то хранить пользовательские сообщения и затем, при ответе на вопрос пользователя, подгружать эти сообщения в промпт модели. Но дьявол кроется в деталях.

Деталь 1 - Что и как хранить

Напомню, что помимо пользовательского вопроса и сгенерированного ответа, есть еще достаточно объемный список документов, которые были получены из базы знаний. Нужно ли их хранить?

Вообще единого ответа на этот вопрос нет, но концептуально — нужно.

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

Наиболее очевидный план — просить модель после каждого ответа суммаризировать информацию. Но как сделать это быстро?

Очевидно, что если сконкатенировать для малой модели все тексты сразу, и попросить суммаризировать, то она потеряет очень много информации, а объяснить ей, что суммаризируй, но как бы не полностью, задача не из самых простых, кто работал с этим, тот поймет. При этом скармливать ей документы по-отдельности достаточно долго.

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

В итоге на помощь пришел structured output — а именно подаем json документов, и на выходе просим json документов, где максимально наивная связка ключ-документ, никакой магии. При этом за один запрос получаем приемлемое качество суммаризаций нескольких документов, да еще и с четкой структурой, чтобы можно было их адекватно парсить и забирать в базу с историей чатов.

В итоге при ответе на вопрос используется N-предыдущих групп: (вопрос, ответ, суммаризированный контекст).

Деталь 2 - Оптимизация поиска в базе знаний

Допустим, первый вопрос звучит так — "Подбери мне ипотеку?". При этом следующий уже может звучать — "А для молодых семей?".

В общем логика ясна, нужно научиться обрабатывать неполные предложения. И по классике вещей для этого используется наша ИИшка. В этот раз все еще проще. Объясняю, что ей нужно интерпретировать пользовательское сообщение, и далее, по интерпретируемому сообщению, уже осуществляю поиск в базе знаний.

Критически важным в данном случае является момент объяснения логики интерпретации модели. Вот отрывок инструкции:

При интерпретации всегда отдавай абсолютный приоритет самому последнему контексту. Анализируй историю снизу-вверх (от последнего сообщения к первому). Последняя реплика ассистента - это главный и первичный контекст для интерпретации.

Для дополнительной точности эмулирую chain of thought и structured output по следующей структуре:

{ "reasoning": "Пошаговый анализ (3-7 шагов)", "interpreted_message": "Полное самостоятельное сообщение" }

Деталь 3 - Четкое следование инструкциям

Эта деталь самая интересная. Кто бы мог ожидать, что модель продолжит так же стабильно следовать инструкциям при сильном увеличении промпта вследствие добавления истории диалога.

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

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

Несмотря на специфичность промптов, оставался один существенный недостаток — инструкции подразумевали, что модель должна быть полезной для пользователя. Даже в случае, когда пользователь хотел завершить диалог («Хорошо, понял», «Спасибо, учту» и т.д.), модель продолжала ему отвечать по теме предыдущего запроса из истории. В этот момент я реализовал классификатор тематик, в частности, чтобы отлавливать сценарий завершения диалога. Впоследствии этот классификатор перерос в topic guardrails.

Логика следующая: у нас есть список предопределенных тем, которые мы бы хотели уметь обрабатывать. Составляем описания этих тем и загоняем в Qdrant. Далее во время поиска по Qdrant мы получаем дополнительно топ-N ближайших документов из коллекции тематик и валидируем правильность выбора с помощью генеративной модели. Конечно, можно было бы обойтись из без Qdrant и сразу загонять все это в нашу модель, но я попытался оптимизировать процесс выбора тематики, чтобы классификация генеративкой проходила быстрее.

В итоге получилось решить проблему со стабильностью работы модели в конкретных темах, и сразу реализовать базовый функционал для topic guardrails, в котором затем были настроены различные чувствительные тематики.

Куда мы движемся дальше

Закончив со всеми деталями, переходим к одному не очень позитивному выводу — многое зависит от того, как представлять чат-бота и где именно указать точку входа.

Была проведена крупная работа по стабилизации чат-бота — да. Заинтересован ли пользователь в функционале чат-бота — не совсем.

По крайней мере, когда мы с командой разработки и менеджмента запустили его в новостном разделе, 90-95% запросов были просто не по тематике сайта: то требуют соединить с оператором Озона, то вернуть деньги, то включить интернет. В итоге продолжаются работы над расширением функционала и эксперименты с точками входа.

Касаемо расширения функционала

Следующая цель — активно использовать tool calling.

Ранее на схеме взаимодействия с базой знаний были указаны коллекции, и вот одна из коллекций — продукты — сейчас полностью отключена. Это было сделано, поскольку в продуктах слишком много параметров, и хоть продукт может быть семантически близкий, мы все еще не уверены в том, что он подходящий. Так же есть нюанс в том, что полученный по семантической близости продукт или группа продуктов могут быть не самыми лучшими из условной выборки подходящих продуктов. По этим причинам парадигма сместилась в сторону рекомендации ранжированных подборок непосредственно на сайте. В свою очередь, качественно реализованная база под tool calling посредством взаимодействия с различными API сайта поможет оперировать такими группами продуктов и тем самым составлять свои подборки, сравнения и прочее, но уже на базе Выберу ИИ.

Также мы с командой продолжаем внедрять наш ИИ в различные процессы в отрыве от чат-бота. Если будет интерес к этой теме, то я постараюсь рассказать про это в следующих статьях.

Спасибо!