Сегодня мы запускаем Yandex Neurosupport — сервис, который генерирует умные подсказки для операторов контакт‑центра. Он выполняет функции второго пилота: нейросеть анализирует текстовые вопросы клиентов и предлагает оператору вариант ответа. В основе лежат облегчённые модели семейства YandexGPT, дообученные на инструкциях для операторов более чем 50 сервисов Яндекса. Cервис можно внедрить в свой интерфейс через Yandex Cloud по API или же развернуть в on‑premise‑окружении.

Технологическим ядром выступает RAG — звучит просто, но здесь не обошлось без добавления особой яндексовой магии. В этой статье вместе с ребятами из нашей команды ML B2B‑проектов, а также коллегами из команды базовой технологии, Yandex Cloud, «Маркета» и «Еды» расскажем подробнее, как вместе делали этот сервис и каких результатов достигли.

В чём боль ML в поддержке

По данным исследователей из Intercom, 45% служб поддержки уже используют нейросети и классические ML‑модели. Но зачастую многие задачи до сих пор решаются вручную, процессы получается автоматизировать до определённого уровня, а дальше эффективность снижается.

Это связано с тем, что стандартные решения часто используют строго описанные сценарии в графах, с фиксированными переходами. Такие графы довольно быстро разрастаются с развитием системы. Гораздо удобнее поддерживать базы знаний, но внедрить RAG‑подход вместо сценариев в графах бывает сложно.

Здесь можно вспомнить историю, как технологии связи распространялись в эпоху ADSL‑модемов. В тех регионах, куда модемы добрались рано, проникновение связи было хорошим и обеспечивало приемлемое качество связи. Но с появлением оптики скорости стали расти, а модемы уже не могли соревноваться с новой технологией.

Переподключать абонентов в таких регионах было дорого и нерентабельно, поскольку скорость увеличивалась всего на 30–50%. Больше повезло тем, кто сразу подключал оптику и получал качество связи на нужном уровне.

Если же компания уже развивает базу знаний и решает использовать RAG, то всё выглядит просто на первый взгляд. Берём модель‑эмбеддер, с её помощью преобразуем весь текст в базе знаний в вектор, складываем в векторную базу данных. Когда мы получим запрос от пользователя, преобразуем запрос в вектор, затем в базе данных найдём похожий вектор и соответствующие ему тексты, соединим это всё с системным промптом и отправим запрос в большую языковую модель. Profit! Но уже потом выясняются свои тонкости на каждом из этапов: и в части retrievаl, и в части generation.

На старте сразу несколько причин мешают сделать ML в техподдержке эффективнее:

• Качество поиска сильно зависит от данных, на которых мы дообучаем и инферим модели.

• Саму базу знаний нужно поддерживать в актуальном состоянии и следить за тем, как она написана: нужно отслеживать противоречия, полноту, учитывать сценарии переписывания базы.

• Большое количество нужной для ответа информации содержится помимо самого диалога с пользователем в различных метаданных (например, информации о заказе со всеми нужными статусами).

• Способы оценки качества с учётом особенностей сервиса могут различаться.

• Есть свои особенности в построении индекса по базе знаний, которая используется для RAG.

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

1. В самом сердце — наши универсальные модели для поиска и генерации ответов в сценариях саппорта. За счёт этого мы обеспечиваем качественное понимание задачи: помочь клиенту и найти нужную информацию по базам знаний совершенно разного рода.

2. Поверх них при необходимости мы можем проводить дообучение под конкретные сервисы, чтобы учесть особенности общения с клиентом, редакционную политику и прочие тонкости.

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

Нередко все эти компоненты приводят к росту качества конечных ответов на 50 пп.

Пойдём по порядку и начнём с базовой технологии, о которой расскажет Света Маргасова @margasova09

Как устроена базовая технология Yandex Neurosupport 

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

В нашем RAG‑пайплайне есть модели для поиска релевантных фрагментов текста по базе знаний (retrieval‑часть), а также генеративная модель, которая выдаёт фразы‑подсказки для оператора, чтобы продолжить диалог с клиентом.

Для оценки качества генеративной модели мы сформировали сложную корзину из 12 различных сервисов и абсолютно разных задач и использовали nhb‑градации качества:

