RAG с нуля: как на самом деле работает генерация с усилением с помощью поиска.
Обзор концепции генерации с усилением с помощью поиска с нуля: почему она существует, как она сравнивается с тонкой настройкой, её развитие, оффлайн- и онлайн-процессы, а также возможные сбои.
Источники: Retrieval-Augmented Generation (RAG) from First Principles: How RAG Works and Why It Matters
Большие языковые модели кажутся ответом на вопрос, который ставит каждая крупная организация: как нам получить доступ к информации, содержащейся в наших собственных документах? Банк хочет ассистента, который может объяснить правила борьбы с отмыванием денег и проверки клиентов. Страховая компания нуждается в программном обеспечении, способном читать тексты полисов. Обслуживающий персонал авиакомпании хотел бы находить информацию в тысячах руководств за секунды. Юристы ожидают инструментов для анализа контрактов, а службы поддержки хотят получать ответы, основанные на внутренней документации, а не на догадках.
Проблема в том, что языковые модели никогда не создавались как живые хранилища корпоративных знаний. То, что они знают, было закодировано в их параметрах во время обучения, поэтому это знание зафиксировано, его трудно изменить, и оно не связано с какой-либо конфиденциальной информацией. Регулирования меняются, политики переиздаются, контракты изменяются, и каждый день появляются новые файлы, поэтому разрыв между тем, что знает модель, и тем, что знает организация, постоянно увеличивается. В результате получается программное обеспечение, которое звучит уверенно и свободно, но при этом ошибается или просто не осведомлено о последней версии правила.
Метод генерации с использованием дополнительных данных, обычно сокращаемый как RAG, стал решением проблемы. Вместо того чтобы ожидать, что модель запомнит каждый документ, система извлекает соответствующий материал из надежных источников в момент поступления вопроса и использует его для составления ответа, основанного на конкретном контексте и имеющего возможность отслеживания. Это небольшое изменение в архитектуре изменило способ создания ИИ-продуктов компаниями, поскольку оно сочетает способность современных моделей к логическим рассуждениям с свежестью, возможностью отслеживания и контролем, которые требуются для корпоративных знаний.
Большинство объяснений останавливаются на этом этапе. Типичный учебник рассматривает концепцию эмбеддингов, векторные базы данных и поиск по сходству, приводит схематическое изображение, где документы поступают в индекс, а затем в модель, и считает, что всё сделано. Этого достаточно для прототипа. Однако остаются без внимания инженерные решения, определяющие, сможет ли система функционировать в реальных условиях: неупорядоченные документы, постоянно меняющиеся знания, случаи невозможности поиска, способ формирования контекста, контроль доступа, оценка эффективности, мониторинг, задержки и затраты. Чтобы справиться с этими проблемами, необходима полная архитектурная картина, а не лишь несколько компонентов.
Далее приведена та самая схема, созданная на основе первоначальных принципов без использования кода. В ней объясняется, почему возникла необходимость в технологии RAG, какие проблемы она решает, в чем отличие от тонкой настройки и использования подсказок, как этот подход развивался от примитивных механизмов поиска информации до агентных систем, почему разделение на офлайн- и онлайн-процессы влияет на каждую реализацию, как один вопрос проходит через всю систему, где находятся слабые места и когда прощее инструмент является лучшим выбором.
Зачем вообще существует поиск информации
Языковые модели — один из самых впечатляющих достижений в области искусственного интеллекта. Они способны рассуждать, делать краткие выводы, переводить, писать рабочий код и объяснять сложные научные концепции. Они могут отвечать на вопросы в тысячах областей и помогать с задачами, которые раньше требовали участия специалиста.
Тем не менее модель не является базой данных фактов. Люди забывают об этом, и именно эта ошибка лежит в основе многих неудачных проектов в области ИИ в корпорациях. Модель генерирует текст на основе статистических закономерностей, усвоенных во время обучения. Она не обращается к источнику истинной информации, который кто-то постоянно обновляет. Вся информация, которой она обладает, распределена между миллиардами параметров, что делает её как обширной, так и жесткой в своих действиях. После завершения обучения модель не осведомлена о новых правилах, измененных политиках, пересмотренных контрактах, новых исследованиях или документах частной компании, если только кто-то не предоставит ей эту информацию во время выполнения задач.
В неформальном общении такое ограничение ещё можно терпеть. Однако в деловой среде это быстро приводит к значительным затратам. Представьте банк, который назначает помощника сотрудникам по соблюдению правил для толкования политики по борьбе с отмыванием денег. Правила часто меняются, внутренние процедуры тоже изменяются, а регулирующие органы постоянно публикуют рекомендации. Модель, обученная несколько месяцев назад, может уверенно отвечать, опираясь на уже устаревшую версию политики, и банк остается под регуляторным риском. Авиационная промышленность сталкивается с той же проблемой: руководства по техническому обслуживанию пересматриваются после каждого бюллетеня, и инженеры всегда должны работать с самой последней утвержденной версией документа. То же самое касается здравоохранения, страхования, юридической деятельности и производства: знания постоянно обновляются.
Устаревшие ответы — это лишь одна из проблем. Корпоративные знания почти никогда не сосредоточены в одном месте. Они распространены по документам с правилами, контрактам, сайтам SharePoint, страницам Confluence, базам знаний, реляционным базам данных, инструментам для обработки заявок, электронной почте, PDF-файлам, таблицах и внутренним порталам. Даже модель с безупречным процессом рассуждений не сможет ответить на вопрос о материале, которого она никогда не видела или к которому не может получить доступ в момент поступления запроса.
Объяснимость — это вторая, не менее важная проблема. Профессионалы редко соглашаются с простым ответом. Специалист по соблюдению нормативов, проверяющий решение о приеме на работу, хочет знать, какое положение правил его обосновывает. Юридический аналитик ожидает соответствующие пункты контракта. Инженер по техническому обслуживанию нуждается в точном разделе руководства, который оправдывает конкретный шаг ремонта. В таких ситуациях одного лишь правильного ответа недостаточно, поскольку система должна показать, откуда взят ответ.
Обычные модели сталкиваются с этой проблемой, поскольку они формируют ответы на основе параметрической памяти, а не на основе проверяемых фактов. Даже правильный ответ невозможно надёжно отличить от правдоподобного предположения, выдуманного моделью. Именно поэтому галлюцинации остаются серьёзным препятствием в корпоративных ИИ-решениях.
RAG предлагает практический способ преодоления этих ограничений. Он разделяет процесс рассуждений и доступ к знаниям. Модель сосредотачивается на понимании желаний пользователя, объединении информации и формировании текста на естественном языке, в то время как отдельная система поиска находит наиболее релевантные и актуальные материалы из надежных источников при поступлении запроса. Вместо того чтобы каждый раз переобучать все более крупные модели при изменении фактов, организация просто редактирует свой хранилище знаний, не вмешиваясь в модель. Модель выполняет функцию механизма рассуждений, а база знаний становится источником достоверных фактов. Именно такое разделение труда является основной идеей этого подхода и причиной того, почему он стал стандартной архитектурой для корпоративного ИИ.
Что на самом деле такое RAG
RAG — это не модель. Это также не фреймворк, векторная база данных или алгоритм поиска. Это архитектурный паттерн, позволяющий языковой модели обращаться к внешним источникам знаний сразу по поступлению вопроса. Принцип кажется на первый взгляд простым: разделять хранение знаний и генерацию текста, чтобы модели не приходилось хранить каждый факт в своих весах.
Представьте опытного консультанта, работающего над сложным проектом. Многолетний опыт не означает возможности отвечать клиенту исключительно на основе памяти. Прежде чем ответить, консультант изучает самые свежие документы с политиками, технические спецификации, руководящие принципы и предыдущие отчеты по проекту. Экспертиза обеспечивает понимание и синтез информации, а содержание ответа берется из актуальных и авторитетных документов.
Система RAG в производственных целях работает аналогичным образом. Когда поступает вопрос, он не направляется сразу в модель. Система сначала ищет во внешнем хранилище документы, отрывки или записи, связанные с вопросом. Полученные результаты затем передаются в модель в качестве дополнительного контекста, благодаря чему ответ основывается как на заранее обученных знаниях модели, так и на самой свежей корпоративной информации, доступной в данный момент.
Роль модели меняется: она перестаёт быть хранилищем знаний и становится механизмом для рассуждений и формирования текста. База знаний компании является источником достоверных фактов, а слой поиска выполняет функцию моста между вопросом и этими знаниями. Вместе они позволяют получать ответы, которые более точны, актуальны и легче отслеживаемы, чем те, которые могли бы сгенерировать отдельно слой поиска или языковая модель.
Существует несколько преимуществ. Знания можно обновлять без повторной подготовки. Внутренние документы остаются вне параметров модели, что упрощает управление и контроль доступа. Ответы могут сопровождаться подтверждающими доказательствами, что способствует прозрачности и доверию. Кроме того, организации могут создавать системы, которые развиваются вместе с их знаниями, вместо того чтобы ждать выхода новой версии модели.
Было бы ошибкой отождествлять RAG с векторным поиском, за которым следует один вызов модели. Реальная реализация обычно включает в себя загрузку документов, парсинг содержимого, извлечение метаданных, разбиение на части, генерацию векторных представлений, индексацию, понимание запроса, поиск информации, переурочение рангов, сбор контекста, формирование инструкции для модели, генерацию ответа, оценку качества, мониторинг и постоянное совершенствование. Поиск является лишь одной частью гораздо более сложной структуры.
Целесообразно рассматривать RAG как инженерную систему, а не просто технику. Каждый этап влияет на итоговый ответ. Небрежная обработка данных приводит к пробелам в знаниях. Некачественное разделение данных на части снижает эффективность поиска. Слабый поиск ограничивает объем контекста, доступного модели. Даже самая совершенная модель не может дать точный ответ, если отсутствуют или неверны вспомогательные данные. Именно поэтому успешные корпоративные системы редко отличаются только моделью, а чаще — тщательной проработкой всех аспектов, связанных с ней.
Проблемы, которые решает RAG
Инженерные решения появляются из-за конкретных проблем, и RAG не является исключением. Он был создан не для того, чтобы сделать модели «умнее». Его придумали для преодоления ограничений, которые возникают сразу после внедрения моделей в производство, причем каждый выбор в конструкции системы RAG связан с одним из этих ограничений.
Замороженные знания и даты окончания обучения
Модель знает только то, что она выучила во время обучения. Как только это завершается, её знания становятся неизменными до тех пор, пока кто-то не проведёт повторное обучение или не заменит её. Для общих знаний это может быть приемлемо. Однако корпоративные знания постоянно меняются. Банки публикуют новые правила соответствия, регуляторы издают обновлённые рекомендации, документация к программному обеспечению меняется с каждым выпуском, а процедуры технического обслуживания в авиации изменяются с появлением информационных бюллетеней. Информация существует гораздо короче, чем модель.
Повторное обучение фундаментальной модели каждый раз, когда меняются корпоративные знания, не является ни практичным, ни доступным с экономической точки зрения. Это стоит дорого, занимает много времени и сопряжено с операционными сложностями. Технология RAG разделяет модель и знания. Вместо того чтобы вводить новые факты в модель через обучение, организации обновляют хранилище данных, а слой поиска обеспечивает, чтобы модель видела самую свежую информацию каждый раз, когда поступает вопрос.
Галлюцинации, возникающие в результате работы параметрической памяти
Модели генерируют наиболее вероятное продолжение текста на основе шаблонов, которые они усвоили. Они не проверяют факты перед тем, как что-либо сказать. Сталкиваясь с неполной, неоднозначной или незнакомой информацией, модель всё равно может дать плавный и убедительный ответ, что и называется галлюцинацией.
В компании галлюцинация — это не просто неверный ответ. Она может привести к нарушениям регуляторных норм, операционным ошибкам, финансовым потерям или рискам для безопасности. Представьте себе помощника по соблюдению нормативов, который выдумывает несуществующее правило, или инструмент поддержки в авиационной отрасли, который рекомендует процедуру ремонта, отсутствующую в утверждённом руководстве. Оба ответа могут казаться правдоподобными, но при этом быть ложными.
RAG снижает риски, основывая ответы на извлеченных доказательствах. Модель формирует ответы на основе релевантных материалов из надежных источников, а не исключительно из памяти. Она не может полностью исключить галлюцинации, но при высоком качестве извлечения информации ответы, не имеющие подтверждения, становятся гораздо менее вероятными.
Отсутствие возможности цитировать источники
Профессионалы редко принимают ответ без каких-либо обоснований. Адвокат ожидает ссылки на конкретные положения. Специалист по соблюдению норм требует нормативных документов, подтверждающих рекомендации. Врач хочет получить ссылки на клинические рекомендации, а инженер-авиаконструктор ожидает соответствующий раздел в руководстве перед началом ремонта.
Стандартные модели не могут обеспечить такой уровень отслеживаемости, поскольку их знания распределены между миллиардами параметров, а не хранятся в виде идентифицируемых документов. Технология RAG вносит явные доказательства в процесс генерации. Поскольку документы, полученные для анализа, известны ещё до написания ответа, система может цитировать те документы, разделы или фрагменты, которые были использованы. Это способствует прозрачности, возможности аудита и доверию пользователей.
Знания, находящиеся вне модели
Большая часть корпоративных знаний является конфиденциальной. Они хранятся в политиках, контрактах, технических руководствах, библиотеках SharePoint, страницах Confluence, системах управления задачами, базах данных и внутренних порталах, и ни один из этих источников недоступен моделям, обученным на публичных данных. Даже если технически возможно было бы включить всё это в процесс обучения, всё равно возникли бы проблемы с безопасностью, конфиденциальностью, управлением, контролем версий и обновлениями.
RAG позволяет организациям хранить знания в контролируемых хранилищах и предоставлять модели доступ только к той информации, которая необходима для ответа на конкретный вопрос. Знания остаются под управлением корпоративных правил, а модель принимает решения на основе предоставленного ей контекста.
Цена рассмотрения каждой изменения как проблемы для модели
Без RAG команды сталкиваются с ложным выбором: либо мириться с устаревшими ответами статической модели, либо переобучать её каждый раз, когда меняются знания. Ни один из вариантов не является эффективным. Корпоративные знания меняются ежедневно, а иногда даже ежечасно. Изменяются правила, обновляется документация к продукту, переписываются статьи с поддержкой и изменяются контракты. Рассматривать каждое обновление как проект машинного обучения невозможно.
RAG меняет модель технического обслуживания. Вы обновляете хранилище данных, не трогая саму модель. Как только новые документы индексируются, их можно сразу получить. Операционная сложность резко снижается, и система постоянно отражает актуальные знания.
Доступ к знаниям, а не новая интеллектуальность
Распространено заблуждение, согласно которому RAG делает модель умнее. Это не так. Способность модели к логическим рассуждениям остается практически прежней. Улучшается лишь качество информации, доступной перед тем, как она формирует ответ.
Вновь обратимся к консультанту. Экспертиза не развивается за одну ночь перед встречей с клиентом, но доступ к последним отчетам, политикам, финансовой отчетности и проектным файлам позволяет консультанту давать более точные и обоснованные рекомендации. RAG предоставляет модели ту же преимущество: он улучшает доступ к релевантным знаниям, не влияя на ее врожденные способы рассуждения. Именно поэтому качество поиска информации часто имеет большее значение для окончательного ответа, чем переход на более крупную и мощную модель.
RAG, тонкая настройка, инжиниринг промптов и обучение в контексте
Наиболее часто задаваемый вопрос — не «Что такое RAG?», а «Действительно ли нам нужен RAG?» И честный ответ часто бывает «нет». RAG — это один из нескольких способов улучшения поведения модели, и выбор неподходящего метода приводит к увеличению сложности, затрат и необходимости технического обслуживания при минимальной пользе. Все эти техники влияют на качество ответов, но действуют на совершенно разных уровнях.
Инжиниринг промптов — это искусство составления инструкций, которые определяют поведение модели во время выполнения задач. Хороший промпт может улучшить процесс рассуждений, задать формат вывода, назначить модели определенную роль или способствовать пошаговому мышлению. Приказ модели действовать как сотрудник, отвечающий за соблюдение правил AML, и всегда обосновывать свои рекомендации с точки зрения нормативных требований может повысить качество и последовательность ее действий без изменения самой модели. Однако промпт не может добавить новые знания. Если модель никогда не видела обновления правил AML вчера, никакие формулировки не заставят ее правильно цитировать этот документ. Использование промптов изменяет поведение модели, но не влияет на ее существующие знания.
Обучение в контексте позволяет модели выявлять закономерности на основе примеров, указанных в запросе. Параметры модели при этом не изменяются. Вы показываете несколько примеров выполнения задачи, например, как классифицируются жалобы клиентов, а затем предоставляете новый случай. Модель определяет закономерность и применяет её. Этот метод хорошо работает для форматирования, классификации, извлечения данных и многих задач рассуждений. Его ограничением является масштаб: примеры занимают место в окне контекста и исчезают по окончании запроса. Ничего не сохраняется навсегда, и модель по-прежнему не может использовать знания, находящиеся вне пределов предоставленного запроса, если только эти знания не будут включены в него напрямую.
Тонкая настройка изменяет модель. Дальнейшая обучающая процедура изменяет её параметры, позволяя ей постоянно осваивать новые поведенческие модели, стили написания, словарный запас конкретной области или навыки выполнения задач. Это полезно, когда требуется единообразный стиль ответов, специализированное рассуждение в определённой области, структурированный вывод или лучшие результаты при выполнении чрезвычайно повторяющихся задач. Однако тонкая настройка часто неправильно понимается, и она является неэффективным механизмом для сохранения постоянно меняющихся знаний. Предположим, вы настраиваете модель на руководство для сотрудников, а через месяц оно пересматривается. Модели требуется ещё один цикл обучения, чтобы усвоить изменения, и постоянное повторение этого процесса при каждом обновлении знаний делает его неработоспособным. Тонкая настройка учит модель выполнять конкретную задачу. Она не является лучшим способом обучения её фактам, которые часто меняются.
Генерация с усилением с помощью поиска следует иным путем. Она добавляет внешний слой знаний между пользователем и моделью, не затрагивая при этом ни запрос, ни параметры. При поступлении вопроса система извлекает соответствующий материал из надежных корпоративных источников и передает его модели перед тем, как будет сгенерирован ответ. Знания остаются вне модели, где их легче обновлять, защищать, контролировать и аудитировать. От модели не требуется хранить все факты в памяти. Системе указывают, где сначала искать, после чего формируется ответ.
Эти технологии не являются конкурентами. Они решают разные задачи и часто сосуществуют в одной производственной системе. В банковском помощнике подсказки могут обеспечивать соблюдение установленных форматов ответов, настройки могут улучшить использование финансовой лексики и структурированность вывода, а технология RAG может получать самые свежие правила АМЛ, процедуры KYC и внутренние руководства по соблюдению норм. Сила системы заключается в сочетании этих инструментов там, где они наиболее подходят, а не в ожидании того, что один метод сможет покрыть всё.
Как развивалась технология RAG: от примитивной до продвинутой, модульной и агентной
RAG не появился в виде готовой архитектуры. Как и большинство инженерных систем, он совершенствовался в ходе множества итераций, при каждой из которых устранялись недостатки, обнаруживаемые в реальных условиях использования. По мере того как компании переходили от исследовательских прототипов к прикладным решениям, возникали новые проблемы, вынуждавшие вносить изменения в механизмы поиска информации, оркестрации действий, логических рассуждений, оценки результатов и общую структуру системы.
Эта история важна потому, что более поздние версии не заменяли предыдущие — они строились на их основе. Каждая современная производственная система по-прежнему содержит основные элементы самых первых реализаций, только значительно усовершенствованные. Этот путь развития имеет четыре основных этапа: наивный, продвинутый, модульный и агентный RAG.
Наивный RAG
Первые реализации развивались по прямой линии. Пользователь задавал вопрос, система извлекала k наиболее похожих фрагментов из векторной базы данных, присоединяла их к запросу и отправляла всё модели. В визуальном представлении:
User Query
│
▼
Vector Search
│
▼
Top-k Retrieved Chunks
│
▼
Prompt + Context
│
▼
LLM
│
▼
Answer
Этот проект показал, что использование внешних знаний моделью значительно повышает точность информации по сравнению с результатами, достигаемыми только с помощью параметрической памяти. Для простого ответа на вопросы на основе документов это решение сработало удивительно хорошо.
Однако в реальных условиях быстро проявились слабости этого подхода. Определение семантической похожести само по себе часто приводило к получению фрагментов, которые были лишь частично релевантны или дублировали друг друга. Иногда удавалось пропустить важные документы, а нерелевантные фрагменты занимали ценное пространство для контекста. Каждый полученный фрагмент рассматривался одинаково, независимо от его качества. Когда объем баз знаний вырос с сотен документов до миллионов, эти недостатки уже невозможно было игнорировать. Примитивный подход RAG доказал целесообразность концепции, но не справлялся с масштабами реальных задач.
Развитый подход RAG
Следующее поколение было создано на основе простого наблюдения: лучшее извлечение данных приводит к лучшему генерированию. Вместо того чтобы полагаться только на поиск по векторному сходству, был улучшен процесс извлечения данных в нескольких аспектах.
Гибридный метод извлечения данных сочетал семантический поиск с традиционным поиском по ключевым словам для повышения точности результатов. Модели переранжирования перестраивали порядок результатов в соответствии с их релевантностью, а не с первоначальным значением сходства. Фильтрация метаданных ограничивала поиск определенными типами документов, отделами, клиентами или периодами времени. Переписывание запросов преобразовывало нечеткие вопросы в такие, которые удобно было обрабатывать для извлечения данных, а компрессия контекста удаляла избыточный или малоценный текст до того, как он попадал в модель.
Общая структура осталась близкой к примитивному RAG, но процесс поиска стал гораздо умнее. Вопрос изменился с «Какие документы наиболее похожи?» на «Какие документы наиболее полезны для ответа на этот вопрос?» Это изменение повысило качество ответов и сократило количество ошибочных данных, особенно в корпоративных системах поиска. Однако осталось одно ограничение: процессы поиска, обработки информации и координации действий по-прежнему были объединены в единую линейную последовательность.
Модульный RAG
По мере того как корпоративные ИИ-решения становились всё более сложными, команды обнаружили, что монолитные архитектуры трудно расширять, настраивать и обслуживать. Разные приложения требовали разных стратегий поиска, способов формирования запросов и методов оценки. Один и тот же модель мог использоваться в юридических инструментах, системах контроля соответствия в банках и инструментах технического обслуживания авиакомпаний, но каждое из них нуждалось в собственной системе поиска.
Модульная архитектура RAG основана на разделении системы на независимые части. Каждый этап превращается в специализированный модуль с четко определенными функциями. Теперь все этапы — от приема данных и их разбиения на фрагменты, через генерацию векторных представлений, индексацию, переранжирование, формирование запросов, оценку качества, кэширование и мониторинг — могут развиваться по собственному графику, не влияя на остальные компоненты всей системы.
Благодаря такой модульности архитектура RAG превратилась из прототипа в инженерную платформу. Это облегчило тестирование, наблюдение, масштабирование и обслуживание корпоративных систем, и большинство современных проектов в производственных условиях следуют этой философии, даже если используются разные фреймворки.
Агентная архитектура RAG
На новом этапе выявляется ещё одно ограничение: многие реальные вопросы невозможно решить с помощью одного поиска. Возьмём, к примеру, запрос вроде «поместите изменения в самом новом регламенте по борьбе с отмыванием денег рядом с нашей собственной политикой соответствия и укажите, в чём мы отстаём». Для ответа требуется несколько этапов обработки информации. Системе может потребоваться извлечь нормативные рекомендации, извлечь внутреннюю политику, сравнить их, выявить несоответствия, проверить подтверждающие документы, и только затем сформулировать вывод. Фиксированная процедура редко справляется с подобными многоэтапными задачами.
Агентный RAG включает процессы планирования, рассуждения и принятия решений в сам процесс поиска информации. Вместо выполнения заранее заданного алгоритма работы система сама определяет необходимые действия, пошагово получает информацию, при необходимости вызывает внешние инструменты, оценивает промежуточные результаты и продолжает работу до тех пор, пока не соберёт достаточно доказательств. Модель перестаёт быть просто генератором ответов и становится оркестратором, который решает, какая информация нужна, где её найти и требуется ли дополнительный поиск перед тем, как дать ответ. Это подходит для исследовательских ассистентов, анализа регуляторных норм, финансовых расследований, помощников в разработке программного обеспечения и других сложных рабочих процессов, в которых используется несколько источников информации.
Каждый шаг был обусловлен проблемами
Каждое новое поколение появлялось из-за того, что предыдущее достигало своих пределов в процессе обработки данных: примитивные системы сталкивались с проблемами релевантности, более сложные — с жесткой структурой, а модульные — с задачами, требующими нескольких этапов. Поэтому архитектура RAG никогда не была фиксированной и постоянно меняется по мере изменения задач в области корпоративного искусственного интеллекта. Новые решения, несомненно, дальше улучшат процессы поиска информации, рассуждений и координации действий, однако все они по-прежнему основаны на идее, заложенной в первых системах: сначала необходимо получить надежную информацию, прежде чем просить модель что-либо написать.
Часто возникает неверное мнение, что агентные системы RAG заменяют традиционные версии. Это не так — они их расширяют. Агент по-прежнему зависит от качественно обработанных документов, эффективного поиска информации и тщательно созданного контекста, и без этих основ даже самый совершенный агент не сможет дать надежных результатов.
Два типа процессов обработки: офлайн и онлайн
Самое распространённое заблуждение относительно RAG заключается в том, что он начинает работу с момента, когда пользователь задаёт вопрос. На самом деле это не так. К моменту, когда первый вопрос попадает в производственную систему, обычно уже собраны, обработаны, проанализированы, дополнены, разделены на части, встроены, индексированы и сохранены тысячи или миллионы документов. Всё это происходит до того, как пользователь начнёт ждать, то есть задолго до первого запроса.
Это делит любую производственную систему на две независимые цепочки обработки: оффлайн-цепочку, которая готовит знания, и онлайн-цепочку, которая отвечает на вопросы. Разделение является базовым, поскольку эти две цепочки решают разные задачи, работают в разных временных масштабах и настраиваются для достижения разных целей.
Оффлайн: подготовка знаний
Офлайн-процесс преобразует сырые корпоративные данные в поисковую базу знаний. Его входными данными являются не вопросы, а сами знания организации, которые могут поступать из документов с правилами, контрактов, технических руководств, нормативных публикаций, библиотек SharePoint, страниц Confluence, баз данных, электронной почты, PDF-файлов, отсканированных изображений, таблиц или многих других источников.
Чтобы всё это можно было быстро найти, необходимо пройти несколько этапов подготовки. Файлы загружаются с различных систем, очищаются, затем преобразуются в простой текст, читаемый компьютером, маркируются метаданными, делятся на логические части, встраиваются в виде векторов и, наконец, индексируются, чтобы поиск оставался быстрым при поступлении запросов. Цель не в том, чтобы отвечать на вопросы, а в том, чтобы убедиться, что база знаний верно отражает то, что организация в настоящее время знает, и позволяет эффективно выполнять поиск. Поскольку эти операции требуют значительных вычислительных ресурсов, они выполняются заранее, а не во время взаимодействия с пользователем. Когда корпоративные знания меняются, процесс снова запускается для обновления индекса. Пользователи этого не видят, но это сильно влияет на каждый ответ.
Онлайн: ответы на вопросы
Онлайн-процесс запускается только тогда, когда пользователь отправляет запрос. Работа в оффлайн-режиме требует полноты и тщательной подготовки, тогда как онлайн-версия создана для скорости. Пользователи ожидают ответов в течение секунд, иногда даже миллисекунд, и каждая операция после поступления вопроса увеличивает задержку.
Вместо обработки документов этот процесс обрабатывает цель запроса. Он анализирует запрос, извлекает наиболее релевантные материалы из индекса, собирает полученный контекст, формирует соответствующий промпт, вызывает модель и возвращает обоснованный ответ. Поскольку знания были подготовлены заранее, система может сосредоточиться на поиске информации и логических рассуждениях, что позволяет производственным системам быстро реагировать, не жертвуя качеством поиска.
Почему разделение важно
Это может показаться деталью реализации, но разделение системы именно таким образом является одним из самых важных решений в инженерии RAG. Оффлайн-часть оптимизирована для качества знаний. Онлайн-часть оптимизирована для качества ответов и времени их генерации. Смешивание этих двух аспектов приводит к неэффективным системам.
Представьте себе, что каждый раз, когда кто-то задает вопрос, необходимо парсить сотни PDF-файлов, извлекать таблицы, генерировать векторные представления и создавать векторные индексы. Даже простой запрос займет несколько минут, и никто не сможет им воспользоваться. Теперь представьте обратную ситуацию: индекс оффлайн-части никогда не обновляется после изменения правил. В таком случае онлайн-часть будет извлекать устаревшие данные и уверенно отвечать на вопросы на основе просроченных знаний. Качество работы системы в реальных условиях зависит от совместной работы обеих частей: одна создает надежные знания, другая находит их и анализирует, причем сбои в любой из частей невозможно устранить с помощью другой.
Два канала обработки, одна система
Хотя они работают отдельно, они тесно связаны между собой. Результаты работы оффлайн-канала служат входными данными для онлайн-канала. Если документ загружен неправильно, онлайн-часть никогда не сможет его найти. При плохом разделении на части процесс поиска ухудшается. Если генерируются некачественные эмбеддинги, релевантную информацию может так и не найти. Даже идеально подготовленная база знаний может привести к плохим ответам, если при поиске выбираются нерелевантные документы или модель получает некорректно собранный контекст.
Обе системы обработки данных требуют одинакового внимания. Быстрый онлайн-механизм не может компенсировать небрежную подготовку знаний, так же как отличный оффлайн-механизм не может исправить слабые процессы поиска или генерации информации. Полезное правило: оффлайн-система определяет, что может знать система, а онлайн-система — насколько хорошо она использует эти знания. Оптимизация только одной из них почти всегда приводит к разочаровывающим результатам в реальных условиях.
Три уровня
Реализации различаются в зависимости от фреймворков и компаний, однако практически любую производственную систему можно разделить на три логических уровня: входные данные, поиск и генерация. Это функции, а не конкретные продукты. Независимо от того, использует ли команда LangChain, LlamaIndex, Haystack, пользовательские микросервисы или внутреннюю платформу, разделение остается прежним. Каждый уровень решает свою инженерную задачу, и слабость в любом из них влияет на итоговый результат, независимо от мощности модели.
Первый уровень: входные данные
Каждая система типа RAG начинается с знаний, причем корпоративные знания редко поступают в пригодном для использования виде. Обычно организации хранят информацию в документах с правилами, контрактах, PDF-файлах, отсканированных изображениях, библиотеках SharePoint, страницах Confluence, базах данных, таблицах, электронных письмах и внутренних порталах, причем у каждого из этих источников свой формат, структура и ритм обновления.
Слой обработки данных преобразует этот фрагментированный материал в структурированную, поисковую базу знаний. Детали могут отличаться, но обычно он включает сбор документов, парсинг, извлечение текста, дополнение метаданных, разбиение на части, генерацию эмбеддингов и индексацию. Когда информация покидает этот слой, она уже не представляет собой просто набор документов, а становится поисковой базой знаний, готовой к поиску при поступлении вопросов. Всё это происходит ещё до первого запроса, что делает обработку данных основой любой системы RAG.
Люди часто считают, что качество поиска зависит от инструмента поиска. На самом деле оно определяется именно на этом этапе. Если важные документы отсутствуют, они плохо парсируются, неправильно разбиваются на части или индексируются с недостаточным количеством метаданных, никакая стратегия поиска не сможет вернуть информацию, которая так и не была правильно подготовлена.
Второй слой: поиск
Как только знания подготовлены, следующей задачей является быстрое и точное нахождение нужного элемента. При поступлении запроса слой поиска анализирует его и определяет информацию, наиболее вероятно способную на него ответить. Поиск часто отождествляют с поиском по векторному сходству, но в производственных системах редко используется только один метод. Современные системы могут сочетать поиск на основе смысла, поиск по ключевым словам, фильтры метаданных, гибкую оценку релевантности, переранжирование и переписывание запросов с целью одновременного повышения точности и полноты ответов.
Цель заключается не просто в получении похожих документов, а в получении доказательств, которые позволяют модели сформировать наиболее точный и надежный ответ. Это различие становится все более важным по мере увеличения объема и сложности баз знаний. Даже самая совершенная модель не сможет компенсировать слабый поиск, поскольку если релевантные данные так и не поступят, у нее не будет надежных оснований для работы.
Третий уровень: генерация
Последний уровень преобразует полученные доказательства в ответ на натуральном языке. Релевантные материалы собираются в контекст и передаются модели вместе с первоначальным вопросом. Модель анализирует их оба и пишет ответ, который является целостным, соответствующим контексту и основанным на предоставленной информации.
На этом этапе модель выполняет ту функцию, ради которой была создана. Она не ищет документы, не индексирует знания и не решает, как следует хранить информацию компании. Её задачи — логическое мышление, синтез, краткое изложение, объяснение и плавное написание текста. Качество её работы во многом зависит от двух предыдущих уровней. Высокоэффективная модель, получающая неполный или нерелевантный контекст, часто дает неполные или вводящие в заблуждение ответы, в то время как более маленькая модель, имеющая высокорелевантные данные, часто превосходит гораздо более крупную модель, получающую плохие результаты поиска. Это одна из определяющих особенностей промышленных решений типа RAG.
Уровни взаимозависимы
Ни один из трех компонентов не должен рассматриваться изолированно:
- Этап ввода данных определяет, какие знания доступны.
- Этап поиска определяет, какие знания могут быть обнаружены.
- Этап генерации определяет, каким образом эти знания передаются.
Каждый слой зависит от предыдущего. Сбой на этапе получения данных оставляет систему поиска без чего-либо, что стоило бы искать; сбой в системе поиска лишает модель надежных доказательств; сбой на этапе генерации может исказить даже те доказательства, которые были получены без ошибок. Поэтому успешные корпоративные системы настраивают все три компонента совместно, а не сосредотачиваются только на модели.
Инженеры, переходящие к использованию RAG в производственных условиях, часто приходят к одному и тому же выводу: модель — это лишь одна часть гораздо более крупной системы. Именно поэтому современная работа с RAG в основном является проблемой инженерии систем, а не выбора модели. Краткий способ запомнить это: получение данных готовит знания, поиск находит знания, а генерация объясняет знания. Каждая производственная система, независимо от используемых инструментов, следует этой схеме.
Работа с одним вопросом
Знание архитектуры — это лишь половина дела. Чтобы по-настоящему понять RAG, необходимо проследить один запрос через всю систему. Каждый вопрос запускает серию согласованных операций. Некоторые из них завершаются за миллисекунды, другие требуют сложных процедур по поиску информации, её ранжированию и анализу, но каждая из них вносит вклад в окончательный ответ. Более точно будет рассматривать RAG как цепочку решений, а не как одну операцию «найти, затем сгенерировать».
Первый шаг: поступает вопрос. Предположим, пользователь вводит: «Какие документы с идентификаторами необходимо собрать для привлечения корпоративного клиента с высоким уровнем риска согласно самым новым правилам Антиотмывочного законодательства?» На этом этапе система не знает ничего, кроме самого запроса. Она не знает, какие документы важны, применимы ли несколько правил, а также находится ли ответ в одном документе или в нескольких. Её цель — лишь выяснить, о чём идёт речь.
Второй шаг: интерпретация. Перед поиском система понимает смысл вопроса. Это может включать выявление ключевых сущностей, распознавание аббревиатур, определение намерения, устранение неоднозначности терминов или преобразование вопроса в форму, которая обеспечит более точный результат. Например, «AML» может быть внутренне расшифровано как «антиотмывочные меры», а «корпоративный клиент с высоким риском» — соотнесено с конкретной категорией клиентов, используемой организацией. Пользователи редко видят этот этап, но он сильно влияет на точность поиска.
Третий шаг: поиск. После понимания запроса слой поиска ищет информацию в индексированном хранилище. Он не сканирует каждый документ, а ищет те элементы, которые с наибольшей вероятностью могут ответить на вопрос, возможно, используя критерии семантического сходства, совпадения ключевых слов, фильтры метаданных и ранжирование документов. Цель не в том, чтобы вернуть как можно больше документов, а в том, чтобы найти наименьший набор доказательств, которые с наибольшей уверенностью подтверждают ответ.
Четвертый шаг: формирование контекста. Полученный материал редко поступает к модели в неизменном виде. Система создает итоговый контекст: возможно удаление дублирующихся фрагментов, изменение порядка разделов, добавление метаданных, удаление нерелевантного текста и сохранение ссылок. Это обеспечивает модели целостные, релевантные и краткие доказательства вместо беспорядочной смеси фрагментов. Качество контекста зачастую влияет на ответ сильнее, чем количество полученных документов.
Пятый шаг: генерация. Только сейчас модель начинает работу. Она получает исходный вопрос пользователя, полученный контекст и системные инструкции, определяющие, как должны формироваться ответы. Вместо того чтобы опираться исключительно на память, она анализирует предоставленные данные, чтобы написать обоснованный ответ. Её задача теперь — не воспроизводить знания компании, полученные во время обучения, а интерпретировать, синтезировать и объяснять то, что было получено.
Шаг шесть: возврат ответа. Ответ возвращается пользователю. Во многих корпоративных системах он содержит вспомогательные ссылки, цитаты из документов, показатели уверенности или ссылки на оригиналы. Это особенно важно в регулируемых сферах, таких как банковское дело, здравоохранение, юридические услуги и авиация, где людям необходимо проверять источник перед принятием решений. С точки зрения пользователя взаимодействие кажется простым, однако за ним стоит целый процесс: подготовка документов, поиск информации, их ранжирование, формирование контекста и, наконец, составление текста на языке.
Множество решений, скрытых в одном запросе
Процесс кажется линейным, но на каждом этапе принимаются инженерные решения, которые напрямую влияют на результат. Неправильно понятый запрос возвращает неверные документы. Плохой поиск означает наличие неполных доказательств. Недостаточная обработка контекста приводит к перегрузке модели нерелевантным текстом. Неудачно сформулированный запрос может заставить модель игнорировать важные доказательства. Надежность — это сумма всех этапов, и именно поэтому работа над продакшн-решением выходит далеко за рамки простого выбора модели эмбеддингов или векторной базы данных.
Система RAG не дает хороших результатов, потому что в ней хранится больше знаний, чем в модели. Ее преимущество заключается в дисциплинированной процедуре: сначала она находит, фильтрует и применяет нужные знания, а только затем формирует ответ. Именно эта дисциплина превращает прототип в готовую к использованию систему.
Почему сбоют продакшн-системы
Систему RAG не следует оценивать по демо-версиям. Её следует оценивать по тому, насколько надежно она справляется с неоднозначными вопросами, неполной документацией, быстро меняющимися знаниями, противоречивой информацией и реальными данными предприятия. Публичные демо-версии обычно проходят по «идеальному» сценарию: документ индексируется, возвращается нужный фрагмент, и модель дает правильный ответ. В реальных условиях всё редко работает таким образом. Документы бывают неполными, правила противоречат друг другу, в отсканированных PDF-файлах есть ошибки OCR, метаданные несогласованы, поиск возвращает лишь частично релевантный текст, а пользователи задают нечеткие вопросы на языке, не соответствующем базе знаний.
Когда ответ неверен, обычно сначала винят модель. Но на самом деле модель является лишь последним этапом длинной цепочки обработки, а настоящая ошибка возникает раньше. Определение места возникновения ошибки — первый шаг к её устранению. В общих чертах существуют три категории: ошибки поиска информации, ошибки формирования контекста и ошибки генерации.
Ошибки поиска информации: не удается найти нужные знания
Это самая распространённая проблема, которая возникает ещё до вмешательства модели. Если система поиска не может найти правильную информацию, у модели нет надёжных данных для генерации ответа. Типичные причины: соответствующие файлы так и не попали в индекс, были повреждены, разделены на бесполезные фрагменты или заняты более сильными по релевантности результатами. Иногда запрос формулируется иначе, чем в исходном источнике, поэтому система поиска не может увидеть связь между ними.
Предположим, сотрудник, отвечающий за соблюдение правил, задает вопрос: «Какие усиленные требования к добросовестности применяются к лицам, находящимся под политическим давлением?», и во внутренней политике всегда используется аббревиатура PEP вместо полного названия. Если система поиска не понимает, что оба выражения означают одно и то же, правильный документ может так и не быть найден. Модель не сработала неправильно — сработала неправильно система поиска. Это важно, потому что замена её на более сложную модель не решит проблему, поскольку ни одна модель не может анализировать информацию, которую она никогда не получала.
Сбои в формировании контекста: хорошие доказательства, неправильное их использование
Поиск соответствующей информации не гарантирует получения правильного ответа, поскольку доказательства должны быть организованы в полезный контекст перед тем, как попасть к модели. В производственных системах часто загружается слишком много данных: дублирующиеся фрагменты, противоречивые версии документов или несвязанные разделы, что мешает выделить важные доказательства.
Возьмём организацию, которая хранит несколько версий внутренней политики. При поиске удаётся найти как текущую версию, так и устаревшую. Если обе версии включаются без указания порядка или информации о версии, модель получает противоречивые данные. Она может объединить их в один ответ или отдать приоритет устаревшим рекомендациям. Проблема заключается не в самой модели, а в процессе сбора контекста. Качественный сбор контекста настолько же важен, насколько и качественный поиск, а добавление большего количества документов не обязательно улучшает ответы — часто это даже ухудшает их.
Сбои при генерации: правильные данные, неправильная интерпретация
Даже когда процессы поиска и сбора информации проходят идеально, итоговый ответ может оказаться неверным. Модель может неправильно понять найденный текст, делать чрезмерные обобщения на основе неполных данных, упускать важные детали или формулировать утверждения, выходящие за рамки предоставленного контекста. Например, банковская политика может предусматривать усиленные меры проверки только для корпоративных клиентов. Если модель ошибочно распространяет их на частных лиц, технически поиск информации прошел успешно, но ошибка возникает на этапе логических рассуждений и формулирования ответа. Современные модели мыслят гораздо лучше, чем раньше, но они по-прежнему являются вероятностными системами, а не детерминистскими механизмами рассуждения. Использование фактических данных повышает надежность, но не гарантирует корректности ответа.
Как возникают каскадные сбои
Сбои редко возникают поодиночке. Некорректное принятие решения о поиске часто приводит к плохой сборке контекста, что, в свою очередь, увеличивает вероятность ошибок при генерации. Типичная цепочка событий выглядит следующим образом:
- Документ, разделенный на некорректные фрагменты, мешает точному поиску.
- Система поиска выдает лишь фрагмент применимых правил.
- При сборке контекста игнорируются вспомогательные положения.
- Модель заполняет пробелы с помощью собственной параметрической памяти.
- Итоговый ответ звучит уверенно, но содержит неверные рекомендации по регулированию.
К тому моменту, когда пользователь это замечает, видимым симптомом кажется галлюцинация, хотя настоящая причина находится гораздо выше в цепочке событий. Именно такая каскадная реакция является одной из причин сложности отладки систем RAG в производственных условиях.
Диагностика как у инженера
Частой ошибкой является замена модели сразу при снижении качества ответа. Более методичным подходом будет последовательный анализ трех вопросов: были ли найдены правильные доказательства? Если их не нашли, проблема кроется в процессе поиска. Были ли найденные доказательства должным образом организованы перед генерацией ответа? Если нет, проблема связана с формированием контекста. Правильно ли модель интерпретировала предоставленные доказательства? Если нет, проблема заключается в самой процедуре генерации. Эти вопросы значительно сокращают время отладки, поскольку позволяют выявить конкретный этап, ответственный за ошибку, что позволяет инженерам улучшить именно ту часть системы, которая действительно нуждается в работе, вместо того чтобы рассматривать каждый неверный ответ как проблему модели.
В ходе внедрения решений в крупных предприятиях постоянно возникает одно наблюдение: большинство сбоев в системах RAG в производственных условиях — это сбои при поиске информации, маскирующиеся под сбои модели. Модель представляет собой лишь ту часть, которую видят пользователи. Настоящая причина часто кроется в процессах загрузки данных, индексации, поиска или формирования контекста, и именно поэтому столь большое внимание уделяется загрузке документов, их разбиению на части, генерации векторных представлений и настройке процесса поиска, поскольку именно эти факторы определяют, получит ли слой генерации необходимые доказательства. Краткое правило отладки: если отсутствуют доказательства, проверьте процесс поиска; если они неясны, проверьте формирование контекста; если доказательства правильные, но ответ неверный, проверьте процесс генерации. Эта единая схема помогает анализировать практически любой сбой в производственных условиях.
Когда RAG — подходящий инструмент, а когда — нет
RAG стал ведущей архитектурой для корпоративного ИИ, но он не подходит для всех задач. Как и любой подход, он увеличивает операционную сложность, требует определённой инфраструктуры и обслуживания. Выбор его из-за модности часто приводит к чрезмерно сложным системам, тогда как выбор по правильным причинам позволяет достичь того, что иначе было бы трудно осуществить. Понимание того, в чём он превосходен, а в чём — нет, является одним из важнейших архитектурных решений, которые принимает инженер по ИИ.
Подходящие случаи применения
RAG проявляет себя наилучшим образом, когда ответы зависят от внешних знаний, которые постоянно меняются. Модель опирается на то, что она выучила во время обучения, тогда как система RAG может получать самые свежие документы по запросу. Это особенно ценно для организаций, чьи знания постоянно развиваются. Хорошим примером являются ассистенты по разработке политик. Банки регулярно обновляют процедуры борьбы с отмыванием денег, руководства по проверке личности клиентов, правила борьбы с мошенничеством и нормативные требования. Вместо того чтобы переобучать модель при каждом изменении, система RAG просто обновляет хранилище данных, и следующий запрос автоматически получает актуальную информацию.
Эта закономерность наблюдается во всех отраслях. Юридические команды изучают изменённые контракты и законы. Инженеры авиастроения ищут в руководствах информацию, обновлённую после выпуска технических бюллетеней. Медицинские специалисты обращаются к постоянно обновляемым рекомендациям. Системы поддержки запрашивают актуальную документацию к продуктам и процедуры устранения неисправностей. Во всех случаях ценность заключается в предоставлении модели свежих, проверяемых и специфичных для организации данных вместо использования исключительно параметрической памяти.
Объяснимость является ещё одним существенным преимуществом. Многие деловые решения требуют подтверждающих доказательств, а не простого ответа. Специалист по соблюдению норм может спросить, почему необходимый шаг в процессе интеграции, юридический аналитик — точный пункт правил, лежащий в основе рекомендации, а сотрудник службы поддержки — статью из базы знаний перед тем, как ответить клиенту. Поскольку технология RAG запрашивает информацию из известных документов, ответы можно связать с их источниками, что повышает прозрачность, возможность аудита и доверие.
Ограничения применения
Не каждому приложению требуется внешнее поиск информации. Если задача в основном связана с логическими рассуждениями, кратким изложением, переводом, генерацией кода или переписыванием уже предоставленного пользователем контента, использование механизма поиска может только усугубить сложность без улучшения результатов. Приложения, основанные на довольно статичных данных, также вряд ли получат значительную пользу. Если необходимые знания редко меняются и укладываются в рамки того, что может обработать модель, использование техник формулировки запросов или их доработка может оказаться проще и легче в обслуживании.
RAG также не может компенсировать низкое качество корпоративных данных. Если документы устарели, неполны, дублируются или противоречивы, поиск лишь выявляет эти проблемы для модели, и качество ответов никогда не сможет превзойти качество базы знаний. RAG улучшает доступ к знаниям, но не улучшает их качество.
Сделают ли огромные окна контекста RAG устаревшим?
Одним из активно обсуждаемых вопросов является то, устраняют ли всё более большие окна контекста необходимость в технологии RAG. Если модели могут обрабатывать сотни тысяч или миллионы токенов в одном запросе, почему бы не передать им все соответствующие документы и не пропустить этап поиска? На первый взгляд это кажется разумным, но на практике всё гораздо сложнее.
Большие окна контекста увеличивают объём информации, который может обработать модель. Однако они не устраняют трудностей, связанных с управлением знаниями в корпорациях. Корпоративные хранилища часто содержат миллионы документов, несколько их версий, ограничения на доступ и постоянно меняющийся контент. Отправка всей базы знаний модели при каждом запросе была бы дорогостоящей, медленной и неэффективной, к тому же большинство документов всё равно не имеют отношения к конкретному вопросу. Поиск остаётся важным инструментом, поскольку он позволяет выделить ту небольшую группу документов, которые действительно важны для ответа на запрос.
Модели с длинным контекстом и RAG не являются конкурентами. Они решают разные задачи. Длинный контекст позволяет обрабатывать больший объем информации во время вывода результата, в то время как RAG определяет, какая информация должна обрабатываться в первую очередь. Многие современные системы сочетают оба подхода: механизм поиска выбирает наиболее подходящие данные, а большой окно контекста обеспечивает достаточно пространства для анализа нескольких документов без потери связей между ними.
Оценка компромиссов
Выбор архитектуры ИИ — это процесс поиска баланса между различными факторами. Технология RAG требует дополнительной инфраструктуры, систем обработки документов, механизмов индексации, мониторинга и поиска, но взамен обеспечивает более актуальные знания, улучшенный контроль и возможность объяснения решений. Тонкая настройка упрощает выполнение задач специализированного характера, но плохо подходит для ситуаций, когда знания быстро меняются. Инжиниринг промптов — самый простой вариант, когда у модели уже есть необходимые знания. Ни одна архитектура не подходит во всех случаях, и лучшая из них решает реальную проблему с минимальной ненужной сложностью.
Лучшим вопросом для начала обсуждения, чем «Стоит ли нам использовать RAG?», будет вопрос: «Требуется ли этому приложению знание, находящееся вне модели и изменяющееся со временем?» Если да, то RAG часто бывает правильным решением. Если нет, более простые варианты могут помочь достичь цели с меньшими затратами и без лишних сложностей. Многие корпоративные команды придерживаются простого правила: использовать RAG, когда меняются знания, использовать тонкую настройку модели, когда меняется её поведение, а использовать техники формулировки запросов — когда ни то, ни другое не требует значительных изменений. Этот принцип позволяет избежать множества ненужных архитектурных решений.
RAG как способ мышления
RAG — это не просто функция. Это философия архитектуры. Качество производственной системы определяется не только выбором модели, но и тем, насколько хорошо знания подготавливаются, извлекаются, объединяются и представляются до самого начала генерации ответа.
Такой взгляд меняет подход к использованию искусственного интеллекта в корпоративных целях. Вместо вопроса «Какую модель нам использовать?» опытные инженеры задают другие вопросы: как собирается и сохраняется корпоративные знания? Обеспечивает ли система надёжный поиск необходимых данных? Является ли собранный контекст полным, релевантным и надёжным? Возможно ли проследить происхождение каждого ответа? Что произойдёт, если завтра изменятся знания? Именно эти вопросы в большей степени определяют качество систем RAG для производственного использования, чем выбор модели.
Они имеют особое значение в регулируемых секторах, таких как банки, страховые компании, больницы, авиакомпании и государственные органы, где точность, объяснимость, наличие контроля и возможность аудита являются деловыми обязанностями, а не дополнительными опциями. Здесь недостаточно убедительного ответа — он должен подкрепляться доказательствами, соответствовать последним знаниям в области организации работы и быть достаточно надежным для принятия реальных решений.
Обратите внимание на то, что намеренно не упомянуто: инструменты загрузки документов, стратегии разбиения на части, технологии эмбеддингов, векторные базы данных, алгоритмы поиска, шаблоны запросов и фреймворки оркестрации. Прежде чем учиться создавать производственные системы, более полезно понять, зачем существует каждый компонент. Как только архитектурные принципы станут ясны, оценка каждого варианта реализации становится проще, поскольку его можно связать с конкретной инженерной проблемой.
И это указывает на направление дальнейших исследований. Каждый ответ, который даёт приложение типа RAG, зависит от качества имеющейся у него информации. Если документы неполные, плохо обработаны, в них отсутствуют таблицы или они были неправильно обработаны при загрузке, ни один метод поиска или модель не смогут это компенсировать. Поэтому следующей естественной темой является первый этап любой производственной системы: загрузка документов из корпоративных хранилищ, извлечение контента из сложных макетов, сохранение метаданных, обработка таблиц и изображений, а также преобразование необработанных файлов в качественную основу для дальнейшей работы. Многие проблемы с поиском, возникающие во время выполнения запроса, на самом деле начинаются гораздо раньше, уже на этапе загрузки.
Связанные материалы
- Практические заметки: Что такое генерация с усилением через поиск (RAG)? Практическое руководство — Подробное пошаговое руководство по практическим заметкам: Что такое генерация с усилением через поиск (RAG)? Практическое руководство: шаблоны контрактов, проверок и готового кода для команд, использующих эту технологию.
- RAG на простом Python: разбиение на фрагменты, TF-IDF, косинусное сходство и формулировка запросов — Создание системы генерации с усилением через поиск с использованием только модуля математики: разбиение текста на фрагменты с использованием скользящего окна, векторы TF-IDF, ранжирование по косинусу, эффективные запросы и их ограничения.