Предприятия измеряют не ту часть RAG

Предприятия быстро перешли на внедрение RAG для заземления LLM в собственных данных. Однако на практике многие организации обнаруживают, что извлечение больше не является функцией, привязанной к выводу модели, — оно стало фундаментальной зависимостью системы.

После развертывания систем искусственного интеллекта для поддержки принятия решений, автоматизации рабочих процессов или эксплуатации полуавтономносбои при извлечении напрямую влияют на бизнес-риск. Устаревший контекст, неуправляемые пути доступа и плохо оцененные конвейеры поиска не просто ухудшают качество ответов; они подрывают доверие, соблюдение требований и эксплуатационную надежность.

В этой статье поиск рассматривается как инфраструктура, а не как логика приложения. Он представляет модель системного уровня для проектирования поисковых платформ, которые поддерживают актуальность, управление и оценку как первоклассные архитектурные задачи. Цель состоит в том, чтобы помочь корпоративным архитекторам, лидерам платформ искусственного интеллекта и командам по инфраструктуре данных рассуждать о поисковых системах с той же строгостью, которая исторически применялась к вычислениям, сетям и хранению данных.

Извлечение как инфраструктура. Эталонная архитектура, иллюстрирующая, как актуальность, управление и оценка функционируют как первоклассные системные плоскости, а не как встроенная логика приложения. Концептуальная схема, созданная автором.

Почему RAG терпит неудачу в масштабах предприятия

Рано Реализации RAG были разработаны для узких случаев использования: поиск документов, внутренние вопросы и ответы и вторые пилоты, работающие в узко ограниченных областях. Эти конструкции предполагали относительно статичные корпуса, предсказуемые модели доступа и постоянный контроль со стороны человека. Эти предположения больше не верны.

Современные корпоративные системы искусственного интеллекта все чаще полагаются на:

• Постоянно меняющиеся источники данных

• Многоэтапное рассуждение в разных областях

• Рабочие процессы, управляемые агентом, которые автономно извлекают контекст

• Нормативные и аудиторские требования, связанные с использованием данных

В таких средах сбои при извлечении данных быстро усугубляются. Один устаревший индекс или политика доступа с неправильной областью действия могут повлиять на множество последующих решений. Рассматривая извлечение данных как легкое усовершенствование логики вывода, мы затушевываем его растущую роль как поверхности системного риска.

Свежесть извлечения — это системная проблема, а не проблема настройки.

Сбои в обновлении редко возникают при внедрении моделей. Они возникают в окружающей системе.

Большинству корпоративных систем извлечения данных сложно ответить на основные эксплуатационные вопросы:

• Насколько быстро изменения исходного кода распространяются на индексы?

• Какие потребители все еще запрашивают устаревшие представления?

• Какие гарантии существуют, если данные изменяются в середине сеанса?

На зрелых платформах актуальность обеспечивается посредством явных архитектурных механизмов, а не периодических перестроек. К ним относятся переиндексация на основе событий, внедрение версий и осведомленность об устаревших данных во время извлечения.

В корпоративных развертываниях повторяющаяся закономерность заключается в том, что сбои в обновлении редко возникают из-за качества внедрения; они возникают, когда исходные системы постоянно изменяются, а конвейеры индексирования и внедрения обновляются асинхронно, в результате чего получатели данных неосознанно работают в устаревшем контексте. Поскольку система по-прежнему дает плавные и правдоподобные ответы, эти пробелы часто остаются незамеченными до тех пор, пока автономные рабочие процессы не начнут зависеть от непрерывного поиска и проблемы с надежностью не выйдут на поверхность в масштабе.

Управление должно распространяться на уровень поиска

Большинство моделей управления предприятием были разработаны для независимого доступа к данным и использования моделей. Поисковые системы занимают неудобное положение между ними.

Неуправляемый поиск несет в себе несколько рисков:

• Модели, получающие доступ к данным за пределами их предполагаемой области применения

• Чувствительные поля просачиваются через вложения

• Агенты, получающие информацию, на которую они не уполномочены действовать.

• Невозможность восстановить, какие данные повлияли на решение.

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

Эффективное управление поиском обычно включает в себя:

• Индексы на уровне домена с явным владением

• API-интерфейсы поиска с учетом политик

• Журналы аудита, связывающие запросы с полученными артефактами

• Контроль междоменного поиска автономными агентами

Без этого контроля системы поиска незаметно обходят меры безопасности, которые, как предполагают организации, существуют.

Оценка не может ограничиваться качеством ответов

