Transcription
Жар. Жар. [музыка] [музыка] [музыка] [музыка] >> [музыка] [музыка] >> Отлично. Привет всем. Большое спасибо, что нашли время присоединиться к нам для очередного выпуска серии "Базы данных для ИИ". Эм, так что, если вы разработчик, работающий над созданием приложений RAG, возможно, вы уже начали экспериментировать с приложениями Graph RAG или просто интересуетесь графами, как и многие из нас, тогда вы сегодня в нужном месте, потому что мы покажем вам, как построить агентную систему Graph RAG менее чем за час. Ээ, меня зовут Мелисса. Я архитектор специализированных решений Neptune, и я буду вашим ведущим сегодняшнего выпуска. Со мной также наш супер особенный гость Иэн. Эм, если Иэн, ты хочешь быстро представиться. >> Всем привет. Меня зовут Иэн. Ээ, я архитектор графов в команде Amazon Neptune. >> Отлично. Спасибо, Иэн. Эм, так что да, как архитектор специализированных решений Neptune, я получаю много запросов от клиентов, людей, использующих Neptune, обо всем, что связано с графами и Neptune, но кажется, что в последнее время многие запросы и вопросы, которые мы получаем, действительно сосредоточены на том, как сделать наши приложения RAG более точными? Как дать им больше контекста? Как уловить некоторые недостающие семантические элементы и детали, которые чистый поиск RAG может упустить? И поэтому традиционным ответом на это было использование Graph RAG. И просто для краткого обзора, если вы смотрели некоторые из наших предыдущих выпусков этой серии "Базы данных для ИИ", вы могли видеть, что мы провели несколько предыдущих выпусков, посвященных графам в целом. Мы немного поговорили о Graph RAG, что это такое, зачем он вам может понадобиться, когда он будет отличным решением. Эм, и мы разместим ссылки в чате, на случай, если вы захотите наверстать упущенное. Но просто для очень быстрого обзора, чтобы задать сцену для агентного Graph RAG, о котором мы будем говорить сегодня, я хотел быстро поговорить о том, что такое Graph RAG. Эм, так что, если вы знакомы со стандартным конвейером RAG, он на самом деле очень похож на то, как будет выглядеть архитектура Graph RAG. Эм, так что здесь, мы снова начинаем с наших источников данных. Мы загрузим их, разделим на части, сгенерируем эмбеддинги, поместим эти эмбеддинги в наше векторное хранилище, но мы действительно обогащаем этот процесс графом, который поможет предоставить дополнительный контекст потоку, который помогает уловить не обязательно схожую информацию, верно? Это может быть несхожая информация, но она все равно может быть релевантна исходному вопросу, верно? И в этом действительно заключается ценность Graph RAG. И один из моих любимых примеров, который я всегда люблю показывать, конечно же, это наш пример с перспективными клиентами компании. И этот [кашляет] действительно отличный простой пример, который улавливает добавленную стоимость графа в потоке Graph RAG. И в качестве примера здесь у нас может быть репозиторий статей о компании, о продажах, о дистрибьюторах, которых она использует. И, верно, если мы сгенерируем для него некоторые фрагменты, и мы пытаемся ответить на этот вопрос с помощью стандартного векторного потока RAG, мы видим, что чат-бот может извлечь из этого, выполнить векторный поиск, и мы сопоставим наиболее семантически схожие фрагменты, которые будут этими синими. И хотя это семантически схоже, и мы можем вывести из этого ответ, верно, что продажи будут отличными, мы на самом деле видим, как люди, что мы упускаем некоторый дополнительный контекст внизу. И поэтому это действительно те дополнительные детали информации, которые имеют решающее значение и могут быть упущены как часть простого стандартного векторного потока. Эм, так что я просто хотел быстро задать сцену с этим дополнительным контекстом о Graph RAG, потому что мы много говорили просто о Graph RAG как об архитектуре. Мы говорили в более общем плане о том, как мы можем соединить граф с агентами для запроса графов с помощью агентов, но сегодня мы действительно объединим все эти различные компоненты в то, что мы называем агентным Graph RAG. И поэтому я думаю, что это действительно подводит нас к вашему вопросу, Иэн, о том, что, как мне кажется, Graph RAG был такой горячей темой в последнее время. Мы понимаем в общих чертах пробелы, которые Graph RAG помогает преодолеть по сравнению со стандартным векторным RAG, но теперь мы переходим к агентному Graph RAG. Так как вы определяете агентный Graph RAG и какие пробелы покрывает агентный Graph RAG, которые сам по себе Graph RAG может не обязательно решать. >> Да, я думаю, [смех] агентный Graph RAG или любое агентное решение — это, по сути, добавление слоя дополнительного интеллекта поверх наших решений RAG. Таким образом, мы предоставляем некоторую экспертизу в предметной области. Мы фактически создаем системы, которые могут применять некоторую экспертизу в предметной области для решения действительно очень сложных проблем. Так что Graph RAG "из коробки" или традиционный векторный RAG не обладают большим интеллектом. Знаете, вы сказали, что Graph RAG очень полезен для поиска некоторой очень релевантной информации, где нам приходится отслеживать некоторые связи в данных. Мы можем использовать векторный RAG для поиска вещей, которые очень похожи на задаваемый вопрос. Мы можем использовать граф для отслеживания дополнительных связей, поиска некоторого неочевидного контента и объединения этих двух наборов информации для получения хорошего ответа. Так что, по сути, с помощью RAG мы находим некоторый контент, а затем передаем его LLM с подсказкой и говорим: "Учитывая эти доказательства, пожалуйста, ответьте на этот вопрос". Но там не так много интеллекта. нам приходится создавать приложение или создавать набор ретриверов, которые знают, как искать эту информацию. А затем мы просто представляем LLM все, что мы нашли. Ну, когда мы думаем о том, как мы, как эксперты в реальном мире, решаем проблемы, мы склонны принимать более итеративный или инкрементальный подход. Мы приходим с целым набором стратегий для решения проблемы. И поэтому мы можем начать решать конкретную проблему, собирая некоторую информацию, просматривая, как выглядит первоначальная ситуация, а затем, основываясь на нашем понимании того, как обстоят дела, мы будем выбирать среди других стратегий, чтобы затем иметь возможность дальше развивать решение проблемы. Так мы ведем себя как настоящие эксперты. И я думаю, что все мы пытаемся сделать сегодня при создании приложений genai — это включить некоторые из этих экспертных поведений в наши системы. И вот где агентный подход может помочь, где агент фактически ведет себя как эксперт. И мы снабжаем этого агента целым набором инструментов и возможностей, а также фрагментами знаний предметной области. И тогда мы говорим: "Эй, вот очень сложная проблема, которую я хочу, чтобы ты решил. Ты сам выяснишь, как ты собираешься ее решить. Используй эти инструменты, примени эти знания, эти знания предметной области и верни ответ". >> И поэтому, добавляя Извините, продолжайте. >> О, нет. Я просто хотел быстро вклиниться с комментариями Реджинальдо. Он поднимает хороший вопрос о свежести данных. Я думаю, что это также распространенный вопрос, который мы получаем даже в обычном потоке Graph RAG о том, как мы поддерживаем вещи в актуальном состоянии. Так что было бы здорово, если бы, пока мы проходим через это, мы могли бы коснуться аспекта свежести, а затем и того, как мы поддерживаем граф в актуальном состоянии как часть этого потока. >> Да. Да. Я имею в виду, это действительно важно, не так ли? Потому что, когда мы, опять же, как люди и человеческие эксперты, пытаемся решить проблему, мы хотим иметь доступ к самой свежей информации. И поэтому мы хотим иметь возможность доверять тому, что любые инструменты или любые источники информации, доступные нам, предоставляют нам хорошие, честные, свежие данные. Так что я думаю, что по мере того, как мы будем проходить несколько демонстраций, мы поговорим о способах поддержания этих данных и их свежести. Но, очевидно, это очень важно для того, чтобы производить точные, своевременные и исчерпывающие решения проблем. Нам нужен доступ к этой действительно релевантной информации. Да. И я думаю, что когда мы говорим об агентном Graph RAG, мы фактически говорим, что в рамках агентного решения мы можем добавить некоторые возможности Graph RAG. Мы можем использовать базовый граф и способы, которыми мы представили все, что нас интересует, как набор связанных данных. Мы будем использовать это для отслеживания этих связей, поиска свежей, релевантной, неочевидной информации и позволим агенту использовать эти возможности. Это начинает итеративно работать над решением проблемы. >> Да. >> Отлично. Так, это звучит потрясающе. Я думаю, мой вопрос будет таким: если я начинаю с нуля, как бы, у меня нет графа, как проще всего это начать? Так что я думаю, я проведу очень простое различие между тем, что мы можем назвать графом знаний, и другими графовыми решениями, которые фактически индексируют текстовый контент. И граф знаний, с одной стороны, является очень точным представлением того, что действительно нас интересует. И то, что мы увидим через минуту, это демонстрация мошенничества, где у нас есть набор данных графа, который представляет счета и транзакции, а также информацию об удостоверении личности, связанную с этими счетами. И чтобы начать там, на самом деле все еще требуется немало усилий, потому что как разработчик я должен подумать: ну, какое идеальное представление моей предметной области? Как я собираюсь моделировать это как граф? Какие вопросы я ожидаю смочь задать и ответить из этого графа? Это своего рода предварительная информационная архитектура, но конечным результатом является то, что у меня есть очень, очень мощный набор данных, который представляет то, что меня действительно интересует, и я могу задавать ему очень, очень сложные вопросы. И я думаю, что со стороны Neptune у нас есть некоторые инструменты, которые могут помочь всем нашим разработчикам начать моделировать эти предметные области и создавать запросы и визуализации. Но, как я уже сказал, я назову это графом знаний. Есть много разных способов описания графов знаний, но это моя простая версия. Это, знаете ли, точное представление того, что в нашей предметной области нас действительно очень интересует. >> Отлично. Отдельно есть, мы часто имеем много информации в неструктурированных или полуструктурированных документах в текстовых документах или файлах markdown или даже JSON документах, таких как это. И один из самых простых способов начать создавать сначала решение Graph RAG, а затем решение агентного Graph RAG на основе такого контента — это использовать такие вещи, как интеграция Neptune Bedrock, которая позволит вам автоматически принимать все эти данные и создавать своего рода возможность Graph RAG. Это полностью управляемая возможность, которую мы предлагаем через Bedrock через базы знаний Bedrock или, опять же, в одной из демонстраций мы увидим это более подробно. У нас есть набор инструментов Graph RAG с открытым исходным кодом, который фактически позволит вам принимать все эти неструктурированные и полуструктурированные документы. И набор инструментов автоматически построит для вас граф. Это не граф знаний. Это граф, который предоставляет очень мощный индекс для всего этого текстового контента. А затем набор инструментов фактически предоставляет вам движок запросов, который позволяет вам начать задавать вопросы к вашим данным. И то, что мы увидим немного позже, это то, как этот набор инструментов также включает некоторые функции, которые автоматически создадут набор инструментов, которые вы можете использовать в агентном решении. Так что, если у вас есть неструктурированные или полуструктурированные данные, самый простой способ начать — это либо через базы знаний Bedrock, либо через набор инструментов Graph RAG. Если вы хотите создать один из этих более высококачественных графов, подобных графам знаний, есть, возможно, другие инструменты, о которых мы можем поговорить или на которые мы можем сослаться в конце шоу, которые могут помочь вам с некоторым моделированием и прикладной информационной архитектурой. >> Отлично. И просто чтобы вклиниться в это, спасибо Реджинальдо за ваш вопрос, говоря немного о том, как Neptune вписывается в архитектуру, которую только что обсуждал Иэн. Так есть ли у Neptune какие-либо возможности поиска сходства или вам нужно сопоставить эти узлы во внешней векторной базе данных? Так что в зависимости от архитектуры, которую вы хотите построить, я думаю, есть пара вариантов, верно, Иэн? >> Да, есть. Да. [фыркает] Итак, во-первых, для тех, кто смотрит и не очень знаком с Neptune, просто скажу, что Neptune — это управляемая графовая база данных Amazon, но на самом деле у нее есть два разных движка. Есть движок базы данных Neptune, который вы можете рассматривать как своего рода SQL для нее, это графовая база данных для онлайн-транзакций для хранения очень, очень больших наборов данных. А затем отдельно у нас есть другой движок под названием Neptune Analytics, который является графовым движком, оптимизированным для памяти. Neptune Analytics также позволяет хранить векторные эмбеддинги как часть графа. Так что, если вы строите решение, которое использует Neptune Analytics, вы можете смоделировать все и смоделировать все как граф, хранить его в Neptune Analytics. Вы также можете генерировать эмбеддинги. Вам придется делать это внешне, возможно, через Bedrock, но затем вы можете хранить эти эмбеддинги в графе. И вы можете использовать языки запросов к графам, которые мы предоставляем с Neptune Analytics, для проведения векторного поиска сходства и использования этого в качестве отправной точки для графового запроса, который затем отслеживает все эти связи в графе. Или вы можете начать обычный обход графа, а затем, когда вы найдете что-то в графе, что вас действительно интересует, если у них есть связанные с ними эмбеддинги или прикрепленные к ним, вы можете использовать это для проведения поиска сходства. Так что это один подход. Neptune Analytics позволяет вам объединить поиск сходства графа и вектора в одной базовой технологии. Отдельный подход, и это подход, который мы приняли в этом наборе инструментов с открытым исходным кодом, заключается в создании логического различия между графовым хранилищем и векторным хранилищем, а затем в создании API для них обоих, чтобы я мог запрашивать векторное хранилище, находить интересующие меня вещи посредством поиска сходства, а затем использовать эти результаты для графового поиска в графе. И снова в наборе инструментов набор инструментов фактически поддерживает несколько бэкендов. Он поддерживает базу данных Neptune, Neptune Analytics, векторы S3, OpenSearch, Postgress с расширением PG vector. В зависимости от того, какой из этих бэкендов вы выберете, возможно, если вы используете Neptune Analytics, графовое хранилище и векторное хранилище фактически будут указывать на один и тот же базовый экземпляр. Помогает ли это ответить на вопрос? >> Да, я думаю, вы идеально это осветили. Да. Итак, чтобы подытожить, базы знаний Bedrock, Graph RAG. Если бы я хотел пойти по этому пути, я мог бы использовать это с Neptune Analytics, и это был бы пакет "все в одном". А затем, если бы я хотел смешивать и сочетать мои хранилища, набор инструментов графа был бы хорошим вариантом для этого. И он бы позаботился о том, чтобы позаботиться обо мне о своего рода сопоставлении между узлами в графе и соответствующими векторами в OpenSearch. Так что, да, это было бы позабочено обо мне, так что мне не придется слишком много об этом думать. >> На самом деле, и я думаю, что это очень важный момент. Так что, вы знаете, мы говорили об интеграции Neptune Bedrock и наборе инструментов, и в обоих случаях эти сервисы, с одной стороны, библиотека с открытым исходным кодом, с другой стороны, выполняют это сопоставление от вашего имени. Но если вы создаете свои собственные решения Graph RAG и хотите объединить векторный поиск с графовым поиском, вам придется подумать о том, как вы будете сопоставлять вперед и назад между ними. Так что результаты, возвращаемые из поиска сходства верхнего уровня, в идеале должны иметь некоторую ссылку на узлы в графе, которые вы можете использовать, чтобы затем начать обход графа или графовый запрос. >> Так что, я думаю, когда мы думаем о том, как набор инструментов Graph RAG вписывается в агентный Graph RAG, я думаю, я мысленно пытаюсь понять, какая связь, если мы хотим сделать агентный Graph RAG. Как это работает, если мы выбираем использование набора инструментов графа для построения этого? >> Так [фыркает] давайте подумаем о общей архитектуре агентного решения. Как я уже сказал, то, что мы хотим сделать здесь, это то, что вы хотите построить систему или приложение, в которое мы включили некоторые знания предметной области, некоторую экспертизу. мы фактически заставляем систему вести себя как эксперт. Способ, которым мы делали это десятилетиями, — это жестко кодировать всю эту логику принятия решений в приложении. Но тогда мы обнаруживаем, что это довольно хрупкий способ решения проблемы. Он работает сегодня очень, очень хорошо, пока мы готовы следовать этим шагам. но что-то там в вашем бизнесе меняется, появляются новые требования, и нам приходится пересматривать и обновлять все это заново. С агентным решением мы фактически говорим: "Послушайте, вот агент на основе LLM, который мы будем снабжать или давать некоторые инструкции, некоторые знания предметной области, которые описывают, как он должен себя вести. И мы также дадим ему некоторые инструменты, которые он может использовать для решения проблемы. Так что мы даем ему некоторые знания и инструменты, которые он может использовать на основе этих знаний, а затем мы позволим ему решить проблему. Он сам выработает свой пошаговый подход к решению проблемы, и он может сделать пару шагов вперед и вернуться, чтобы решить. Способ, которым набор инструментов Graph RAG может помочь здесь, заключается в том, что он может автоматически создавать то, что я называю инструментами, специфичными для предметной области, инструментами, которые тесно связаны с базовым набором данных, и он может предоставлять эти инструменты агенту. Теперь многие агентные решения будут иметь не только граф как часть базового набора инструментов. У них может быть много других инструментов, которые указывают на другие бэкенды. Но там, где мы внедрили набор инструментов для предоставления агенту некоторых возможностей графа, набор инструментов очень, очень упрощает автоматическое создание инструментов, которые являются описательными или репрезентативными для нашей предметной области. они естественным образом включают много знаний о нашей предметной области, потому что набор инструментов автоматически интроспектирует базовые данные и говорит: "Эй, я думаю, что этот базовый набор данных представляет собой набор рабочих руководств или набор документов о политике, так что, эй, посмотрите, у меня есть база знаний или у меня есть инструмент, который знает все о рабочих руководствах для решения проблем x, y и z, и мы рекламируем это агенту, а затем агент, получив проблему, если он считает, что уместно использовать этот инструмент, эти рабочие руководства или эти документы о политике, он автоматически вызовет его. Так вот как набор инструментов делает эти вещи действительно, действительно простыми. Он автоматически создает инструменты, которые вы можете включить в агентное решение. >> Отлично. Круто. Так что, может быть, посмотрим на это в действии? Я очень хочу увидеть, как все это работает. Я работал с набором инструментов Graph RAG раньше, но не с точки зрения пользовательских инструментов предметной области. Так что >> будет интересно посмотреть, как все это соберется воедино. >> Да. И я думаю, когда Мелисса и я обсуждали, как мы хотели бы решить некоторые из этих проблем ранее, мы выделили три разных способа, которыми вы можете включить граф и графовые возможности в ваши агентные решения сегодня. Так что мы рассмотрим эти три подхода. Это не обязательно "или-или", знаете ли, каждый подход актуален для определенного набора проблем, но замечательная вещь в агентных решениях заключается в том, что мы всегда можем добавлять больше инструментов. Мы всегда можем представить агенту больше инструментов. Так что вы можете фактически комбинировать или смешивать и сочетать три разных подхода, которые мы рассмотрим сегодня. Итак, сначала мы рассмотрим два примера создания инструментов, которые мы даем агенту, которые указывают на один из этих графов знаний. Одна из тех вещей, о которых я говорил ранее, где у нас есть очень точное представление конкретной предметной области. кто-то вложил время, чтобы создать хорошую информационную архитектуру и построил, заполнил и поддерживал в актуальном состоянии набор данных вокруг конкретной предметной области. И это будет демонстрация мошенничества, и я думаю, что в предыдущих прямых трансляциях мы уже использовали пример демонстрации мошенничества. Итак, мы рассмотрим это в первую очередь. А затем третий пример — это пример, где у нас есть этот неструктурированный и полуструктурированный текстовый контент, который мы приняли в набор инструментов. И мы покажем, как набор инструментов автоматически выводит, о, вот какие инструменты я могу создать и передать агенту. Хорошо. Итак, я >> И для тех, кто заинтересован в том, чтобы следить за этим, у нас есть все примеры и некоторые примеры мошенничества, которые Иэн упоминает из прошлых выпусков. Мы разместим эти ссылки в чате, так что у вас будет доступ к их прохождению самостоятельно. Так что >> Круто. Итак, давайте начнем с этого примера мошенничества. Итак, здесь у меня есть простая диаграмма, иллюстрирующая базовую модель данных графа для этих данных о мошенничестве. Так что я сказал, что это кто-то применил тщательную информационную архитектуру, чтобы разработать модель графа, которая очень, очень полезна для выявления таких вещей, как мошеннические кольца. Так что вы можете видеть, что в наших базовых данных графа у нас будет много разных счетов, и многие транзакции, где эти счета имели транзакции с торговцами. И каждый счет связан с одним или несколькими фрагментами информации об удостоверении личности. Так что, когда мы регистрируем счета, мы собираем такие вещи, как физический адрес, дату рождения человека, адрес электронной почты и так далее. И для целей демонстрационного приложения по борьбе с мошенничеством мы обычно извлекаем эти фрагменты информации об удостоверении личности и представляем их как отдельные узлы, потому что это позволяет нам находить счета, которые используют несколько фрагментов информации об удостоверении личности. И это часто является ключевым признаком того, что мы имеем дело с людьми или группами людей, которые ведут себя мошенническим образом. Хорошо, так это базовые данные. Эта диаграмма или эта визуализация просто показывает небольшую подмножество данных, которые есть в нашем базовом графе. Так что вы можете видеть все, что здесь красное. Это разные счета. Различные фрагменты информации об удостоверении личности синие. Так что у нас есть такие вещи, как адрес электронной почты, дата рождения, номер телефона, а затем у нас есть все различные транзакции, где эти счета покупали услуги или продукты у разных торговцев. Так что это просто, чтобы дать вам представление о базовых данных, с которыми мы работаем. Хорошо. Теперь первый подход, который мы можем принять, если мы хотим включить некоторые возможности обнаружения мошенничества в наше агентное решение или мы создаем агентное решение, которое отвечает за выявление и оценку потенциально мошеннического поведения. Первый способ, которым мы можем это сделать, — это создать агента и дать ему некоторые знания. Скажем, "Эй, смотри, ты агент. Ты отвечаешь за обнаружение мошенничества, и у тебя есть доступ к графовой базе данных и набору данных графа, который представляет всю эту информацию". Так что мы очень явно говорим. Мы фактически говорим агенту что-то о базовых данных. Мы говорим, что когда тебе будет предложена проблема для решения, ты можешь написать любой запрос к этим базовым данным, чтобы решить эту проблему или ответить на конкретный вопрос. Так что мы фактически позволяем агенту действовать как хороший инженер данных или специалист по базам данных. Хорошо. Так что это первый подход, который мы предпримем. И чтобы сделать это, мы будем использовать еще одно программное обеспечение под названием сервер Amazon Neptune MCP. Так что сервер Amazon Neptune MCP доступен на GitHub Labs. Его очень легко настроить, и вы увидите, что именно это я делаю в этой ячейке здесь. Я создаю локальный экземпляр, который работает на этом экземпляре ноутбука сервера Amazon Neptune MCP. И я сообщил этому серверу, где находится моя графовая база данных. Я дал ему конечную точку графа этого набора данных. И поэтому этот сервер MCP теперь может быть предложен в качестве клиента для агента. Так что очень простой код для создания клиента, который позволит агенту взаимодействовать с этим сервером MCP. И этот сервер MCP, в свою очередь, будет перенаправлять запросы в базовую графовую базу данных. Следующее, что у меня есть здесь, — это подсказка. Так что это та подсказка, которую я собираюсь дать моему агенту. И вы можете видеть, что мы говорим ему, как я хочу, чтобы ты себя вел. Ты агент по расследованию мошенничества. Так что мы говорим ему немного о его роли. А затем мы предоставляем ему некоторые дополнительные рекомендации. И интересная вещь здесь в том, что у нас есть два разных вида рекомендаций. У нас есть некоторые рекомендации о том, как он должен вести себя как специалист по базам данных. Мы говорим ему, как писать хорошие графовые запросы. Но вторая часть подсказки, мы также даем ему немного знаний предметной области вокруг домена расследования мошенничества. Так что мы говорим, когда вам задают вопросы, вы должны делать такие вещи, как выявление общих ресурсов, таких как общие устройства, общие IP-адреса. Вы должны попытаться отследить потоки транзакций и закономерности перемещения денег. Так что мы фактически говорим в подсказке, мы даем агенту некоторые знания предметной области, и мы также даем ему некоторые знания о том, как вести себя как хороший специалист по базам данных. Хорошо. В этой ячейке здесь мы затем создадим самого агента. Так что мы создаем агента. Мы даем ему инструменты, которые доступны через этот клиент MCP. И в этом случае сервер Amazon Neptune MCP предоставляет пару инструментов. Один — это инструмент, который позволяет получить базовую схему графа. А другой — это инструмент, который позволяет вам или агенту фактически выполнять графовые запросы. Так что давайте запустим. Хорошо. Так О. Да, не смог создать свою подсказку, верно? Давайте перезапустим и сделаем это снова. >> Я люблю [фыркает] Jupyter Notebooks. [смех] Если вы все еще не работали с Jupyter Notebooks, они очень веселые. Если вы интересуетесь интерфейсом, который показывает Иэн, и я думаю, мы видели немного визуализацию ранее, у нас есть этот пакет с открытым исходным кодом под названием graph notebook, который находится на нашем GitHub, который фактически расширяет Jupyter notebooks с некоторыми магическими командами, специфичными для Neptune, которые просто делают намного проще, например, генерировать некоторые визуализации, которые мы видели ранее. Так что с тех пор, как мы его представили, я думаю, что все мы склонны использовать ноутбуки для всего, что связано с графами Neptune. >> Да, это плюсы и минусы, но это приятная интерактивная среда для экспериментов как с точки зрения написания запросов, так и с точки зрения использования многих из этих программ и SDK, которые мы предоставляем. Хорошо, теперь он работает. Так что мы создали агента. Я дал ему инструменты, которые были доступны через этот сервер MCP. Я дал ему подсказку со всеми этими знаниями предметной области. И затем я также дал ему вопрос. Найдите счета, связанные общими контактными данными или устройствами, которые указывают на одного мошенника. И теперь этот вывод здесь вверху, мы фактически можем видеть, как агент начинает работать. Как я уже сказал, мы хотим создавать агентов, которые ведут себя как эксперты, которые итеративно и инкрементально начинают решать проблему на основе их текущего понимания состояния мира. Так что он сделает первоначальный запрос, получит результаты, интерпретирует эти результаты, решит, что делать дальше, и затем потенциально выполнит некоторые дополнительные графовые запросы. Так что вы можете видеть, как агент говорит: "Я могу помочь вам найти эти счета". Он первоначально получает схему графа, чтобы подтвердить, что граф выглядит именно так, как мы обещали, а затем он начинает выполнять ряд графовых запросов к базовым данным. И то, что здесь происходит, это то, что агент знает достаточно о языке запросов, который мы используем для Neptune, языке запросов под названием Open Cipher. Он знает достаточно, чтобы фактически создавать запросы на лету, которые он затем может выполнять к этим базовым данным. Так что вы можете видеть, сколько у нас здесь пять запросов, я думаю, которые он выполнил один за другим, получает результаты, принимает некоторые решения, продвигает решение своей проблемы немного дальше, выполняет еще один запрос и так далее, а затем, наконец, представляет нам результаты. Так что в итоге это решение типа RAG, но агент более интерактивно извлек все эти доказательства, а затем, наконец, создал ответ на основе этих доказательств. Так что он сказал: "Вот кластер мошенничества с высоким риском", много, много деталей, даже рекомендованные действия, которые мы должны предпринять дальше. Хорошо. Так что довольно исчерпывающий ответ, и все, что нам нужно было сделать, это дать ему подсказку, которая рассказала ему немного о базе данных или схеме данных и немного знаний о домене мошенничества. Да, я вижу это как очень полезное, особенно если бы я был следователем по мошенничеству с деловой стороны и не хотел бы знать, как самому писать графовые запросы, тогда я могу просто задавать вопросы на естественном языке и получать что-то обратно, что очень круто, но также это подводит меня к вопросу о том, как предотвратить злонамеренных людей от, скажем, удаления определенных данных или дополнения данных, ввода плохих данных, таких вещей? >> Правильно. Эм, так что я думаю, во-первых, мы должны убедиться, что инструменты, которые мы запускаем, и среды, в которых они работают, имеют достаточные разрешения для выполнения работы, но не более того. И одна из вещей, о которых мы будем очень осторожны в таком контексте, — это убедиться, что наша среда ноутбука может читать граф, но не может записывать или удалять данные. Хорошо. Если мы хотим создать инструмент для расследования, где мы не обязательно хотим использовать инструмент для создания данных и хотим определенно предотвратить удаление данных кем-либо, тогда мы будем использовать разрешения IM, чтобы гарантировать, что эта среда имеет только разрешение на чтение данных из базового графа. И тогда эти разрешения будут проходить через этот сервер MCP, и любой запрос, который может придумать агент. И мы все знаем, что агенты могут быть довольно креативными. Мы знаем, что LLM могут быть довольно креативными и часто пытаются делать вещи, которые выходят за рамки их обязанностей. Но если бы агент здесь изобрел запрос, который подумал бы: "Возможно, мне нужно удалить некоторые данные", и отправил бы запрос на удаление. Пока мы настроили среду таким образом, что она может только читать данные, это будет отказано. >> Хорошо. Так что один из способов здесь — это, во-первых, обезопасить среду, в которой мы запускаем агента, чтобы предотвратить его злонамеренные действия против базовых данных. >> Отлично. Также хотел быстро вклиниться с парой быстрых вопросов из чата. Так что Лорен спрашивает, доступно ли это для нас, чтобы попробовать самим. Так что да, у нас есть репозиторий GitHub, где мы публикуем много примеров, связанных с Neptune и генеративным ИИ, который мы только что разместили в чате. Так что проверьте этот репозиторий позже на этой неделе, и мы обновим его этими примерами, чтобы вы могли поиграть с ними. Также хотел поднять вопрос от Реджинальдо, который, я думаю, является хорошей точкой перехода к тому, о чем мы говорили, о том, что, когда мы начнем переводить этот поток в продакшн, можем ли мы сами писать запросы или можем ли мы действительно полагаться на агента и LLM, чтобы убедиться, что он приходит с логически правильной версией чьего-то вопроса на естественном языке. >> Правильно. Да, я думаю, что это естественно приводит ко второй демонстрации здесь, где мы будем накладывать немного больше контроля на типы инструментов, которые мы предоставляем агенту. Но просто чтобы подчеркнуть, я имею в виду, что этот клиент MCP и сервер Amazon Neptune MCP доступны через GitHub, и вы можете установить их точно так же, как я установил их здесь. И поэтому вы можете использовать их сегодня против вашего собственного хорошо сформированного графа. Если у вас есть существующая графовая база данных, существующий граф Neptune, вы можете использовать это сегодня, чтобы агент писал запросы. Недостаток заключается в том, что, как мы видели, агент выполнял несколько разных запросов. У меня фактически есть некоторое журналирование, где мы фактически видим базовые запросы. И то, что я иногда вижу, это то, что агент может сначала создать запрос, синтаксис которого не совсем правильный, и он запускает его против базы данных, а затем получает ответ и говорит: "О, я попробую снова, и я изменю запрос". Так что он может быть довольно нерешительным в продвижении вперед и решении проблемы. Это отличный способ очень, очень быстро начать работу. Но возможно, что по мере того, как мы будем переводить некоторые из наших решений в продакшн, мы захотим как разработчики получить немного больше контроля над типами инструментов, которые мы предоставляем агенту, и способами, которыми эти инструменты работают. Так что второй пример, который у меня есть здесь, и это снова работает с этими базовыми данными о мошенничестве. Но здесь, как разработчик приложений, я создал пару очень специфичных для предметной области инструментов. Так что вы можете видеть, что у меня есть один здесь, инструмент под названием "найти кандидатов в мошеннические кольца" и второй под названием "рассчитать воздействие мошеннического кольца". Так что это выглядит как обычные методы Python, и вы можете видеть, что каждый метод инкапсулирует графовый запрос. В первом из них мы фактически запускаем графовый алгоритм, алгоритм графа Луэйна, чтобы найти потенциально мошеннические группы мошеннических акторов. И мы возвращаем эти результаты. И этот второй запрос, опять же, использует язык запросов Open Cipher, но, учитывая список идентификаторов счетов, он обходит граф, находит все эти различные транзакции и суммирует результаты. Так что это позволяет нам точно контролировать типы поведения и типы запросов, которые агент может выполнять к нашему базовому набору данных. Так что мы переместили часть этих знаний из подсказки, которую мы видели в первом примере, обратно в код, но мы затем предоставляем эти методы или функции как инструменты агенту. И снова, ключевая вещь в агентном решении заключается в том, что мы не слишком предписываем порядок, в котором агент выполняет процесс. Мы просто говорим: "Послушайте, вы такой эксперт. Вот набор инструментов, которые вы можете использовать. Вы думаете о порядке, в котором вы хотите их применять, какие инструменты вы хотите использовать. Вы выбираете и сочетаете. Вы идете вперед, решаете проблему наилучшим образом, как вы считаете нужным". И я также вижу это, у нас есть еще один комментарий от Ассана о том, если бы мы хотели интегрироваться с приложением, таким как веб-приложение, как мы можем его обезопасить, чтобы запросы синтезировались и отвечали только на действительные вопросы. Так что это выглядит как отличный подход для этого, потому что вы можете иметь гораздо больше контроля над тем, какие именно запросы выполняются. Похоже, с этим. >> Да. Да. Я, как разработчик приложений или инженер данных, имею гораздо больше контроля над типами возможностей запросов, которые я хочу предоставить агенту. Так что я определенно не буду включать запросы, которые изменят или повредят данные. Я не буду включать никакие запросы, которые удаляют данные. Что это означает, так это то, что мне нужна экспертиза в графовой базе данных, мне нужно понимать предметную область, модель данных графа, и мне также нужно знать, как создавать хорошие запросы, которые могут эффективно реализовывать эти виды возможностей. С первым решением мы просто позволяли агенту писать лучшие запросы, которые он мог придумать, чтобы решить проблему. Теперь мы вернули эту ответственность мне, но я создал пару значимых для предметной области инструментов, которые мы можем дать агенту и просто сказать: "Знаете, вы идите вперед, решайте проблему так, как вы считаете нужным". Так что снова мы создадим небольшой локальный сервер MCP. Мы дадим ему эти два инструмента. >> Так что настройка немного отличается, >> но мы все еще создаем клиент. Продолжайте. О, извините. Иэн, я думал, что выполнение некоторых из этих шагов займет больше времени, потому что у нас есть пара вопросов в чате. Я просто хотел быстро поднять их. Один был просто о языке запросов. Так что мы используем Open Cipher сегодня, но сервер Amazon Neptune MCP также поддерживает Gremlin, поскольку база данных Neptune сегодня поддерживает оба языка запросов. >> Да, это верно. Так что, если вы используете базу данных Neptune в качестве базового графового хранилища, то у вас есть доступ к языкам запросов Open Cipher и Gremlin для таких графов свойств. Если вы используете Neptune Analytics сегодня, Neptune Analytics поддерживает Open Cipher для запроса модели данных графа свойств. Так что да, все примеры, которые мы используем сегодня, были написаны с использованием Open Cipher. >> Да. И еще один вопрос от Сиобан Шу, спрашивающей, можем ли мы сделать этот агентный поток Graph RAG с помощью Agent Core. Так что, на данный момент, я полагаю, мы просто показываем его локально. Это правильно, Иэн? >> Да. Да. И снова ноутбуки — отличное место для экспериментов. Они предоставляют очень приятную интерактивную среду, где я могу просто построить или доработать скелет общего решения. Но для внедрения в продакшн я бы использовал такие вещи, как Agent Core, чтобы должным образом размещать, управлять и контролировать многие из агентных компонентов в моем решении. Хорошо. Так что мы создали эти инструменты. Развернули сервер, который предоставляет эти инструменты. Этот код должен выглядеть очень знакомым [фыркает], потому что мы создаем агента. Мы говорим ему, какую модель мы хотим использовать для его собственного интеллекта. И это будет Claude Sonet 4. Мы даем ему эти инструменты. Мы даем ему очень, очень простой системный промпт. "Ты полезный ассистент. Ответь на вопрос пользователя на основе доказательств из результатов поиска". Это очень, очень общий системный промпт. Но затем проблема, которую мы просим его решить, заключается в следующем: "Пожалуйста, можешь ли ты определить самое большое потенциальное мошенническое кольцо, а затем перечислить его участников и рассчитать его воздействие". Так что мы создадим этого агента. О, да, вот оно. Итак, я помогу тебе определить самое большое потенциальное мошенническое кольцо. Так что он использует первый инструмент, инструмент номер один, "найти кандидатов в мошеннические кольца". Возвращает некоторые результаты. Теперь позволь мне рассчитать воздействие этого мошеннического кольца. Хорошо. Так что вы можете видеть снова агента, он знает инструменты, которые у него есть в его распоряжении. Ему была поставлена задача решить проблему, и он выбирает наиболее подходящие инструменты для решения этой проблемы. Действительно дал ему два инструмента, и он использовал оба инструмента. Но может быть, что существует гораздо более широкий спектр инструментов для обнаружения и анализа мошенничества, которые мы предоставляли серверу. Хорошо. Так что это первые две демонстрации, и они работали с этими данными о мошенничестве. И, как я уже упоминал ранее, это очень хорошо смоделированный набор данных о мошенничестве, который довольно репрезентативен для набора счетов, торговцев и транзакций и так далее. И у нас было два разных подхода к созданию агентного решения, которое использует возможность находить все эти связи в базовых данных. >> Да. Первый подход. >> О, извините, Иэн. У меня небольшая задержка, но прежде чем мы перейдем от двух примеров, я хотел бы быстро вернуться к комментарию Реджинальдо ранее о свежести данных. Так что, поскольку оба эти примера мы читаем из хорошо структурированного графа знаний. В этом случае мы могли бы иметь отдельный конвейер, который просто обновляет граф в реальном времени, если бы мы хотели, верно? Так что нам действительно не нужно, по крайней мере, с точки зрения агента, слишком беспокоиться о свежести данных, потому что мы постоянно обновляем граф. >> Да. Да. Это действительно очень хороший момент, что мы создаем агента, который указывает на этот набор данных о мошенничестве. Что строит набор данных о мошенничестве? Ну, вероятно, есть другие части приложения, другие конвейеры, другие системы, которые по мере того, как организация регистрирует новые счета, начинает добавлять новые узлы в граф, добавляет эти фрагменты информации об удостоверении личности, и по мере того, как мы узнаем о транзакциях, по мере того, как транзакции проходят через организацию, опять же, будет какой-то другой конвейер или приложение, которое заполняет и обновляет граф. Так что это то, что обеспечивает постоянное обновление графа. Агент затем может выполнять свою работу, зная, что данные, к которым у него есть доступ, максимально свежие. Хорошо. Теперь мы перейдем к нашему третьему примеру, и это пример, который использует набор инструментов Graph RAG, о котором я упоминал ранее. Набор инструментов Graph — это библиотека с открытым исходным кодом для создания графовых приложений GenAI. Набор инструментов Graph позволяет принимать неструктурированный и полуструктурированный текстовый контент. Так что такие вещи, как PDF, текстовые файлы, файлы markdown, а также некоторый полуструктурированный контент. Это могут быть JSON документы, такие вещи. Он позволяет принимать все это, и он автоматически построит для вас граф, который фактически индексирует весь этот текстовый контент. Так что мы не строим то, что я назвал ранее графом знаний. Мы строим граф, который я называю лексическим графом, который фактически является продвинутым графовым индексом для всего этого текстового контента. Но набор инструментов также предоставляет API движка запросов, который позволяет вам задавать вопросы на естественном языке, а затем у него есть некоторые стратегии извлечения, которые были предварительно заполнены очень хорошо написанными графовыми запросами для поиска всего этого релевантного текстового контента. И снова преимущество использования графа здесь заключается в том, что мы всегда можем использовать векторный поиск для поиска семантически схожей информации. И это обычно является основой для ответа на любой хороший вопрос. Но граф также поможет нам найти некоторую неочевидную связанную информацию, которая находится в других документах. Мы можем объединить всю эту информацию, чтобы получить очень исчерпывающий ответ. Хорошо. Так что это то, что позволяет вам делать набор инструментов Graph RAG. Он позволяет вам создавать тип приложения Graph RAG, который Мелисса показывала в начале прямой трансляции. Теперь есть пара других вещей в наборе инструментов, которые очень полезны для нас здесь, когда мы создаем агентные решения. Первое — это поддержка "из коробки" концепции многопользовательской работы. Так что я могу создавать отдельные лексические графы, полностью и целиком отличные друг от друга, в одной и той же базовой графовой базе данных. Теперь вы можете использовать это, потому что у вас есть свои разные клиенты, разные пользователи, и они все хотят свои отдельные графы. Но другой способ, которым вы можете использовать это, — это принимать определенные типы документов или определенную информацию предметной области в определенного клиента. Так что вы применяете своего рода подход "разделяй и властвуй", чтобы у вас были разные лексические графы, представляющие разные тела текстового контента. Хорошо. Так что многопользовательская работа позволяет нам принимать данные в разные лексические графы в одном и том же экземпляре. Так что мы можем разделять и властвовать на основе разных видов контента. Второе важное свойство здесь заключается в том, что по мере того, как мы принимаем всю эту информацию, мы фактически строим параллельно своего рода выведенную схему для базовой семантики предметной области для этих данных. Правильно. Объединенные вместе. Это означает, что мы можем взять эту выведенную схему. Мы можем взять образец некоторых данных и автоматически сгенерировать описание этого графа, которое мы можем сформулировать как описание инструмента. Хорошо. Так что пример, который у меня есть здесь, — это два разных набора данных в двух разных лексических графах, расположенных в одном и том же экземпляре базы данных. Один из этих наборов данных — это информация о, это своего рода информация о самолетах. Это информация о различных моделях легких самолетов, производителях, истории этих различных самолетов и так далее. Это информация, полученная из Википедии. Второй набор данных, который у меня есть, — это набор отчетов об авиационных происшествиях от Национального совета по безопасности на транспорте. Так что это своего рода полуструктурированные документы, описывающие авиационные происшествия, произошедшие за последние несколько лет. Так что вы можете видеть, что эти два массива информации связаны, но они несколько различны. Один — это все об истории самолетов и производителей, а другой — очень специфическая информация о конкретных происшествиях. Так что я ранее принял всю эту информацию с помощью набора инструментов в двух разных клиентах. То, что я покажу здесь, — это выведенная схема только для одного из этих наборов данных. Так что я сказал, что по мере того, как мы принимаем данные, мы фактически строим параллельно своего рода выведенную схему для данных. Так что мы можем видеть, что у нас есть такие вещи, как самолеты и объекты, и
производители, а затем различные виды отношений, которые связывают экземпляры этих вещей. Таким образом, в базовом наборе данных у нас будет информация о конкретных самолетах и о конкретных производителях, и они будут связаны множеством различных отношений. Хорошо. Итак, я собираюсь запустить сервер MCP. И в инструментарии есть несколько методов, которые автоматически создадут для вас сервер MCP. Когда он создает этот сервер MCP, инструментарий анализирует все эти различные лексические графы, берет схемы для каждого графа, выбирает образцы данных для каждого графа и использует это для генерации описания содержимого графа. Итак, это только что произошло здесь. Давайте немного увеличим экран. Я снова создам клиент, который может указывать на мой сервер MCP. И посмотрите, это инструменты, которые были автоматически созданы для меня инструментарием на основе его понимания содержимого этих различных графов. Итак, первый инструмент называется "самолеты", и его область применения — общая авиация и база знаний по самолетам. Так что это довольно многословно, но дает своего рода подробное описание того, какую информацию вы найдете в этой конкретной базе знаний. И обратите внимание, что это даже не описывается как граф. Просто говорится: "Эй, я инструмент, который знает все об авиации и самолетах". И вы можете использовать его для таких вещей, как отслеживание истории самолетов, и вы можете использовать его для ответов на такого рода вопросы. Таким образом, он просто предоставляет несколько примеров, чтобы помочь агенту понять, когда может быть уместно использовать этот конкретный инструмент. Второй инструмент называется NTSB, и это снова инструмент, который говорит: "Эй, я база знаний, которая знает все о безопасности полетов и расследовании авиационных происшествий". Так что, если вы хотите узнать о конкретных инцидентах, я — инструмент, который вам нужен. Итак, знакомый фрагмент кода, снова мы создадим агента. Мы дадим ему эти инструменты: базу знаний по самолетам и базу знаний по авиационным происшествиям. Очень простой системный запрос, но довольно сложный вопрос, на который мы хотели получить ответ. Какие проблемы безопасности и закономерности аварий демонстрируют экспериментальные самолеты серии Kit Fox? И как они соотносятся с конструктивными особенностями и производственными спецификациями, предоставленными Denny Aircraft? Я имею в виду, для меня это звучит как довольно сложный вопрос, который может потребовать от нас углубления в оба набора данных, выбора и сопоставления множества фрагментов информации. Хорошо. Итак, что мы увидим здесь, мы не видим много деталей о том, что происходит за кулисами, но фактически агент, чтобы ответить на этот конкретный вопрос, движется вперед и назад, используя оба этих инструмента, задавая вопрос, получая результаты, интерпретируя результаты, решая, что он хочет сделать дальше, что ему нужно узнать дальше, и так далее, пока он не почувствует, что удовлетворительно собрал достаточно информации, чтобы правильно ответить на вопрос. Таким образом, он движется вперед и назад, и за кулисами он фактически задает вопросы на естественном языке. Агент задает вопросы на естественном языке этим базам знаний, потому что он не знает, что за кулисами есть граф. Нет языка запросов к графам, который он знает. Он просто задает вопросы на естественном языке. И тогда мы можем увидеть здесь, что он наконец собрал достаточно информации, чтобы создать довольно исчерпывающий ответ о происхождении, дизайне и так далее. >> Потрясающе. Да, большое спасибо Иэну за то, что он показал нам эту демонстрацию. Я думаю, это действительно объединяет все различные части. Итак, э-э, в предыдущих двух примерах мы видели, как сервер Neptune MCP может подключаться к более структурированному графу знаний. А затем здесь, знаете, мы могли бы наложить на эти предыдущие два примера еще один сервер MCP и набор инструментов, которые раскрыли бы то, что предоставляет граф-инструментарий для графовой части, что, я думаю, очень круто. Э-э, последний вопрос, который я хотел вывести на экран. э-э, прежде чем мы начнем завершать, это от Уильяма. Э-э, он спрашивает, какую службу AWS мы используем для векторной базы данных rag. Также не беспокойтесь о том, что опоздали. Мы опубликуем все записи на YouTube, а все наши примеры будут доступны по ссылкам на GitHub, которые мы опубликовали, к этой пятнице. Э-э, но что касается векторного хранилища здесь, граф-инструментарий поддерживает как Neptune Analytics, который имеет свой собственный векторный индекс, так и другие векторные хранилища в сочетании с ним. Э-э, мне жаль, Иэн, в вашем примере вы использовали базу данных Neptune плюс что-то еще? >> Э-э, это использует Neptune Analytics. Таким образом, Neptune Analytics является как графовым хранилищем, так и векторным хранилищем. Инструментарий также поддерживает, как вы говорите, э-э, другие серверные векторные хранилища, включая OpenSearch, PostgreSQL с расширением PG vector и S3 vectors. Э-э, и мы всегда приветствуем вклад в добавление новых коннекторов. >> Потрясающе. Отлично. >> Спасибо. Ну, спасибо большое Иэну за то, что он уделил время, чтобы показать нам все это сегодня. Э-э, прежде чем мы закончим, есть ли у вас какие-либо последние мысли или заключительные мысли, которыми вы хотели бы поделиться с аудиторией? Э-э, ну, мне понравился ваш термин "наложить". Я имею в виду, суть в том, что мы предоставляем вам множество различных вариантов создания инструментов, которые вы можете передать своим агентам. Вы можете постоянно добавлять новые инструменты к своим агентам, не только графовые инструменты, но и другие, и эти агенты становятся более мощными, более специализированными, ведут себя со временем больше как эксперты. >> Потрясающе. Ну, на этом, э-э, еще раз всем большое спасибо за то, что присоединились к нам, и да, спасибо Иэну за то, что поделились всеми своими знаниями с нами, и да, надеюсь увидеть вас всех на следующем выпуске "Базы данных для ИИ". Спасибо. >> Замечательно. Спасибо. Спасибо, Мелисса. Спасибо всем. >> [музыка]