Непосредственно ответ клиенту формирует оператор. Если сервис не смог сгенерировать подсказку (в том числе если генеративка сказала, что ответа в документах нет) - мы ее просто не покажем оператору
Под хорошей репликой тут имеется в виду сообщение в стиле "Не хватает информации для ответа", по которому мы сможем понять, что документы не нашлись (поиск ошибся или может в БЗ и вовсе нет ответа на этот вопрос) и лучшее, что может сделать универсальная генеративная модель - это отказаться от ответа.
При дообучении под конкретного клиента мы чаще уходим от этого критерия, потому что там генеративная модель после обучения может выдать полезную подсказку для частых сценариев и без базы знаний
Не совсем так - если мы работаем с базовыми моделями, которые отвечают четко по документации, то да, эта доля потока останется без подсказок. Но если мы дообучаем их под конкретный сервис - отсутствие документа может компенсироваться обучением генеративки. Плюс бывают какие-то общие правила общения с клиентом, например, когда и как стоит прощаться, или когда стоит уточнить вопрос. В корзинку для оценки качества поиска (не самих ответов) мы такое стараемся не собирать (если нет подходящей страницы в базе знаний), но подобные спецэффекты все равно могут сказаться на потолке качества для таких корзинок
Картинка скорее отражает продуктовый образ. В самом общем случае анализ вопроса это по сути просто вычисление эмбеддинга. Для некоторых клиентов добавлялась предобработка с классификаторами запросов, на которые хорошую подсказку мы дать не сможем (в основном для уменьшения нагрузки на карты), но можно обойтись и без этого
По нашим экспериментам, для маленькой модели применение DPO сыграло ключевую роль в росте качества. На больших моделях мы тоже наблюдаем прирост качества от DPO, но не такой большой.
При этом для дообучения модели после DPO под конкретного клиента мы ограничиваемся SFT. В этом контексте тоже добавление DPO к базовой модели перед финальным SFT сильно подняло нам качество
Витальность мы используем только при внедрении модели для конкретных клиентов, чтобы учесть особенности общения с клиентом и выучить по данным то, что не описано в базе знаний. При этом дообучаем мы нашу универсальную (базовую) модель, которая учится именно на релевантных данных, чтобы избежать переобучения под какие-то неявные особенности сервисов
Благодаря такому подходу мы имеем отличные универасльные модели, которые из коробки складываются в качественный пайплайн, но при необходимости можем дообучить любую из них под конкретного клиента
Индексы могут содержать как большие, так и маленькие чанки или документы — это в первую очередь зависит от того, как организована база знаний у клиента. На таких данных мы обучаем модели поиска, и если в индексе лежат большие документы, эта модель должна уметь находить нужный даже в том случае, когда релевантная информация занимает лишь небольшую его часть. Конечно, лучше, когда документы разбиты на более мелкие фрагменты, но иногда такой возможности нет.
Если действительно можно без уточнения у пользователя определить заказ, то система это сделает даже без использования LLM. Однако есть много нюансов, например: вопрос может быть про старый заказ, он может быть задан с другого аккаунта пользователя. В таких и других сценариях лучше уточнить дополнительную информацию у пользователя, чтобы дать ему корректный ответ
Да, очень хорошие мысли - мы просим опытных операторов и службу контроля качества регулярно размечать подсказки с потока, чтобы следить за качеством. Пока этих данных заметно меньше, чем специально собранных другими процессами, поэтому они не играют ключевую роль в обучении, и фидбек по ошибкам и недостающей информации мы обрабатываем сами, не автоматически.
Сейчас экспериментируем с тем, чтобы поток, особенно с оценками и с правильным ответом оператора, анализировать и искать места для улучшения автоматически - находить потенциальные противоречия в базе знаний или непокрытые области, недостаток информации на входе и все подобное.
Для некоторых сервисов так же пробуем автоматическое локальное переписывание базы знаний, чтобы модель лучше по ней отвечала. Этот процесс чуть сложнее, надо убеждаться, что ключевая информация не теряется, но уже есть хорошие сигналы
Не секрет, используем наш OCR, он доступен в облаке, а ещё почитать про нашу VLM можно в недавнем посте
Только отмечу, что в API Нейросапорта нет встроенного OCR, нужно будет передавать текст. Если в документации есть сканы или что-то подобное - можно воспользоваться нашим облачным OCR или опенсорсными VLM-моделями в Yandex Cloud AI Studio
Непосредственно ответ клиенту формирует оператор. Если сервис не смог сгенерировать подсказку (в том числе если генеративка сказала, что ответа в документах нет) - мы ее просто не покажем оператору
Под хорошей репликой тут имеется в виду сообщение в стиле "Не хватает информации для ответа", по которому мы сможем понять, что документы не нашлись (поиск ошибся или может в БЗ и вовсе нет ответа на этот вопрос) и лучшее, что может сделать универсальная генеративная модель - это отказаться от ответа.
При дообучении под конкретного клиента мы чаще уходим от этого критерия, потому что там генеративная модель после обучения может выдать полезную подсказку для частых сценариев и без базы знаний
Не совсем так - если мы работаем с базовыми моделями, которые отвечают четко по документации, то да, эта доля потока останется без подсказок. Но если мы дообучаем их под конкретный сервис - отсутствие документа может компенсироваться обучением генеративки. Плюс бывают какие-то общие правила общения с клиентом, например, когда и как стоит прощаться, или когда стоит уточнить вопрос. В корзинку для оценки качества поиска (не самих ответов) мы такое стараемся не собирать (если нет подходящей страницы в базе знаний), но подобные спецэффекты все равно могут сказаться на потолке качества для таких корзинок
Картинка скорее отражает продуктовый образ. В самом общем случае анализ вопроса это по сути просто вычисление эмбеддинга. Для некоторых клиентов добавлялась предобработка с классификаторами запросов, на которые хорошую подсказку мы дать не сможем (в основном для уменьшения нагрузки на карты), но можно обойтись и без этого
По нашим экспериментам, для маленькой модели применение DPO сыграло ключевую роль в росте качества. На больших моделях мы тоже наблюдаем прирост качества от DPO, но не такой большой.
При этом для дообучения модели после DPO под конкретного клиента мы ограничиваемся SFT. В этом контексте тоже добавление DPO к базовой модели перед финальным SFT сильно подняло нам качество
Витальность мы используем только при внедрении модели для конкретных клиентов, чтобы учесть особенности общения с клиентом и выучить по данным то, что не описано в базе знаний. При этом дообучаем мы нашу универсальную (базовую) модель, которая учится именно на релевантных данных, чтобы избежать переобучения под какие-то неявные особенности сервисов
Благодаря такому подходу мы имеем отличные универасльные модели, которые из коробки складываются в качественный пайплайн, но при необходимости можем дообучить любую из них под конкретного клиента
Индексы могут содержать как большие, так и маленькие чанки или документы — это в первую очередь зависит от того, как организована база знаний у клиента. На таких данных мы обучаем модели поиска, и если в индексе лежат большие документы, эта модель должна уметь находить нужный даже в том случае, когда релевантная информация занимает лишь небольшую его часть. Конечно, лучше, когда документы разбиты на более мелкие фрагменты, но иногда такой возможности нет.
Хотим собрать обратную связь, прежде чем выпускать продукт в публичный доступ, поэтому точных сроков пока назвать не можем
Если действительно можно без уточнения у пользователя определить заказ, то система это сделает даже без использования LLM. Однако есть много нюансов, например: вопрос может быть про старый заказ, он может быть задан с другого аккаунта пользователя. В таких и других сценариях лучше уточнить дополнительную информацию у пользователя, чтобы дать ему корректный ответ
Да, очень хорошие мысли - мы просим опытных операторов и службу контроля качества регулярно размечать подсказки с потока, чтобы следить за качеством. Пока этих данных заметно меньше, чем специально собранных другими процессами, поэтому они не играют ключевую роль в обучении, и фидбек по ошибкам и недостающей информации мы обрабатываем сами, не автоматически.
Сейчас экспериментируем с тем, чтобы поток, особенно с оценками и с правильным ответом оператора, анализировать и искать места для улучшения автоматически - находить потенциальные противоречия в базе знаний или непокрытые области, недостаток информации на входе и все подобное.
Для некоторых сервисов так же пробуем автоматическое локальное переписывание базы знаний, чтобы модель лучше по ней отвечала. Этот процесс чуть сложнее, надо убеждаться, что ключевая информация не теряется, но уже есть хорошие сигналы
Не секрет, используем наш OCR, он доступен в облаке, а ещё почитать про нашу VLM можно в недавнем посте
Только отмечу, что в API Нейросапорта нет встроенного OCR, нужно будет передавать текст. Если в документации есть сканы или что-то подобное - можно воспользоваться нашим облачным OCR или опенсорсными VLM-моделями в Yandex Cloud AI Studio