Комментарии 22
Если не секрет что используете для OCR?
Не секрет, используем наш OCR, он доступен в облаке, а ещё почитать про нашу VLM можно в недавнем посте
Только отмечу, что в API Нейросапорта нет встроенного OCR, нужно будет передавать текст. Если в документации есть сканы или что-то подобное - можно воспользоваться нашим облачным OCR или опенсорсными VLM-моделями в Yandex Cloud AI Studio
Да, очень хорошие мысли - мы просим опытных операторов и службу контроля качества регулярно размечать подсказки с потока, чтобы следить за качеством. Пока этих данных заметно меньше, чем специально собранных другими процессами, поэтому они не играют ключевую роль в обучении, и фидбек по ошибкам и недостающей информации мы обрабатываем сами, не автоматически.
Сейчас экспериментируем с тем, чтобы поток, особенно с оценками и с правильным ответом оператора, анализировать и искать места для улучшения автоматически - находить потенциальные противоречия в базе знаний или непокрытые области, недостаток информации на входе и все подобное.
Для некоторых сервисов так же пробуем автоматическое локальное переписывание базы знаний, чтобы модель лучше по ней отвечала. Этот процесс чуть сложнее, надо убеждаться, что ключевая информация не теряется, но уже есть хорошие сигналы
а зачем у юзера спрашивать про его заказ если вы бы могли той же llm сходить и по юзеру получить его активные заказы и если 1 не задавать странных вопросов?
Если действительно можно без уточнения у пользователя определить заказ, то система это сделает даже без использования LLM. Однако есть много нюансов, например: вопрос может быть про старый заказ, он может быть задан с другого аккаунта пользователя. В таких и других сценариях лучше уточнить дополнительную информацию у пользователя, чтобы дать ему корректный ответ
Как долго будет в превью?
Подскажите, а как вы комбинировали подокументную и почанковую релевантность для обучения retrieval . Например, документ, может быть большим и странно все помечать как позитив.
Индексы могут содержать как большие, так и маленькие чанки или документы — это в первую очередь зависит от того, как организована база знаний у клиента. На таких данных мы обучаем модели поиска, и если в индексе лежат большие документы, эта модель должна уметь находить нужный даже в том случае, когда релевантная информация занимает лишь небольшую его часть. Конечно, лучше, когда документы разбиты на более мелкие фрагменты, но иногда такой возможности нет.
Подскажите, если вы используете витальность, то для каждого проекта вы до обучаетесь? Т е у вас нет такого, что одна модель может поддерживать все решения?
Витальность мы используем только при внедрении модели для конкретных клиентов, чтобы учесть особенности общения с клиентом и выучить по данным то, что не описано в базе знаний. При этом дообучаем мы нашу универсальную (базовую) модель, которая учится именно на релевантных данных, чтобы избежать переобучения под какие-то неявные особенности сервисов
Благодаря такому подходу мы имеем отличные универасльные модели, которые из коробки складываются в качественный пайплайн, но при необходимости можем дообучить любую из них под конкретного клиента
И вопрос про DPO- дает ли он прирост качества? и действительно ли он нужен, возможно стоит ограничиться только SFT?
По нашим экспериментам, для маленькой модели применение DPO сыграло ключевую роль в росте качества. На больших моделях мы тоже наблюдаем прирост качества от DPO, но не такой большой.
При этом для дообучения модели после DPO под конкретного клиента мы ограничиваемся SFT. В этом контексте тоже добавление DPO к базовой модели перед финальным SFT сильно подняло нам качество
На рисунке "В общем случае базовый сценарий сервиса выглядит так" написано, что первый этап "анализ вопроса клиента". А в самой статье ничего про это не указано. Можете раскрыть что на том этапе происходит?
Классификатор неприемлемых тем?
Картинка скорее отражает продуктовый образ. В самом общем случае анализ вопроса это по сути просто вычисление эмбеддинга. Для некоторых клиентов добавлялась предобработка с классификаторами запросов, на которые хорошую подсказку мы дать не сможем (в основном для уменьшения нагрузки на карты), но можно обойтись и без этого
Еще интересно смотрятся метрики hit_rate@32 ~80%
То есть вы уже на этом этапе понимаете, что больше чем на 80% вопросов не сможете ответить.
Не совсем так - если мы работаем с базовыми моделями, которые отвечают четко по документации, то да, эта доля потока останется без подсказок. Но если мы дообучаем их под конкретный сервис - отсутствие документа может компенсироваться обучением генеративки. Плюс бывают какие-то общие правила общения с клиентом, например, когда и как стоит прощаться, или когда стоит уточнить вопрос. В корзинку для оценки качества поиска (не самих ответов) мы такое стараемся не собирать (если нет подходящей страницы в базе знаний), но подобные спецэффекты все равно могут сказаться на потолке качества для таких корзинок
Простите, а тут опечатка, или на каком-то этапе действительно важно что бы сама структура ответа была корректная, но он может не относится к теме запроса?
А научить давать такой же хороший ответ но с попаданием в тему - это отдельный шаг.
Под хорошей репликой тут имеется в виду сообщение в стиле "Не хватает информации для ответа", по которому мы сможем понять, что документы не нашлись (поиск ошибся или может в БЗ и вовсе нет ответа на этот вопрос) и лучшее, что может сделать универсальная генеративная модель - это отказаться от ответа.
При дообучении под конкретного клиента мы чаще уходим от этого критерия, потому что там генеративная модель после обучения может выдать полезную подсказку для частых сценариев и без базы знаний
Сделали copilot-сервис для техподдержки и делимся секретами RAG c глубоким пониманием контекста