RAG для тех, кто разочаровался: почему retrieval ломается и как это починить

В сфере искусственного интеллекта произошло заметное событие. badcasedaily1 2 часа назад RAG для тех, кто разочаровался: почему retrieval ломается и как это починить Средний 7 мин 2. 3K Блог компании OTUS Программирование * Python * Машинное обучение * Искусственный интеллект Туториал Вы собрали RAG-пайплайн: загрузили документы, нарезали на чанки, сгенерировали эмбеддинги, подключили векторную базу. Задаёте вопрос — модель отвечает уверенно и подробно.

Показываете заказчику, тот в восторге. Потом начинается тестирование на реальных вопросах, и оказывается, что на половину из них система отвечает мимо: то находит не тот документ, то находит правильный, но не тот кусок, то вообще ничего релевантного не достаёт и модель уверенно галлюцинирует. Каждый раз проблема не в модели (GPT-4 и Claude отвечают хорошо, если им дать правильный контекст), а в retrieval — в том, как мы ищем релевантные куски документов.

Технические детали

Модель отвечает ровно настолько хорошо, насколько хорош контекст, который ей подсунули. Рассмотрим три основные причины. Проблема 1: чанки нарезаны бездумноСтандартный подход — нарезать документ на куски по 500-1000 символов с перекрытием.

Представьте договор на 30 страниц. 3 про ответственность начинается на одной странице и заканчивается на другой. При нарезке по 500 символов пункт разрезается пополам: первая половина в одном чанке, вторая в другом.

Пользователь спрашивает «какая ответственность по договору», retrieval находит первую половину (там есть слово «ответственность»), но не находит вторую (там уже про суммы и сроки). Модель отвечает неполно, а пользователь думает, что система не работает. Другой пример: таблица с тарифами.

Отраслевые последствия

При нарезке по символам заголовок таблицы попадает в один чанк, а данные в другой. Чанк с данными без заголовка бессмысленен: числа без контекста. Первое, что стоит сделать — перейти от «нарезки по символам» к «нарезке по смыслу»:from langchain.

text_splitter import RecursiveCharacterTextSplitter # Стандартный подход — работает, но грубо basic_splitter = RecursiveCharacterTextSplitter( chunk_size=1000, chunk_overlap=200, ) # Лучше: разделители по приоритету # Сначала пробуем разрезать по двойному переносу строки (между параграфами), # потом по одинарному, потом по предложению, потом по символам smart_splitter = RecursiveCharacterTextSplitter( chunk_size=1000, chunk_overlap=200, separators=, )RecursiveCharacterTextSplitter пробует разделители по порядку: сначала ищет двойной перенос (граница параграфа), если чанк получается слишком большой — ищет одинарный перенос, потом точку с пробелом (конец предложения). Идея в том, чтобы разрезать в естественных точках текста, а не посередине слова. Но для структурированных документов (договоры, регламенты, технические спецификации) этого мало.

Лучше нарезать по структуре документа: каждый раздел или пункт — отдельный чанк. import re def split_by_sections(text: str, max_chunk_size: int = 2000) -> list: """Нарезка по заголовкам разделов (markdown-стиль). split(r'\n(#{1,3}\s+.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.