• «хороший ответ» — полный ответ или хорошая реплика в случаях, когда сам контекст нерелевантен;

• «частично хороший ответ» — ответ, требующий небольших доработок от оператора;

• «плохой ответ» — нерелеватный или неподтверждённый ответ.

Пришли к такому результату:

Посмотрим по этапам, как этого достигли.

Retrieval 

При работе с текстовыми данными все документы сначала нарезаются на логически связанные части — чанки. На retrieve‑этапе мы ранжируем эти чанки по релевантности запросу в две стадии:

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

• На второй стадии переранжируем отобранный пул с помощью модели‑реранкера, которая видит одновременно и запрос, и документ и выносит вердикт о релевантности.

Сначала покажу, как происходило дообучение моделей на retrieval‑этапе, а затем расскажу, как оценивали качество и получали этот результат.

Обучение моделей

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

Помимо почанковых данных, мы также использовали разметку на предмет релевантности полных документов. Для сбора таких данных мы использовали несколько источников из журналов наших сервисов:

• когда операторы отмечали полезные для ответа документы (подокументная релевантность);

• если ответ оператора полностью скопирован из документа, то среди всех чанков, на которые разбивается документ, мы определяли как релевантные те, которые содержат ответ (почанковая релевантность).

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

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

Детали дообучения векторных моделей:

• использовали Contrastive Loss;

• в качестве негативов брали in‑batch‑негативы (для увеличения их числа использовали cross‑batch‑негативы со всех GPU при multiGPU‑обучении).

А если заменить архитектуру на cross‑encoder, то получим один из вариантов реализации модели‑реранкера.

Качество обучения эмбеддингов по внутреннему бенчмарку из пяти сервисов на моделях без дообучения и с дообучением.

Оценка качества retrieval

Для оценки качества можно использовать два подхода (мы используем оба):

• оценивать качество найденных чанков с помощью разметки редакторами;

• собрать retrieve‑бенчмарк для автоматической оценки качества.

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

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

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

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

Рассмотрим пример

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

Однако опытный оператор сервиса может посмотреть на метаинформацию и увидеть, что способ доставки — особенный, для которого есть отдельная страница в базе знаний, и правила ответа в таком случае будут отличаться. И вот такой документ уже будет являться витальным. В релевантном документе (или тем более чанке) может не быть информации, которая бы отразила, что для данного диалога документ не применим. Чтобы это понять надо быть глубоко погруженным в специфику работы конкретного сервиса.

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

Генеративная модель

Для достижения нужного нам качества дообучение прошли не только модели на retrieval‑этапе, но и модели, генерирующие ответы. Для обучения специализированной генеративной модели мы делаем дополнительные alignment‑стадии поверх instruct‑моделей семейства YandexGPT 5.

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

• модель выдаёт много частично хороших ответов;

• модель плохо отвечает на нерелевантных чанках (простыми словами, она плохо формулирует вежливый отказ от ответа на вопрос не по адресу).

Чтобы улучшить качество мы делаем дополнительную стадию SFT‑обучения, для которого используем идеальные ответы, написанные редакторами. Стоит отметить, что мы не используем реальные ответы операторов из логов, они довольно шумные по нескольким причинам:

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

• операторы могут ошибаться.

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

• берём тот же набор инстрактов, что и для SFT‑стадии;

• генерируем ответы‑кандидаты набором лучших моделей;

• позитивный и негативный ответ отбираем по ансамблю ревордов: базовые реворд‑модели YandexGPT, набор специализированных для Yandex Neurosupport ревордов, обученных на разных подмножествах данных;
  Замечание: для дообучения специализированных ревордов нам всё‑таки пришлось разметить небольшой сэмпл данных на предмет ранжирования ответов по качеству.

• дополнительно на позитивный ответ добавляем ограничение по подтверждённости с golden‑ответом из SFT.

Оценка качества генеративной модели

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

Дополнительно в корзине выдержана пропорция по качеству retrieval:

• 70% диалогов содержат среди топ-3 релевантные чанки, информации в которых достаточно для решения проблемы клиента;

• 30% диалогов содержат топ-3 нерелевантных чанка, в таких диалогах мы ожидаем ответ наподобие вежливого отказа «Недостаточно информации для ответа» (фраза для такого ответа явно прописана в промпте). Такие подсказки в дальнейшем не показываются оператору.

