Не внедряйте RAG, пока не сделали это

Это вторая глава из моей новой книги “Знания, поиск и RAG”, в которой я расскажу, как подготовить вашу документацию, чтобы от векторной базы данных была польза, а не вред. Я не планирую углубляться в технические детали, скорее всего, это будет в отдельной статье, когда я сам в них разберусь.

Нет никакого смысла врываться в историю RAG и LLM, если ваша документация плохо написана. Главная мысль всего текста: документация должна быть пригодна для чанкинга (то есть для скармливания по кусочкам в RAG). Если вы не знаете об этом слове из трёх букв вообще ничего, начните с этой статьи.

Итак, погнали, что же делает вашу документацию пригодной для внедрения в неё RAG.

Правильно расставленные заголовки и подзаголовки

Четкая организация контента с помощью заголовков и подзаголовков улучшает читаемость и помогает моделям RAG понимать структуру ваших документов. Хорошо подобранные заголовки помогают LLM держать контекст. Заголовок “Введение” — плохо, а “Как пропатчить KDE2 под FreeBSD” — хорошо.

Существуют две школы:

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

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

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

С умом используйте списки и таблицы

Классика документации, если у вас процесс состоит из нескольких последовательных шагов — используйте нумерованные списки. Если вдруг нужно разорвать список для какого-то примечания, то можно использовать фразы типа «После завершения второго шага выполните…», чтобы связать идеи и улучшить поток информации.

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

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

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

Меньше скриншотов больших и разных

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

Многомодальные LLM-модели могут обрабатывать как изображения, так и текст. То есть если вы не делаете RAG, а просто закидываете свой док со скриншотами в ChatGPT или Claude, то они смогут дать вам ответ, используя, в том числе, информацию со скриншотов. Но если мы скармливаем базу знаний в RAG, то туда попадает только текст статьи и ссылка на изображение.

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

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

Насыщение контекстом

Эту часть многие пропускают даже просто в документации. Написали заголовок “Создание учётки”, потом накидали каких-то букв во введение, и дальше пишут “Откройте страницу, нажмите сюда, выберите это”. Конечно, LLM всё равно поймёт, что всё это про создание учётки. Но результирующий вектор будет гораздо ближе к вопросу пользователя “как мне создать учётку?”, если статья будет называться “Как создать учётку”, а в тексте будет фраза “Чтобы создать учётку, откройте страницу…”.

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

Отдельно есть подход, который использую при самом формировании RAG, когда добавляют контекст из соседних абзацев, которые не попали в чанк, или пишут, где находится каждый кусок текста. В духе “этот текст из статьи про создание учеток пользователей в сервисе А”. Контекст + тест отдаются в RAG и семантическая связь получается ещё лучше. Но это уже другая история.

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

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

Типа заключение

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

• актуальность;
• активный залог;
• полнота;
• минимум воды (чтобы было больше воды на планете);
• иметь хорошую структуру статей или разделов;
• консистентность.

Если у вас хорошая база знаний, то переход к RAG будет намного более эффективным.

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