Подготовка данных — обязательное условие эффективности корпоративного RAG
Контекст в компании распределен. Один и тот же процесс или объект могут описывать несколько документов: приказ, регламент, инструкция, шаблон. Эти документы живут в разных системах (СЭД, файловых хранилищах, порталах, почте) и редко синхронизируются между собой, а версии и приоритеты почти невозможно контролировать вручную.
Когда RAG-система получает запрос, она ищет ответ по всем доступным внутренним источникам. И если в базе одновременно лежат действующая и устаревшая редакции регламента, два противоречащих друг другу положения или разные версии одного договора, система найдет оба варианта, но не будет знать, какой из них правильный.
Поэтому главным фактором точности ответа становится не мощность модели, а проблемы источников:
➖ Противоречивые версии. Когда в базе есть и актуальная, и устаревшая редакция документа, RAG не может определить, какая из них действующая;
➖ Смысловые конфликты между документами. Регламент и инструкция описывают одну процедуру по-разному, при этом каждый документ по отдельности выглядит корректно.
➖ Разорванные связи. Документ ссылается на приложение, которого нет в системе, или на редакцию, которая уже заменена, поэтому ответ строится на неполном контексте.
➖ Неоднозначные формулировки. Условие допускает несколько трактовок, и модель выбирает ту, которая статистически вероятнее, а не ту, которая юридически верна.
➖ Некачественные сканы и метаданные. OCR распознал текст с ошибками, атрибуты заполнены неверно или отсутствуют — в таком случае ответ опирается на искаженный источник.
Отдельная проблема — права доступа. Если RAG не наследует ролевую модель из источника, он может показать сотруднику документ, который ему не предназначен. Из-за чего вопрос переходит в плоскость безопасности.
Начинать нужно с источников, т.к. пока в документах есть противоречия и устаревшие версии поиск будет менее результативным. Пошаговый порядок действий мы подробно разбирали в посте про аудит данных.
RAG-система, построенная на непроверенных источниках — это не инструмент, а источник новых рисков. Сначала необходимо подготовить данные, а далее разрабатывать RAG. Без этого шага модель может ошибаться или предоставлять общие ответы на основе внутренних знаний.
Контекст в компании распределен. Один и тот же процесс или объект могут описывать несколько документов: приказ, регламент, инструкция, шаблон. Эти документы живут в разных системах (СЭД, файловых хранилищах, порталах, почте) и редко синхронизируются между собой, а версии и приоритеты почти невозможно контролировать вручную.
Когда RAG-система получает запрос, она ищет ответ по всем доступным внутренним источникам. И если в базе одновременно лежат действующая и устаревшая редакции регламента, два противоречащих друг другу положения или разные версии одного договора, система найдет оба варианта, но не будет знать, какой из них правильный.
Поэтому главным фактором точности ответа становится не мощность модели, а проблемы источников:
➖ Противоречивые версии. Когда в базе есть и актуальная, и устаревшая редакция документа, RAG не может определить, какая из них действующая;
➖ Смысловые конфликты между документами. Регламент и инструкция описывают одну процедуру по-разному, при этом каждый документ по отдельности выглядит корректно.
➖ Разорванные связи. Документ ссылается на приложение, которого нет в системе, или на редакцию, которая уже заменена, поэтому ответ строится на неполном контексте.
➖ Неоднозначные формулировки. Условие допускает несколько трактовок, и модель выбирает ту, которая статистически вероятнее, а не ту, которая юридически верна.
➖ Некачественные сканы и метаданные. OCR распознал текст с ошибками, атрибуты заполнены неверно или отсутствуют — в таком случае ответ опирается на искаженный источник.
Отдельная проблема — права доступа. Если RAG не наследует ролевую модель из источника, он может показать сотруднику документ, который ему не предназначен. Из-за чего вопрос переходит в плоскость безопасности.
Начинать нужно с источников, т.к. пока в документах есть противоречия и устаревшие версии поиск будет менее результативным. Пошаговый порядок действий мы подробно разбирали в посте про аудит данных.
RAG-система, построенная на непроверенных источниках — это не инструмент, а источник новых рисков. Сначала необходимо подготовить данные, а далее разрабатывать RAG. Без этого шага модель может ошибаться или предоставлять общие ответы на основе внутренних знаний.