Традиционная оценка RAG фокусируется на том, кажутся ли ответы правильными. Этого недостаточно для корпоративных систем.

Сбои при получении часто проявляются перед окончательным ответом:

• Получены не имеющие отношения к делу, но правдоподобные документы.

• Отсутствие критического контекста

• Чрезмерное представление устаревших источников

• Тихое исключение авторитетных данных

Как системы искусственного интеллекта Становясь более автономными, команды должны оценивать поиск как независимую подсистему. Это включает в себя измерение запоминания в условиях политических ограничений, мониторинг отклонения новизны и выявление систематических ошибок, вызванных путями поиска.

В производственных средах оценка имеет тенденцию прерываться, когда поиск становится автономным, а не инициируемым человеком. Команды продолжают оценивать качество ответов по выборочным подсказкам, но им не хватает ясности в отношении того, что было получено, что было пропущено, а также повлиял ли на решения устаревший или несанкционированный контекст. Поскольку пути поиска в производстве динамично развиваются, бесшумный дрейф накапливается вверх по течению, и к тому времени, когда проблемы становятся очевидными, сбои часто ошибочно приписывают поведению модели, а не самой системе поиска.

Оценка, игнорирующая поведение при извлечении данных, оставляет организации слепыми к истинным причинам сбоя системы.

Плоскости управления, управляющие поведением поиска

Смодель плоскости управления для корпоративных поисковых систем, отделяющая исполнение от управления, чтобы обеспечить соблюдение политик, возможность аудита и непрерывную оценку. Концептуальная схема, созданная автором.

Эталонная архитектура: поиск как инфраструктура

Система поиска, разработанная для корпоративного ИИ, обычно состоит из пяти взаимозависимых уровней:

1. Уровень приема исходного кода: Обрабатывает структурированные, неструктурированные и потоковые данные с отслеживанием происхождения.

2. Слой внедрения и индексирования: Поддерживает управление версиями, изоляцию домена и контролируемое распространение обновлений.

3. Уровень политики и управления: Обеспечивает контроль доступа, семантические границы и возможность аудита во время извлечения.

4. Уровень оценки и мониторинга: Измеряет актуальность, отзыв и соблюдение политики независимо от результатов модели.

5. Уровень потребления: Обслуживает людей, приложения и автономные агенты с контекстными ограничениями.

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

Почему извлечение определяет надежность ИИ

По мере того как предприятия переходят к агентным системам и долгосрочным рабочим процессам искусственного интеллекта, извлечение информации становится основой, от которой зависят рассуждения. Модели могут быть настолько надежными, насколько надежен контекст, в котором они представлены.

Организации, которые продолжают относиться к поиску информации как к второстепенной задаче, столкнутся с:

• Необъяснимое поведение модели

• Пробелы в соблюдении требований

• Непостоянная производительность системы

• Эрозия доверия заинтересованных сторон

Те, кто возводит извлечение данных в инфраструктурную дисциплину — управляемую, оцениваемую и спроектированную для изменений, — получают основу, которая масштабируется как с автономией, так и с риском.

Заключение

Извлечение больше не является вспомогательной функцией корпоративных систем искусственного интеллекта. Это инфраструктура.

Свежесть, управление и оценка не являются дополнительными оптимизациями; они являются предпосылками для развертывания систем искусственного интеллекта, которые надежно работают в реальных средах. По мере того, как организации выходят за рамки экспериментального развертывания RAG и переходят к автономным системам поддержки принятия решений, архитектурная обработка поиска будет все больше определять успех или неудачу.

Предприятия, которые осознают этот сдвиг на ранней стадии, будут иметь больше возможностей для ответственного масштабирования ИИ, выдержат проверку со стороны регулирующих органов и сохранят доверие по мере того, как системы станут более функциональными и более значимыми.

Варун Радж — руководитель отдела разработки облачных технологий и искусственного интеллекта, специализирующийся на модернизации облачных технологий в масштабе предприятия, архитектурах с использованием искусственного интеллекта и крупномасштабных распределенных системах.

Добро пожаловать в сообщество VentureBeat!

В нашей программе гостевых публикаций технические эксперты делятся своими идеями и нейтральными, не имеющими никаких прав глубокими знаниями об искусственном интеллекте, инфраструктуре данных, кибербезопасности и других передовых технологиях, формирующих будущее предприятия.

Читать далее из нашей программы гостевых постов — и ознакомьтесь с нашим руководящие принципы если вы заинтересованы в написании собственной статьи!