Важной особенностью оказалась настройка качества модели на нерелевантных чанках (способность вежливо отказываться от ответа). Для достижения наилучшего баланса мы подбирали пропорцию таких ответов в обучении на каждой стадии. Мы пришли к следующей пропорции: в SFT — 7% вежливых отказов, в DPO — 10% примеров с позитивным вежливым отказом, 5% примеров с негативным вежливым отказом.

Теперь, когда у нас есть такие хорошие базовые модели, займёмся их доработкой под конкретные сервисы. Тут нам помогут Егор Кашпар @shaun_the_sheep и Максим Зайцев.

Дообучение моделей под конкретные сценарии

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

Подготовка данных. Есть несколько вариантов для дообучения эмбеддеров:

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

2. Поскольку операторы тоже ошибаются, можно фильтровать ответы по разным операторам, например, с учётом их опыта, либо использовать умную LLM. Просим такую модель проверить соответствие документа ответу оператора, а также проверить сам ответ на соответствие диалогу.

3. Есть стандартные махинации для обучения пары «embed + rerank»: используем negative sampling и считаем негативными пары, которые отфильтровала LLM.

4. Если мы работаем с диалогами, в выборку можно добавить пары «диалог + документы», в которых документы отвечают на один из предыдущих уже решённых вопросов, и дать такой паре таргет 0. Там можно акцентировать внимание эмбеддера на последнем вопросе клиента, по которому и нужно находить ответ.

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

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

Теперь про адаптацию стадии переранжирования и оценку качества в конечных сервисах расскажут Алексей Островский @good_soup и Таймураз Тибилов @timtibilov

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

В качестве признаков или фичей мы чаще всего останавливаемся на следующих:

• эмбеддинг документа;

• эмбеддинг диалога;

• косинусная близость между ними (диалог‑документ);

• ранк документа, упорядоченный по косинусной близости.

Умножив это на количество ретриверов в multiretrieve‑подходе, получаем достаточный список признаков (фичей). При желании на этом этапе можно вложить больше информации о документах, специфичной для сервиса, например, о частоте использования документа операторами.

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

И теперь мы можем обучить классификатор, показывающий необходимый score полезности документа к диалогу. Отсортировав по этому значению, получаем наш топ документов. Как итог — у нас прирост метрики качества поиска ещё на 5–10 пп.

Оценка качества ответов на внедрении

В условиях практически любого проекта внедрения RAG встаёт закономерный вопрос: как оценивать качество внедрённой модели? Идеально — на готовой размеченной выборке: есть пользовательский запрос, есть эталонный ответ, есть условно метка «хорошо/плохо». Разметки — наилучший способ как отслеживать изменения в логике ответа, так и обогащать данные для обучения. Но, как мы уже говорили в самом начале, разметить все чанки для каждого запроса очень сложно. А также у каждого сервиса есть множество тонкостей (вспомним те же витальные документы), поэтому используются несколько способов.

Оценки на основе разметок 

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

Чуть подробнее о каждой.

Оценка качества подсказок определяет качество генерации ответа. Наш главный инструмент в замере итогового результата, является ещё и самым большим направлением. Логика разметки следующая:

• Для начала определяем, можно ли вообще из имеющейся метаинформации и текста диалога сгенерировать ответ. Сомнений здесь может быть несколько: например, если в тексте был прислан визуальный объект (скриншот, фото), если требуется активное действие для перевода между линиями, нужен дополнительный анализ с помощью сервисов отслеживания товара, или же просто диалог неинформативный.

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

  • 1 — Критически плохо;

  • 2 — Бесполезно;

  • 3 — Требует значимых правок;

  • 4 — Можно отправить с минимальными правками;

  • 5 — Идеальный ответ.

Эта разметка полезна, поскольку она не только позволяет оценить качество моделей, но и приблизительно показывает прокси‑метрику экономии АХТ. Её вычисляем с помощью умножения оценки на коэффициент, конвертируемый в ускорение/замедление ответа.

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

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

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

Для промежуточных оценок качества и ускорения итераций обучения моделей сильно помогают автоматические процессы оценок, про которые расскажет Тимур Сухарев @tsuharev

Как оценить качество с помощью reasoning-моделей без ручной разметки

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

