Аннотация: Мы обсуждаем, почему вопросы и ответы по корпоративным RAG-файлам не только оптимизируют эффект ответа, но и создают отслеживаемую цепочку доказательств, начиная с анализа документов, их фрагментирования, поиска, цитирования и заканчивая ручным просмотром. Ключевые слова: RAG, вопросы и ответы по документам, корпоративная база знаний, векторный поиск, цитирование ИИ, цепочка доказательств. Легко создать демонстрируемый прототип, загрузив PDF-файл в большую модель и спросив: «Каковы требования?» Как только вы действительно вникаете в бизнес-процесс, вопросы сразу же меняются на другой набор вопросов: с какой страницы приходит ответ? Вы цитируете оригинальный текст или аннотацию? Что происходит со старыми ответами после обновления файла? Будете ли вы продолжать делать, казалось бы, разумные выводы, когда модель не будет найдена? Это также наиболее распространенная поломка, когда проект RAG переходит от демо-версии к производству...
Аннотация: Мы обсуждаем, почему вопросы и ответы по корпоративным RAG-файлам не только оптимизируют эффект ответа, но и создают отслеживаемую цепочку доказательств, начиная с анализа документов, их фрагментирования, поиска, цитирования и заканчивая ручным просмотром.
Ключевые слова: RAG, вопросы и ответы по документам, корпоративная база знаний, векторный поиск, цитирование ИИ, цепочка доказательств.
Легко создать демонстрируемый прототип, загрузив PDF-файл в большую модель и спросив: «Каковы требования?» Как только вы действительно вникаете в бизнес-процесс, вопросы сразу же меняются на другой набор вопросов: с какой страницы приходит ответ? Вы цитируете оригинальный текст или аннотацию? Что происходит со старыми ответами после обновления файла? Будете ли вы продолжать делать, казалось бы, разумные выводы, когда модель не будет найдена?
Это также наиболее распространенный переломный момент, когда проект RAG переходит от демо-версии к производству. Пользователям нужны не просто ответы, а цепочка доказательств, чтобы иметь возможность перепроверить ответы.
Рисунок 1. Статус данных и статус утверждения отображаются отдельно. Скриншот взят из реального бизнес-интерфейса Biomai Cloud.
Прежде чем документ попадет в индекс, необходимо решить проблемы с идентификацией.
Корпоративные документы часто существуют в нескольких версиях: первый черновик, версия с печатью, дополнительное пояснение, сканированная копия и версия, составленная внутри компании. Если система использует в качестве идентификаторов только имена файлов, перезапись одинаковыми именами и смешивание версий практически неизбежны.
Для каждого документа требуются как минимум следующие метаданные:
Стабильный идентификатор документа и номер версии;
Хэш файла, время загрузки и загрузчик;
Тип документа и право собственности на бизнес;
Статус парсера и версия парсера;
Объем полномочий и статус одобрения;
Будет ли она заменена новой версией.
«Загружено» не равно «может использоваться ИИ». Материалы, которые не удалось разобрать, имеют неподтвержденные разрешения или не были одобрены, должны оставаться за пределами индекса. Если сделать этот шаг явным, модель не сможет ссылаться на неполный или неавторизованный контент без ведома пользователя.
Цель разбиения на фрагменты — не иметь одинаковую длину.
Сегментация по фиксированному количеству символов является самой быстрой реализацией, но она несовместима с системами, контрактами и документами о закупках. Оговорочное предложение может охватывать абзацы, а заголовки таблиц и строки данных могут быть разделены.
Более надежные стратегии фрагментации часто сочетают в себе:
Структура документа: названия, главы, пункты, таблицы и номера страниц;
Семантические границы: избегайте обрезания в середине предложения или пункта;
Контекстное окно: сохранение небольшого перекрытия соседних блоков;
Координаты источника: номер страницы записи, положение абзаца или ячейки;
Информация о версии: каждый блок можно отследить до определенной версии документа.
Если исходный документ представляет собой скан, результаты достоверного распознавания текста и макета также должны быть включены в оценку качества. Некачественный текст не должен поступать в базу знаний молча, иначе какой бы мощной ни была последующая модель, она сможет ответить только на основе неверного ввода.
Результаты поиска должны быть проверены доказательствами
Высокое сходство векторов не означает достаточных доказательств. В одном фрагменте может говориться о «похожих проектах» без уточнения, является ли это обязательной квалификацией или оцениваемым элементом; другой фрагмент может быть из более старого издания, выпуск которого прекращен.
После извлечения можно добавить уровень проверки доказательств: проверку разрешений на документ, достоверности версии, типов сегментов, охвата ключевых слов и согласованности между сегментами. Для ключевых вопросов вы также можете одновременно запустить лексический поиск и векторный поиск, а затем объединить и переупорядочить результаты.
Вопрос
-> контроль доступа
-> лексический + семантический поиск
-> фильтрация версий
-> переоценка доказательств
-> обоснованный ответ
-> проверка цитирования
Если доказательств недостаточно, система должна четко выдать сообщение «В текущих данных не обнаружено достаточных оснований» и