Полевая карта RAG: от первых принципов до сбоев в производстве
Два канала обработки, три этапа и список именованных сбоев: как работает генерация с усилением на основе поиска, где возникают сбои, и какие решения устраняют каждую проблему.
Источники: The Complete RAG Roadmap: From “What Is It?” to Production
Метод генерации с усилением на основе поиска легко продемонстрировать, но трудно сделать правильно. Рабочий прототип можно создать за сорок строк и один день. Затем начинается долгий процесс выяснения причин, по которым система трижды из десяти дает неверные ответы или почему чат-бот уверенно цитирует положение контракта, которого никогда не существовало. Данный план охватывает оба аспекта: он начинается без малейшего использования жаргона и заканчивается техниками, которые отличают демо-версию, созданную на выходных, от системы, которой люди доверяют свои деньги.
Идея простыми словами
Представьте модель языка как хорошо образованного выпускника, который никогда не видел ваших файлов. Она ознакомлена с большей частью общедоступного Интернета, но не имеет никакой информации о ваших договорах аренды, правилах кадрового управления, каталоге продуктов или презентациях совета директоров за прошлый квартал.
RAG превращает экзамен с закрытыми учебниками в экзамен с открытыми учебниками. Вместо того чтобы полагаться на то, что модель запомнила ваши данные, система сначала находит соответствующие страницы, передаёт их модели и указывает ей отвечать исключительно на их основе. Название описывает три этапа:
- Поиск: поиск в ваших документах и извлечение нескольких важных фрагментов.
- Дополнение: включение этих фрагментов в запрос рядом с вопросом.
- Генерация: заставление модели написать ответ, основанный на полученных данных.
В этом и заключается вся суть. Все последующие усовершенствования, от инструментов переранжирования до графов, существуют лишь для того, чтобы сделать хотя бы один из этих трёх этапов менее неэффективным.
Для читателей, не имеющих технического опыта, преимущество заключается в возможности объяснить, что создаёт инженерная команда, почему что-то не работает так, как это происходит, и какие вопросы стоит задавать во время демонстрации у поставщика. Для инженеров же важны механизмы работы, компромиссы и способы сбоев, что подразумевает необходимость понимания, почему косинусное сходство является странным критерием релевантности, почему блоки по 512 токенов портят структуру данных и почему набор для оценки имеет большее значение, чем выбор модели. Никто не считает ответ «просто используйте векторную базу данных» полным решением.
Два потока обработки, а не один
Почти всех сбивает с толку структурный аспект: система RAG — это не один поток обработки. Это два потока, которые никогда не работают одновременно.
Канал A занимается индексацией. Эта процедура выполняется заранее, обычно в виде пакетной задачи. Документы разделяются на части, каждая из которых преобразуется в список чисел, отражающих её смысл, а эти числа помещаются в поисковый индекс. Это менее интересный этап, но именно на нём определяется примерно 80% качества окончательного ответа.
Канал B занимается поиском. Он работает в реальном времени каждый раз, когда пользователь задаёт вопрос. Вопрос преобразуется в числа точно таким же способом, находятся наиболее близкие сохранённые части, они помещаются в запрос, и возвращается ответ.
Если два подхода расходятся в вопросах кодирования, ничего не работает — это похоже на то, когда документы сортируются по алфавиту, а затем ищутся по цвету. Люди склонны сосредотачиваться на подходе B, то есть на вводных данных, самой модели и параметре температуры, в то время как большинство проблем кроется в подходе A. Индексация выполняется один раз, запросы — каждый раз, и большинство ошибок скрывается в промежутке между ними.
Этапы, от основ до производства
Основы
Первая тема касается того, откуда на самом деле берутся галлюцинации, причем дело не в том, что модель глупа. Связанные с этим вопросы включают понятие окна контекста, причины, по которым всю базу данных нельзя просто вставить в него, и значение понятия «порог знаний». Затем есть вопрос, в котором люди ошибаются: RAG, финтунинг и более большое окно контекста — это три отдельных инструмента для решения трех разных проблем, однако их постоянно рекомендуют для решения задач друг друга.
Страховая компания, у которой формулировки полисов меняются каждый квартал, наглядно демонстрирует эту разницу. Для точной настройки потребуется переобучение каждый квартал, тогда как с использованием RAG достаточно обновлять папку с данными.
Получение и разбиение на части
Само ввод данных представляет собой отдельную сложность: PDF-файлы, на самом деле являющиеся отсканированными изображениями, таблицы, заголовки, подзаголовки и 40-страничное приложение, которое никому не нужно. Затем следует разбиение документа на части — принятие решения о том, как его разделить. Это кажется простым, но на деле таковым не является. Если части слишком маленькие, в них может оказаться только фраза «депозит подлежит возврату» без указания условий. Если части слишком большие, модель тонет в шуме. Основными методами являются разбиение фиксированного размера, с учетом структуры предложений и рекурсивное разделение, плюс метод с перекрытием, предотвращающий прерывание предложений.
Возьмем 60-страничный договор аренды, в котором условия штрафов зависят от определения, приведенного на 40-й странице. Границы частей определяют, сохранится ли это соответствие между страницами.
Эмбеддинги и векторный поиск
На этом этапе кажется, что происходит магия, но это не так. Текст преобразуется в список чисел, упорядоченный таким образом, что фраза об отмене заказа оказывается рядом с фразой об возврате покупки и далеко от фразы об заказе дополнительных товаров. К связанным понятиям относятся размерности, косинусное сходство, а также тот факт, что близость в векторном пространстве не гарантирует наличия ответа.
Далее идет вопрос хранения: что на самом деле делает векторная база данных, почему метод жесткого поиска теряет эффективность при больших объемах данных и что приближенный поиск ближайшего соседа жертвует ради скорости.
Цикл поиска
Здесь происходит сбор элементов. Выбор параметра top-k, определяющего количество получаемых фрагментов, является частью этого процесса, и большее количество не всегда лучше. Фильтрация метаданных позволяет ограничить поиск лишь документами 2024 года или только регионом Мумбаи. Важна также структуризация запроса, поскольку способ и порядок расположения полученного контекста влияют на ответ.
Затем следуют обоснования и цитаты. Модель должна указывать на конкретный раздел, например 4.2, а не просто выражать уверенность в своих ответах. Не менее важно, чтобы она указывала, что ответа в документах нет, что, вероятно, является наименее оцененной особенностью любой системы RAG.
Оценка
Почти все пропускают этот этап, что объясняет, почему практически все выпускают неисправные RAG. Проблему, которую невозможно измерить, нельзя исправить. Качество определяется двумя вопросами: был ли получен правильный материал и оставался ли модель верной ему? Каждый из этих аспектов сам по себе является проблемой, требующей отдельного решения. В набор инструментов входит набор «золотых» тестовых вопросов от реальных пользователей, оценка поиска по точности и полноте, оценка генерации по степени верности и релевантности к вопросу, а также ИИ-модель в роли судьи, отслеживающая моменты, когда подход дает сбои.
Одна система показала 90% по точности поиска и 55% по степени верности ответов. Поиск у неё работал нормально, но ответы всё равно были неверными.
Обновления, каждое из которых связано с сбоем
Лучший поиск
Гибридный поиск сочетает поиск на основе смысла с традиционным совпадением по ключевым словам, поскольку методы эмбеддингов плохо справляются с точными идентификаторами, такими как номера моделей и идентификаторы счетов-фактур. Метод переранжирования дешево получает 50 кандидатов, после чего более медленная, но более умная модель выбирает лучшие 5 вариантов. Преобразование запроса преобразует нечеткый вопрос в поисковый, разделяет сложный вопрос на части или использует метод HyDE, который генерирует фиктивный идеальный ответ и ищет с его помощью вместо самого вопроса.
Запрос о сравнении двух проектов в Бангалоре по дате получения и цене представляет собой один вопрос, требующий трех отдельных поисков.
Лучшая индексация
Для правильной обработки полосы A используется несколько техник. Поиск в стиле «родитель-дочерний» производится над небольшими, точными фрагментами, но в модель поступает более крупный участок вокруг них. Семантическое разделение на фрагменты осуществляется в местах смены темы, а не по произвольному количеству символов. Резюме и иерархические индексы сначала ищут краткое содержание документа, а затем углубляются в детали. Графовый RAG хранит связи между сущностями, а не только текст, поэтому может отвечать на вопросы вроде «какие поставщики также являются клиентами».
Хорошим примером является запрос, связанный с соблюдением норм: для получения ответа требуются правило, его поправка за 2023 год и примечание об исключении — три документа для одного ответа.
Поведение агента
После этого этапа RAG больше не является фиксированной процедурой и начинает принимать решения. Механизм маршрутизации направляет вопрос в соответствующий индекс, в SQL-базу данных или вообще не осуществляет поиск. Многократный поиск позволяет сначала получить информацию, затем обнаружить пробелы и снова выполнить запрос. Технологии Self-RAG и Corrective RAG позволяют системе оценить качество полученного контекста и отбросить его, если он нерелевантен, после чего обратиться к поиску в Интернете или честно признать отсутствие ответа.
Возьмём вопрос о причинах отклонения заявки. Чтобы на него ответить, необходимо поочерёдно получить информацию из правил, файла заявки и кода отклонения.
Загромождённые документы
Настоящие профессиональные знания в бизнесе редко представлены в виде аккуратных абзацев. Они поступают в виде таблиц, сканов, планов помещений, скриншотов и диаграмм. Среди необходимых навыков — анализ структуры документа, извлечение таблиц, включая сведения из объединенных ячеек, обработка изображений, а также поиск информации в документах, где ответ содержится в графике. Типичным примером является вопрос о ценообразовании, номер к которому имеется только в отсканированном списке тарифов.
Производственные аспекты
После демонстрации всё ломается. Показатели задержек показывают, куда уходят миллисекунды. Важна стоимость за запрос, а также кэширование, которое действительно помогает. Индекс должен оставаться актуальным, когда документы меняются каждый час. Система контроля доступа должна гарантировать, что пользователь А не сможет получить данные пользователя Б — это распространённая и реальная проблема утечки информации. Отравленные документы могут вводить вводные данные. Мониторинг и логирование позволяют выявить моменты тихого снижения качества. Система, которая работала отлично с 200 документами, может сломаться при обработке 200 000 документов.
Сначала изучите причины сбоев
Если нужно запомнить одну вещь, пусть это будет следующее: продвинутый RAG — это не более сложная версия базового RAG. Это набор патчей, каждый из которых предназначен для конкретной проблемы с определённым названием. Как только причина сбоя понята, следующим логичным шагом становится использование метода сопоставления.
Три принципа обеспечивают честность подхода:
- Никакого культа фреймворков. Концепции важнее инструментов, и любой, кто понимает принципы разбиения задач на части, может применить их где угодно.
- Никакого непонятного кода, скопированного без объяснений. Код показывается только после того, как становится ясно причина его такого вида.
- Никаких притворств, что всё всегда работает. В некоторых случаях RAG оказывается неподходящим решением, и проще подходы оказываются лучше.
Новичкам следует изучать темы в порядке, поскольку каждая из них основана на предыдущей. Те, у кого уже есть система, которая не соответствует ожиданиям, могут сразу перейти к этапу оценки.
Связанная литература
- Практические рекомендации: переход RAG в производство: проблемы на всех этапах на основе реальных кейсов — Подробное руководство по практическим рекомендациям: переход RAG в производство: проблемы на всех этапах на основе реальных кейсов: контракты, проверки и готовые блоки кода для команд, внедряющих эту архитектуру.
- Гибридный поиск в Postgres для помощника в сфере здравоохранения: схема, разбиение на части, RRF и методы оценки — Создание слоя поиска для помощника в сфере здравоохранения в Postgres: разбиение данных с учётом структуры, гибридный поиск с использованием pgvector и алгоритма RRF, двоичная квантизация, пороговые значения и методы оценки.