Чтобы ускорить разработку и не перегружать разметку, мы начали использовать для оценки качества reasoning‑модели, включая нашу, и построили вокруг них трёхэтапную методику автоматической оценки:

1. Есть ли информация в документах? Первый промпт проверяет, содержат ли подобранные для контекста чанки из базы знаний ту информацию, что необходима для ответа на пользовательский запрос. Это позволяет понять, насколько retrieval‑часть справляется с задачей.

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

3. Как звучит ответ, если смотреть только на запрос? На третьем этапе reasoning‑модель оценивает финальный ответ, не имея доступа к документам, — только на основе запроса. Это приближается к глазами обычного пользователя: понятно ли, точно ли, уместно ли, полезно ли.

Комбинируя оценки с трёх точек зрения, получаем агрегированный score, который качественно коррелирует с человеческой оценкой. В пилотах с заказчиками совпадение шкал достигает 70% — достойный результат при полном отсутствии ручной разметки. Так что даже без идеальных датасетов можно строить вменяемую систему оценки RAG‑решений.

Теперь перейдём к последнему и критически важному компоненту нашего пайплайна — к подготовке и работе с базой знаний, про которую также поведает Тимур @tsuharev

Работа с индексом

Построение индекса по базе знаний, которая используется для RAG, начинается с работы над самой документацией. Базы знаний бывают со всевозможными данными, от экселек до ворда на тысячи страниц. Главная проблема — что удобно человеку, далеко не всегда удобно машине и может быть совершенно нечитаемо для парсера.

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

1. Структурированные support‑базы, которые содержат описание типовых проблем и алгоритмы их решения. Часто такие данные уже лежат в базе данных, откуда их можно выгрузить в виде удобного JSON. Идеальный вариант для машинной обработки, особенно если каждое решение можно превратить в отдельный чанк с понятным заголовком и применимостью по условиям.

2. Неструктурированные знания первого уровня — текстовая документация, часто предназначенная для внутренних нужд службы поддержки. Такие БЗ требуют полноценного конвейера: парсинг, распознавание, структуризация, нарезка и нормализация.

3. FAQ/чат‑бот стилистика — базы в формате «вопрос — ответ». Сюда же отнесём огромные справочники по продукции, услугам, тарифам, адресам — нередко формально оформленные как контент для ботов. Такие базы хорошо ложатся в retrieval‑часть RAG и позволяют строить эффективные чат‑решения при минимальной генерации.

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

Что важно с точки зрения подготовки данных 

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

Один из удобных подходов — использовать уже существующую разметку документа. Например, Markdown позволяет иерархически структурировать материал: заголовки, списки, абзацы — всё это даёт естественную «сетку», по которой можно разбить документ. Если разметки нет, но есть оглавление — это тоже может стать опорной точкой для нарезки. Но что если клиент не планирует использовать Yandex Neurosupport в режиме self‑сервиса и хочет запросить помощь в подготовке данных от нашей ML‑команды — как мы могли бы автоматизировать эти задачи на своей стороне?

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

На полях: что не так (и что так) с опенсорсом для этих задач

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

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

А что насчёт LLM для парсинга документов? Один из частых вопросов при обработке неструктурированных данных: «А зачем вообще парсить? Сейчас же куча больших языковых моделей — можно просто скормить документ LLM, и всё само распарсится, правда?». Да, так тоже можно. Но с оговорками и с осторожностью.

Сценарии, где LLM действительно отлично работают, — это короткие или средние по объёму документы: страница текста, краткая инструкция, небольшая спецификация.

Но как только вы сталкиваетесь, скажем, с документом на 120 000 токенов (в моей практике был и на 1,5 миллиона) — начинается совершенно другая история.

Приходится нарезать, использовать вспомогательные стратегии, например, «chunk + reassemble». Иначе можно встретиться с тем, что LLM в таких случаях склонны... заниматься суммаризацией. А точность данных нередко критична, например, в юридических, финансовых, технических документах.

При этом в документации встречается не только текст. Ещё работа с базами знаний — не только тексты и абзацы. Во‑первых, на практике часто встречаются таблицы. К сожалению, они бывают со сложным оформлением, смещениями или многословными заголовками, которые трудно адекватно распарсить. Во‑вторых, информация может быть в виде иллюстраций, схем, графиков и других изображений. На этапе машинной обработки по картинке сложно понять, это просто иллюстрация к тексту (например, скриншот), или же уникальная информация, которой в текстовой части документа нет.

