Transcription
Сейчас в области ИИ идет огромная гонка за определение следующего поколения RAG. Хотя вы, вероятно, слышали заявления о том, что RAG умер, уже слишком много раз, они часто преувеличены, а решения, как правило, слишком упрощены. Многие игроки в индустрии сходятся во мнении о концепции слоя знаний или контекста между вашим агентом и его базовыми источниками данных как гораздо лучшей альтернативе традиционному RAG. Но нет большого согласия относительно того, как на самом деле выглядят эти решения, и они, как правило, не являются универсальными. И теперь Reddus, один из настоящих пионеров в области высокоскоростного извлечения данных, только что анонсировал Iris с архитектурой, которую действительно стоит серьезно рассмотреть, если вы создаете ИИ-агентов, полагающихся на большие, быстро меняющиеся данные, распределенные по множеству различных источников данных, потому что это серьезные слабости большинства систем извлечения ИИ. И, кстати, мы не имеем никакого отношения к Reddus. Мы, по сути, никогда не делали спонсированных видео на этом канале, но мы все можем черпать вдохновение из архитектуры Reddis здесь, даже не используя их стек напрямую. Давайте начнем с некоторого контекста. Несколько месяцев назад генеральный директор Reddus сказал: «Я видел меньше примеров реальных успешных производственных агентов, чем ожидал, в любом случае, кроме инженерии». И, честно говоря, ИИ-агенты часто не оправдывали ожиданий в производственных системах в целом. И существует огромный разрыв между эффектной демонстрацией и той, которая выдерживает реальные данные и реальные сценарии использования. Он также написал в этом посте в блоге: «Самые сложные проблемы в производственном ИИ больше не решаются выбором модели. Они проявляются во время выполнения. Устаревшее состояние, медленное извлечение, фрагментированная память, отключенные инструменты и сессии, которые не накапливаются». И пример, который он приводит здесь, — это бот поддержки клиентов. Клиент может спросить: «Почему мой заказ задерживается?» Подумайте обо всем, что нужно агенту, чтобы фактически ответить на этот вопрос, особенно в крупных организациях, таких как база данных клиентов, система заказов, поставщик доставки, инструмент для обработки заявок и документы с политиками. Наивный RAG почти никогда не будет работать в таких сценариях использования, и это все еще может быть довольно сложной задачей для многих конфигураций агентского RAG. Мы уже освещали подобные решения на нашем канале, например, предоставление вашему ИИ-агенту ограниченного доступа к представлению вашей базы данных только для чтения, и мы очень глубоко погружаемся в стратегии агентского извлечения в нашем курсе AI Architects, ссылка на который находится в описании. Но давайте посмотрим, что именно предлагает Reddus. Прежде чем углубляться, у них есть хороший список требований для агентов, чтобы они могли функционировать в масштабе. Конечно, все упомянутое здесь является фокусом их продуктового предложения, но это все еще хороший список, чтобы дать некоторый контекст заранее. Во-первых, агент должен уметь перемещаться по большому объему данных. Он должен уметь traversing отношения, понимать сущности, обнаруживать релевантный контекст и так далее. Во-вторых, контекст должен быть извлекаемым быстро, что в большинстве случаев является очень реальным требованием. Системы агентского RAG часто могут быть очень медленными, если за кулисами у них есть качественные стратегии извлечения, и они могут проходить через множество циклов для извлечения правильной информации. В-третьих, контекст всегда должен быть актуальным. Конвейеры извлечения агентов часто слишком медленны для чего-либо близкого к реальному времени, и данные, которые агент извлек 10 минут назад, могут быть уже устаревшими и неактуальными. И четвертое — это аспект самосовершенствования, что большинство ИИ-агентов на самом деле не запоминают взаимодействия, информацию и контекст так, как должны. Итак, что именно такое Reddus Iris и как они собираются решать эти проблемы и соответствовать этим требованиям? Во-первых, Iris — это стек сервисов Reddus, и не все из них новые. Iris только что был анонсирован на момент записи этого видео. Так что это определенно не практическое руководство или обзор их сервиса, а скорее объяснение архитектуры извлечения, которую они используют, которая сильно отличается от многих других решений контекстного слоя ИИ в индустрии. На очень высоком уровне у вас есть данные в исходных системах, Oracle, Postrest, MongoDB, и у вас есть эта интеграция данных Reddus, которая постоянно фиксирует изменения и синхронизирует их в структуры данных Reddus. Таким образом, у вас есть операционная копия данных в Reddus. Затем ваш агент может взаимодействовать с этими данными, используя извлекатель контекста Reddus, который предоставляет агенту инструменты CLI и MCP. Мы поговорим об этом через минуту. Затем память агента Reddus пытается сохранять то, что он узнает, между сессиями, используя комбинацию как краткосрочной, так и долгосрочной памяти. А затем кэш Reddus LAN кэширует ответы и пытается обойти все, что уже было отвечено ранее. Таким образом, ваш агент никогда не обращается напрямую к операционным данным. Он взаимодействует с данными в базе данных Reddus, которая была синхронизирована через интеграцию данных Reddus через MCP или CLI, предоставленные извлекателем контекста Reddus. Итак, давайте углубимся в эти компоненты, потому что у вас, вероятно, больше вопросов, чем ответов на данный момент. Начнем с самого начала с этой интеграции данных Reddus, которая в настоящее время находится в публичном предварительном просмотре. RDI реализует шаблон захвата изменений данных для синхронизации данных из исходной базы данных, такой как Postgress или Oracle, Snowflake или, и отслеживает это и обновляет данные в структурах данных Reddit. Именно так Iris удовлетворяет требованиям, которые мы упомянули ранее, — быть всегда актуальным. RDI зеркалирует свежую копию ваших данных для агента, чтобы он мог обращаться к ней с высокой скоростью, а Reddus — эксперты в молниеносном извлечении. Так что я бы не сомневался в них в этом отношении. И поскольку они делают копию данных из операционных систем, это означает, что агент не будет бомбардировать транзакционные системы запросами, потому что прямой доступ к операционным данным может быть большой проблемой для загруженных агентских систем, где агенты могут делать в тысячи раз больше запросов, чем человек. Это также означает, что данные могут быть смоделированы таким образом, который более эффективен как с точки зрения скорости, так и индексации, а также в более плоской, денормализованной структуре, что значительно облегчит взаимодействие агентов с ними через инструменты. Конечно, идея копирования операционных данных в другой источник не нова. Такой подход часто используется, например, для аналитики и кэширования. Далее, извлекатель контекста Reddus — это тот, который стремится удовлетворить требование агента к возможности навигации по вашей базе знаний. Идея здесь заключается в том, что вы определяете модели ваших бизнес-данных, сущностей, полей и отношений, и эти модели затем могут быть выполнены через MCP или CLI вашим агентом. Затем вы можете определить данные, к которым вы хотите предоставить доступ своему агенту, вместе с контролем доступа на уровне ролей. Так что ваши сущности могут быть, например, продукт, клиент или заказ. А затем у вас есть инструменты. Это инструменты, которые ваш агент сможет вызывать на основе этих данных. Например, найти продукт по диапазону, получить клиента по ID, искать клиентов по тексту, фильтровать по тегам, фильтровать продукт в наличии. Таким образом, у вас есть множество различных операций, таких как фильтрация, поиск, получение, поиск. Таким образом, это дает агенту инструменты для более легкого доступа к вашим данным по мере необходимости, не пытаясь заставить вашего агента объединять данные из множества различных таблиц или из разных источников данных, что может быть невероятно ненадежным в агентском RAG. Память агента Reddus включает функции как краткосрочной, так и долгосрочной памяти. Для краткосрочной памяти вы можете установить пользовательский TTL, который будет очень важен для систем, где исходные данные могут меняться очень, очень часто. А затем у них есть долгосрочная память, которая хранит извлеченные прошлые сессии, пользовательские предпочтения, изученные закономерности и другие релевантные данные. И это одно из многих решений для памяти в индустрии. Например, у вас есть mem zero, honcho, dep graffiti. У нас есть функции типа dreaming в облачных управляемых агентах и openclaw, которые я рассмотрел в предыдущем видео, и многое другое. Но как работает память Reddus, во-первых, у нас есть краткосрочная память, которая является памятью сессии. И это очень важно для поддержания текущего состояния разговора и истории сессии. Таким образом, краткосрочная память будет храниться временно. И определенные элементы, пользовательские предпочтения, закономерности и другие релевантные данные могут быть переведены в долгосрочную память, в противном случае они просто удаляются в соответствии с политикой TTL. Затем у вас есть сервис LANCA. Таким образом, вместо того, чтобы вызывать вашу LLM для каждого запроса, вы можете использовать lang cache, чтобы проверить, был ли похожий ответ уже сделан ранее, и если да, то мгновенно вернуть его из кэша, чтобы сэкономить время и деньги. Звучит здорово. Семантическое кэширование может быть очень полезным для ваших проектов, но это также потенциальная минное поле, где вы можете получить похожие прошлые ответы, которые на самом деле не в контексте. При поиске в кэше вы можете искать по порогам сходства, а также по стратегиям поиска, используя либо точный поиск, либо семантический поиск. Это могут быть довольно грубые инструменты. Поэтому вам действительно нужно тщательно оценивать системы, использующие кэширование ответов подобным образом. Данные запрашиваются в системе с помощью Reddus search, который может искать векторные, структурированные и неструктурированные данные в одном индексе. Здесь вы можете увидеть некоторые запросы Reddus search, похожие на SQL, но со своим собственным синтаксисом. И существует множество различных типов запросов: точное совпадение, диапазон, полнотекстовый, геопространственный, векторный, комбинированный и агрегирующий. Reddus также утверждает, что вы можете легко масштабироваться до 1 миллиарда векторов, используя их индексы, что довольно много. А затем у них также есть Reddis Flex, который представляет собой новый уровень хранения на основе SSD, который они предлагают. Таким образом, вы не платите за все, что работает в памяти, что действительно может иметь значение с точки зрения ценообразования. Таким образом, здесь Reddus очень признает, что вы не можете просто волшебным образом решить проблему извлечения с помощью очень простого слоя. Это требует модульного стека. Вам нужно несколько сервисов вместе, и вам нужно быть очень внимательным к тому, как вы их используете. И очень важно смотреть за пределами маркетинга. Извлечение здесь, безусловно, не является решенной проблемой просто путем регистрации учетной записи Reddus. Это не plug-and-play, и потребуется обслуживание, чтобы убедиться, что форма вашего слоя извлечения соответствует исходным операционным данным. И вам нужно моделировать ваши исходные данные вместе с отношениями. Недавно на нашем канале Даниэль освещал Pine Cone Nexus, который является еще одним подходом к знаниевому слою для ваших ИИ-агентов, но это совершенно другая архитектура. Новое предложение Pine Cone здесь идет до времени сборки. Он предварительно компилирует типизированные артефакты знаний, связанные с продажами, финансами, поддержкой и маркетингом. Таким образом, агент запрашивает предварительно сформированный ответ вместо того, чтобы извлекать его при каждом вызове. В то время как Reddus здесь идет до времени выполнения. Он не пытается предварительно вычислить что-либо в скомпилированный слой знаний. Он делает структуры данных быстрыми и навигируемыми. Таким образом, агент извлекает свежий контекст по запросу, поскольку он быстро меняется. И эти два варианта четко разделены по своим сильным сторонам. Pine Cone, скорее всего, будет силен там, где у вас есть большая стабильная база знаний с повторяющимися известными вопросами, контрактами, руководствами по соответствию и тому подобным, где предварительно скомпилированный артефакт идеально подходит. При использовании движка знаний Pine Cone или чего-либо вроде идеи вики Капати, всякий раз, когда исходные данные меняются, вам нужно перекомпилировать то, что находится в слое знаний. В то время как архитектура Reddus здесь будет гораздо более подходящей для сред с очень быстро меняющимися данными, потому что в этих случаях предварительно скомпилированный артефакт в слое знаний может устареть через 5 минут после его создания. При оценке решений для извлечения данных мы часто имеем в виду сценарий использования из прошлого опыта или конкретных проектов, над которыми мы работали. И, безусловно, есть сегмент профессионалов в области программного обеспечения, которые закатывают глаза, когда видят идею вики Капати или идею Pine Cone Nexus о скомпилированном слое знаний. Они, вероятно, будут думать о сценариях использования, где базовые данные очень регулярно меняются. И хотя такой тип архитектуры может быть довольно сложным, он может быть необходим для создания надежного рабочего ИИ-агента в производстве. Если отступить, то действительно нет универсального решения для извлечения. Традиционный RAG и более простые решения агентского RAG часто рекламировались как волшебное решение, но на самом деле эффектные демонстрации часто не приводят к надежным производственным системам. Глубокое погружение в стратегии извлечения было нашим основным фокусом на этом канале и в сообществе в течение довольно долгого времени. И если вы хотите спроектировать контекстный слой и слой извлечения, который действительно будет работать в производстве, именно это мы освещаем в нашем модуле агентского извлечения в рамках курса AI Architects в нашем сообществе, ссылка на который находится ниже в описании. И я также настоятельно рекомендую вам посмотреть наше недавнее видео, посвященное Pine Cone Nexus, которое Даниэль рассмотрел на нашем канале, которое использует совершенно другую архитектуру для своего слоя знаний, чем архитектура Reddus Iris, рассмотренная в этом видео. Спасибо за просмотр.