Что касается бустов источников, сейчас бусты у нас довольно простые - они решают базовую задачу приоритета источников (доки > тикеты), но не претендуют на динамическую оптимизацию. Автоматическое присваивание всем наиболее свежим тикетам высоких бустов, на мой взгляд, может быть болезненно для качества ответов в целом, так как тикеты часто содержат частные кейсы, временные обходные решения или обсуждение, которое может быть нерелевантно для большинства пользователей. В таком случае система начнет чаще вытаскивать шум вместо проверенной документации. Что касается валидации реранкеров, то сейчас у нас идёт альфа-стадия, поэтому полноценного A/B ранкеров пока нет. Основная валидация, пока что, это - ручная проверка кейсов и сбор обратной связи от пользователей. Отдельного слоя автоматической детекции конфликтов между чанками сейчас нет. Частично это нивелируется приоритезацией источников (тем, что продуктовой документации доверяем больше, чем другим категориям источников знаний) и тем, что у нас есть сегментация базы знаний по версиям документации - это позволяет свести к минимуму вероятность того, что в один контекст попадут инструкции из разных версий продукта. Более сложные проверки консистентности (graph-подходы и т.п.) пока не реализованы, но это вполне возможное направление развития. Что касается метрики в 80 процентов, то сейчас это human eval по результатам альфа-тестирования: смотрим ответы, собираем обратную связь и оцениваем, помог ли ответ решить задачу. По мере накопления данных планируем добавлять и более формальные метрики.
Сейчас у нас пока что идёт альфа-тестирование и параллельно наполняем бэклог такими улучшениями. Если увидим подтверждённый спрос от бизнеса на обработку подобных кейсов, будем это добавлять в систему. Что касается, конкретно, уточнений, то на текущем этапе это не критичная проблема - в реальной работе пользователи довольно часто сами уточняют вопрос следующей репликой, если ответ оказался не про тот сценарий или сценарий тот, но ответ недостаточно полный, так что для альфы это вполне нормальное поведение системы
Идея понятная, но мне кажется тут есть сложность, связанная с тем, что правильных ответов на один вопрос может быть несколько, и тогда система может посчитать ухудшением ответ, который на самом деле просто сформулирован иначе или даже стал лучше. Например, если на вопрос пользователя эталонный ответ - «Ошибка возникает из-за истёкшего токена авторизации», а новый ответ модели - «Причина ошибки - истёкший access token. Введите логин и пароль заново, вот ссылка - .../auth», то по смыслу он даже лучше (добавлено действие), но автоматическое сравнение может решить, что ответ «хуже», потому что он отличается от эталона
Да, в основе архитектуры действительно используется классический RAG - об этом в статье прямо написано. И я согласен, что GraphRAG - действительно интересное направление, и мы тоже смотрим в эту сторону. Но пока мы пошли от более простого и устойчивого решения: сначала собрать рабочий RAG, который реально помогает людям находить информацию (что, по сути, и было целью)
Что касается бустов источников, сейчас бусты у нас довольно простые - они решают базовую задачу приоритета источников (доки > тикеты), но не претендуют на динамическую оптимизацию. Автоматическое присваивание всем наиболее свежим тикетам высоких бустов, на мой взгляд, может быть болезненно для качества ответов в целом, так как тикеты часто содержат частные кейсы, временные обходные решения или обсуждение, которое может быть нерелевантно для большинства пользователей. В таком случае система начнет чаще вытаскивать шум вместо проверенной документации.
Что касается валидации реранкеров, то сейчас у нас идёт альфа-стадия, поэтому полноценного A/B ранкеров пока нет. Основная валидация, пока что, это - ручная проверка кейсов и сбор обратной связи от пользователей.
Отдельного слоя автоматической детекции конфликтов между чанками сейчас нет. Частично это нивелируется приоритезацией источников (тем, что продуктовой документации доверяем больше, чем другим категориям источников знаний) и тем, что у нас есть сегментация базы знаний по версиям документации - это позволяет свести к минимуму вероятность того, что в один контекст попадут инструкции из разных версий продукта. Более сложные проверки консистентности (graph-подходы и т.п.) пока не реализованы, но это вполне возможное направление развития.
Что касается метрики в 80 процентов, то сейчас это human eval по результатам альфа-тестирования: смотрим ответы, собираем обратную связь и оцениваем, помог ли ответ решить задачу. По мере накопления данных планируем добавлять и более формальные метрики.
Qdrant
Сейчас у нас пока что идёт альфа-тестирование и параллельно наполняем бэклог такими улучшениями. Если увидим подтверждённый спрос от бизнеса на обработку подобных кейсов, будем это добавлять в систему.
Что касается, конкретно, уточнений, то на текущем этапе это не критичная проблема - в реальной работе пользователи довольно часто сами уточняют вопрос следующей репликой, если ответ оказался не про тот сценарий или сценарий тот, но ответ недостаточно полный, так что для альфы это вполне нормальное поведение системы
Идея понятная, но мне кажется тут есть сложность, связанная с тем, что правильных ответов на один вопрос может быть несколько, и тогда система может посчитать ухудшением ответ, который на самом деле просто сформулирован иначе или даже стал лучше.
Например, если на вопрос пользователя эталонный ответ - «Ошибка возникает из-за истёкшего токена авторизации», а новый ответ модели - «Причина ошибки - истёкший access token. Введите логин и пароль заново, вот ссылка - .../auth», то по смыслу он даже лучше (добавлено действие), но автоматическое сравнение может решить, что ответ «хуже», потому что он отличается от эталона
Да, в основе архитектуры действительно используется классический RAG - об этом в статье прямо написано. И я согласен, что GraphRAG - действительно интересное направление, и мы тоже смотрим в эту сторону. Но пока мы пошли от более простого и устойчивого решения: сначала собрать рабочий RAG, который реально помогает людям находить информацию (что, по сути, и было целью)