На помощь приходят два класса технологий: OCR для извлечения текста с изображений, скриншотов и сканов и визуально‑текстовые модели (VLM), которые также способны понять контекст изображенного.

Отдельный вид боли — документация с алгоритмическими диаграммами, например, схемами поведения службы поддержки. Также в сложные случаи попадёт и документация в виде диаграмм баз данных. В таком случае без привлечения VLM‑моделей уже не обойтись.

Универсального рецепта для обработки всех изображений нет, каждое из них требует анализа. Мы, как правило, реализуем условную логическую проверку — если изображение содержит читаемый текст, применяем OCR. Если нужно «понять» объект в целом — используем VLM, давая модели инструкцию объяснить, что изображено и в какой части документа это применяется.

Такой подход позволяет извлекать полезную информацию даже из визуального контента, который ранее оставался «слепым пятном» для систем поиска и генерации ответов.

Как эти проблемы решаются в нашем конвейере обработки

При подготовке данных для RAG‑системы мы в первую очередь явно извлекаем из текста заголовки (тайтлы) и контекстуальные описания (semantic titles) для чанков. Это не просто «красивые подписи» — это фундамент, который влияет на релевантность поиска и точность ответов. Так, если заголовки слишком общие (например, «Инструкция» или «Раздел 5»), также используются отдельные модели для контекстуализации, где нейросеть анализирует содержимое чанка и формирует его краткое описание.

Итоговая цепочка обработки разнородной документации в сервисе выглядит так — всё укладывается в конвейер. У нас есть несколько модулей («коробок») с более‑менее универсальными парсерами и стратегиями нарезки. При необходимости подтягиваются дополнительные инструменты — OCR и VLM, если попадаются сканы, схемы или картинки с важной информацией. На выходе получаем нормализованный контент в Markdown‑подобном формате.

Далее запускаем стандартный пайплайн: разбивка на чанки, генерация эмбеддингов, индексация — и всё это идёт в RAG‑систему. Такой подход позволяет закрывать до 70% типов корпоративной документации без ручной работы в каждом новом проекте.

Частота обновления документации и влияние на индекс RAG. Документация может меняться очень часто: по нашим наблюдениям, в некоторых сервисах до трети контента редактируется каждый месяц. Если при этом индекс не обновляется, система начинает «говорить прошлым»: отвечает на основе устаревших эмбеддингов, а не актуальной информации. Лучшим решением будет автоматизировать переиндексацию: отслеживать изменённые документы, обновлять эмбеддинги и аккуратно замещать старые чанки в базе.

Как итог, практика показывает, что такая дотошная работа с индексом — это не просто «предобработка», а ключевой рычаг повышения качества в RAG‑системах.

В одном из наших кейсов переход от базового индекса (с быстрым эмбеддером и без особой нарезки чанков) к более проработанному пайплайну дал рост покрытия релевантных ответов с 20% до 65% — и это без дообучения модели или кастомных эмбеддингов.

Мы взяли стандартную генеративную модель и дефолтный эмбеддер, но тщательно поработали с индексом:

• грамотно нарезали чанки по смыслу,

• варьировали их размер,

• придумали осмысленные заголовки,

• убрали шум,

• классифицировали типы контента,

• и выстроили кастомную стратегию выбора кандидатов на этапе retrieval.

Если поверх этого немного поиграть с промптами в генеративной части, то можно легко добавить ещё 10–15% по метрикам релевантности ответа и полноты.

---

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

Но останавливаться на достигнутом мы не собираемся. Мы продолжаем совершенствовать наши модели и создавать новые полезные инструменты, которые упрощают процесс работы и повышают качество поддержки. Впереди — ещё больше автоматизации: агенты, которые самостоятельно смогут собирать всю необходимую оператору информацию из разных источников, а также новые инструменты для поддержания и формирования качественной базы знаний.

Мы уверены, что всё это сделает работу поддержки удобнее, а опыт пользователей — приятнее и эффективнее.

Сейчас сервис находится в режиме Preview и доступен для тестирования по заявкам: отправить запрос на тест можно на сайте.