Чек-лист: готовы ли ваши данные к RAG
Пятнадцать проверок, которые мы прогоняем до того, как согласиться делать поиск по документам. Отвечаете на них за час своими силами — и понимаете, получится ли у вас разумный ответ по вашему корпусу или сначала нужно привести данные в порядок. Полный список на этой странице, PDF — без регистрации.
- Пятнадцать проверок в четырёх группах: корпус, структура, права, проверяемость.
- У каждой — объяснение, что сломается, если ответ «нет».
- В конце — как читать результат и с чего начинать при каждом раскладе.
Корпус: что вообще есть
- 01
Вы можете назвать точное место, где лежат документы, по которым нужны ответы.
«Где-то на диске и в почте у Марины» — это не корпус. Пока источник не назван одним адресом, объём работы нельзя оценить даже в порядке величины.
- 02
Вы знаете, сколько их: сотни, тысячи или десятки тысяч.
От порядка величины зависит всё: на сотне документов работает почти любой подход, на десятках тысяч начинают решать нарезка и стратегия поиска.
- 03
Известно, какая доля — сканы и фотографии, а не текст.
Скан — это отдельный этап распознавания со своей стоимостью и своим процентом ошибок. Если про него узнают в середине проекта, срок сдвигается всегда.
- 04
Вы можете сказать, какая версия документа действующая.
Система найдёт и процитирует обе редакции с одинаковой уверенностью. Отличить действующую от отменённой она может только по признаку, который есть в данных.
Структура: как документ устроен
- 05
В документах есть заголовки разделов, а не сплошной текст.
Заголовки — самая дешёвая граница для нарезки. Без них приходится резать по длине, и половина ответов будет обрываться на середине мысли.
- 06
Вы знаете, есть ли в документах таблицы и насколько они важны для ответов.
Таблица, разрезанная пополам, даёт уверенно неверный ответ: строка есть, а заголовок столбца остался в другом куске. Таблицы обрабатывают отдельно или не обрабатывают вовсе.
- 07
Понятно, есть ли перекрёстные ссылки между документами.
«В порядке, установленном приложением 3» — без приложения 3 ответ будет формально верным и практически бесполезным.
- 08
Дубли и почти-дубли известны хотя бы приблизительно.
Пять версий одного регламента вытесняют из выдачи всё остальное: поиск считает их пятью независимыми подтверждениями одного и того же.
Права: кто что видит
- 09
Вы знаете, все ли документы можно показывать всем сотрудникам.
Если нет — права нужно закладывать в поиск с первого дня. Достроить их поверх готовой системы значит переделать индекс.
- 10
Известно, есть ли в корпусе персональные данные.
Это решает, где вообще может обрабатываться корпус, какую модель можно взять и что должно остаться в вашем контуре. Вопрос архитектурный, а не юридический.
- 11
Есть человек, который отвечает за содержание документов.
Когда система процитирует документ и окажется неправа, спорить будут о содержании, а не о технике. Без владельца контента спор упирается в разработчика, и это тупик.
- 12
Понятно, как часто документы меняются: раз в год, раз в месяц или ежедневно.
От этого зависит, нужен ли инкрементальный доиндекс и наблюдение за свежестью, или достаточно перестраивать индекс вручную по расписанию.
Проверяемость: как узнать, что получилось
- 13
Вы можете записать двадцать реальных вопросов, которые задают люди.
Не выдуманных, а тех, что приходили в поддержку или звучали на встречах. Это и есть техническое задание: без них качество нечем измерить, и спор о нём становится вкусовым.
- 14
Для каждого вопроса известен документ, в котором лежит правильный ответ.
Это превращает «нравится или нет» в измеримое: нашла ли система нужный документ и процитировала ли именно его. Такой набор собирается за день и работает годами.
- 15
Есть договорённость, что считается приемлемым ответом.
«Точно и полно» — не критерий. Критерий звучит так: правильный документ в первых трёх результатах, ответ со ссылкой на источник, честное «не нашёл» вместо выдумки.
Двенадцать и больше «да»
Данные готовы. Разумно начинать с пилота на одном разделе корпуса и набора из двадцати вопросов: за две-три недели видно, попадает ли поиск, и стоит ли расширяться.
От семи до одиннадцати
Обычный расклад для живой компании. Начинать можно, но с той части корпуса, где ответов больше всего «да». Параллельно закрывайте пробелы в правах и версионности — они дороже всего обходятся потом.
Меньше семи
RAG сейчас даст красивое демо и неработающую систему. Дешевле потратить две-три недели на порядок в документах: назначить владельца, развести версии, выделить действующие редакции. Это работа не про AI, и без неё любой подрядчик получит тот же результат.
Прошли чек-лист — пришлём разбор по вашему случаю
Напишите, что получилось: сколько документов, какие ответы «нет» и какие вопросы должны закрываться. Ответим разбором по вашему корпусу — что делать в первую очередь и нужен ли вам вообще RAG. Это не коммерческое предложение, а разбор; если задача решается проще, так и скажем.
Что такое готовность данных к RAG?
Это набор свойств корпуса, при которых поиск по документам может дать проверяемый ответ: источник известен и один, структура позволяет резать документы осмысленно, права описаны, действующие редакции отличимы от отменённых, и есть набор вопросов с известными правильными ответами. Модель на это не влияет — она работает с тем, что нашли.
Нужно ли отдавать почту, чтобы скачать чек-лист?
Нет. Файл скачивается по кнопке, форма ничего не требует. Весь список к тому же напечатан прямо на этой странице — PDF нужен только чтобы взять его на встречу.
Сколько времени занимает пройти чек-лист?
Около часа, если рядом человек, который знает, где лежат документы, и человек, который отвечает за их содержание. Дольше всего обычно обсуждают версионность и права: как раз те два пункта, которые потом дороже всего исправлять.
Мы не прошли чек-лист. Что делать?
Это нормальный и полезный результат: он экономит бюджет пилота, который всё равно бы не взлетел. Порядок действий один — выбрать один раздел корпуса, навести в нём порядок и запустить пилот на нём. Расширяться проще из работающей маленькой системы, чем из большой неработающей.
RAG и база знаний
Что мы делаем, когда данные готовы.
Что такое RAG и когда он нужен бизнесу
RAG — это ответы модели по вашим документам, а не по интернету, с видимым источником под каждым утверждением. Разбираем, из чего он состоит, где теряется качество на нарезке и обновлении, как считать, что он работает, и когда он не нужен.
Нарезка документов для RAG: почему чанки важнее модели
Плохой ответ RAG-системы почти всегда родом не из модели, а из нарезки. Разбираем, как резать регламенты, договоры, PDF-сканы и тикеты поддержки, что ломается на корпусе из десятков тысяч длинных документов и как понять, что виновата именно нарезка.
Как обновлять базу знаний RAG, не останавливая систему
Демо живёт на статичном корпусе, продакшн — на меняющемся. Разбираем инкрементальное обновление вместо полной переиндексации, подмену индекса без рестарта, удаление документов и то, какие метрики показывают деградацию поиска раньше, чем о ней сообщат пользователи.