Transcription
[Музыка] Я, по сути, посвятил свою профессиональную жизнь тому, чтобы разработчики могли создавать лучшие приложения и создавать приложения лучше, используя не только отдельные точки данных, извлеченные одновременно, по одной за раз, или суммированные, или сгруппированные, рассчитанные средние значения, а отдельные точки данных, связанные отношениями, верно, и сегодня я собираюсь поговорить об этом, примененном в мире LLM и Gen. Итак, прежде чем я это сделаю, я немного отвлекусь. Я собираюсь поговорить о поиске, об эволюции поиска. Все здесь, в этой комнате, знают, что подавляющее большинство веб-поисков сегодня выполняется с помощью Google, но некоторые из вас знают, что так было не всегда. Это началось так. Кто здесь узнает эту веб-страницу? Да, кто здесь узнает AltaVista как название? Несколько человек, верно? В середине 90-х годов существовали десятки компаний, занимающихся веб-поиском, десятки, множественное число, как 30, 40, 50 компаний, занимающихся веб-поиском, и все они использовали, по сути, одну и ту же технологию. Они использовали поиск по текстовым ключевым словам, инвертированный индекс, поиск типа BM25, для тех из вас, кто знает, что это значит. И это работало очень, очень хорошо, пока не перестало работать, и вступил в силу эффект AltaVista, который заключался в том, что вы искали что-то, получали тысячу или тысячи результатов, и вам приходилось просматривать страницу за страницей, пока вы не находили нужный вам результат. Эффект AltaVista: вы получали слишком много результатов из интернета. Вначале это не было проблемой, потому что большинство вещей, которые вы искали, когда я впервые выходил в интернет, давали ноль результатов, потому что в интернете не было контента об этом, верно? Но эффект AltaVista, слишком много результатов поиска, был решен Google. Это пресс-релиз Google, середина, вы знаете, середина 2000-х. Они говорят о миллиарде проиндексированных URL-адресов, верно? Но они также говорят о технологии, которую они используют за кулисами, технологии под названием PageRank, которая выдает самые важные результаты поиска очень рано. Фактически, первые 10 синих ссылок на первой странице, верно? Эта технология PageRank на самом деле является графовым алгоритмом, который на самом деле называется центральностью собственного вектора. И инновация, которую сделал Google, заключалась в применении этого к масштабу интернета и масштабу веба, верно? PageRank, который открыл и создал, честно говоря, самую ценную компанию на планете на довольно долгое время, эру PageRank, которая продлилась около десяти лет, около дюжины лет, пока в 2012 году Google не написал этот пост в блоге, который является удивительным постом в блоге, представляющим Knowledge Graph, вещи, а не строки. Там они сказали: «Знаете что, ребята, мы сделали обновление на бэкенде нашей поисковой технологии, самое большое с тех пор, как мы изобрели PageRank, где мы уходим от простого хранения текста и ссылок между документами, но также и концепций, встроенных в эти документы, вещей, а не просто строк». И мы все знаем, как выглядит Knowledge Graph визуально, когда вы ищете что-то в Google сегодня, Moscone Center, прямо за углом отсюда, вы получите эту маленькую панель справа. Если вы посмотрите на эту панель, она содержит комбинацию неструктурированного текста, в данном случае из Википедии, со структурированным текстом. Она содержит адрес, владельца здания Moscone, вы знаете, такого рода вещи. Эта вещь основана на бэкенде на структуре данных, выглядящей так, верно? У нее есть эти концептуальные кольца, которые мы называем узлами, которые связаны с другими узлами через отношения, и как узлы, так и отношения имеют свойства ключ-значение. Вы можете прикрепить два, три, тысячу, 10 000 как к узлам, так и, что очень важно, к отношениям. Это Knowledge Graph, и это было следующее десятилетие или около того, 12 лет доминирования Google, пока несколько месяцев назад, несколько месяцев назад на Google IO они не сделали следующий шаг, открытый конференцией инженеров ИИ год назад, ну, не совсем, но, конечно, вся экосистема вокруг Gen. И это один из примеров, который они сделали, классический план путешествия. Он помог мне спланировать это путешествие. Все здесь, в этой комнате, знают, что это основано на LLM, и это основано на LLM в сочетании с этой структурой данных Knowledge Graph, Graph RAG. Это открывает следующую эру веб-поиска, эру Graph RAG. О чем я собираюсь вам сегодня рассказать, так это о том, как вы можете использовать, ну, во-первых, стоит ли вам это делать, и если да, то как вы можете использовать Graph RAG для своих собственных приложений на основе RAG. Итак, что такое Graph RAG? Это очень, очень просто. Graph RAG — это RAG, где на пути извлечения вы используете Knowledge Graph. Очень, очень просто. Это не означает, что вы используете только Knowledge Graph, но вы используете Knowledge Graph, возможно, в сочетании с другими технологиями, такими как векторный поиск. Итак, давайте возьмем классический пример бота для обслуживания клиентов, верно? И давайте предположим, что вы работаете в компании, которая производит, например, Wi-Fi роутеры, верно? И у вас есть куча статей поддержки, верно? И они были сохранены в текстовых файлах, верно? И тогда вам поручено создать бота, который либо предоставляет конечным пользователям прямой доступ к ним, либо вашим собственным сотрудникам службы поддержки, агентам, доступ к этой информации. И вы знаете, как это сделать, потому что вы живете в мире LLM и мире Gen. Так что вы будете использовать RAG для этого, верно? И вот у вас есть эти данные, это текстовые документы. Вы добавили этот текст к свойствам конкретных узлов, так что у вас есть узел на статью, но затем вы также сказали, что эта статья посвящена этому конкретному Wi-Fi продукту, верно? У вас есть отношение к этому Wi-Fi продукту, и этот Wi-Fi продукт находится в иерархии других Wi-Fi продуктов, и он написан этим конкретным инженером службы поддержки, вы знаете, такого рода вещи. А затем у конечного пользователя возникает вопрос: «Эй, мои Wi-Fi индикаторы мигают желтым, и мое соединение обрывается, что мне делать?» Что-то вроде этого. Я думаю, мы все знаем, как мы это делаем. Мы векторизуем поиск, верно? Мы получаем какой-то векторный эмбеддинг обратно. Мы используем векторный поиск, чтобы получить основные документы. Но вот где вступает в игру часть Graph RAG. Вы получаете эти основные статьи, которые связаны с узлами. Фактически, текст находится на узлах, но затем вы используете граф, чтобы пройти оттуда и извлечь больше контекста вокруг него. Возможно, это не просто эта конкретная статья для этого конкретного Wi-Fi, а что-то еще в этом семействе. Возможно, вы используете тот факт, что этот конкретный инженер имеет очень высоко оцененный контент, и тогда вы ранжируете его выше, верно? Вы извлекаете больше контекста, чем то, что вы получаете из поиска на основе A&N из вашего векторного хранилища, и передаете это LLM вместе с вопросом. Вы получаете ответ и передаете его пользователю. Итак, основной шаблон на самом деле очень, очень прост, но очень, очень мощный, верно? Вы начинаете с векторного поиска. Я думаю об этом почти как о первичном ключе. Это, конечно, не первичный, но почти как первичный ключ для поиска в графе. Вы используете этот векторный поиск, получаете начальный набор узлов, затем вы обходите граф и расширяете его, находите релевантный контент на основе структуры графа. Затем вы берете это и возвращаете LLM или, возможно, это дает вам тысячу или 10 000 узлов, а затем вы делаете то, что сделал Google: ранжируете это, получаете топ K на основе структуры графа, возможно, вы даже используете PageRank, верно? Вы получаете это, передаете это LLM. Очень, очень просто, но очень, очень мощно. А затем есть несколько более продвинутых шаблонов, но это своего рода следующий, следующий доклад, который я сделаю через год, более сложные шаблоны графового извлечения, верно? Но основной, очень, очень простой. Хорошо, если это то, что такое Graph RAG, каковы преимущества Graph RAG? Когда его следует использовать, а когда не следует? Первое и самое яркое преимущество — это точность. Она напрямую коррелирует с качеством ответа. За последние шесть месяцев или около того было опубликовано множество исследовательских статей об этом. Я считаю, что первая была от data.world. Я выбрал три случайных из тех, которые мне нравятся. Это первая, насколько мне известно, от dataworld, компании, занимающейся каталогизацией данных, основанной на Knowledge Graph. И они доказали на, я думаю, 43 различных вопросах, что в среднем качество ответа, точность была в три раза выше, если они использовали Knowledge Graph в сочетании с векторным поиском. Мне нравится эта статья от LinkedIn. Она показывает очень похожий тип, я думаю, это около 75% или 77% увеличение точности, но она также имеет отличный обзор архитектуры. Так что вы можете взять QR-код прямо здесь, посмотреть эту статью, которая объединяет различные компоненты, а также поток через нее, который, как мне показалось, был просто очень педагогическим. Но в целом, это показывает одно и то же, немного разные цифры, но значительно более высокая точность, когда использовался граф в сочетании с векторным поиском. А затем у Microsoft был фантастический пост в блоге, а затем, я думаю, две академические статьи. Пост в блоге был в феврале этого года, где они также говорят об улучшении качества ответов, но также и за пределами этого. Эй, знаете что, Graph RAG позволяет нам отвечать на другой важный класс вопросов, на которые мы даже не могли ответить с помощью одного только векторного поиска или базового векторного поиска. Это то, что они называют, или базового RAG. Итак, первое преимущество — более высокое качество ответа. Второе — более простая разработка, и это немного интересно, потому что там есть звездочка, потому что мы очень четко слышим от наших пользователей, что проще создавать RAG-приложения с Graph RAG по сравнению с базовым RAG, но мы также слышим, что это на самом деле сложно. И в чем нюанс? Ну, нюанс в том, что если у вас уже есть работающий Knowledge Graph. Так что есть кривая обучения, где людям нужно узнать, как создать Knowledge Graph в первую очередь. Как только у вас это есть, это намного проще. Но как создать этот Knowledge Graph? Итак, давайте поставим небольшой флажок на этом. Если я достаточно быстро пройдусь по следующим нескольким слайдам, я надеюсь, покажу вам демо этого, но давайте поставим небольшой флажок на этом. Итак, это пример. Это из очень быстрорастущей финтех-компании, которая очень передовая в области ИИ, и они начали играть с Graph RAG около шести месяцев назад. И они взяли существующее приложение и сказали: «Знаете что, мы перенесем его из векторной базы данных в Neo». И большинство операций дают лучший результат. Они могут вычислять эмбеддинги на уровне базы данных. Получение связанных действий так же просто, как следование отношениям между узлами. И мне очень нравится этот кэш, и кэш здесь — это их приложение. Они называют его Cache. Его можно визуализировать. Это чрезвычайно ценный инструмент отладки, и в скобках я уже исправил пару ошибок благодаря этому. Удивительно, как только вы смогли создать этот граф, гораздо проще создать ваше RAG-приложение. И почему это так? Итак, давайте поговорим немного о представлении. Допустим, у нас есть фраза: «Яблоки и апельсины — оба фрукты», и мы хотим представить это в векторном пространстве и в графовом пространстве. В графовом пространстве мы уже говорили об этом: яблоко — это фрукт, апельсин — это фрукт. Довольно просто. Это представление в графовом пространстве. В векторном пространстве это выглядит так, или, возможно, это что-то другое, например, мы на самом деле не знаем. Два разных способа представления этой фразы. А затем мы можем выполнять вычисления сходства разными способами, используя оба эти представления, которые я не буду сейчас рассматривать. Мы можем искать разными способами. Это не конкурирующие способы сделать это, это взаимодополняющие способы сделать это, верно? Один не лучше другого, за исключением того, что я сделаю одно заявление: когда вы садитесь и пишете свое приложение, когда вы создаете свое приложение, я на самом деле сделаю заявление, что одно из них превосходит. Это представление в векторном пространстве полностью непрозрачно для человека, но представление графа очень, очень четкое. Оно явное, детерминированное, визуальное. Вы можете его видеть, вы можете его трогать, когда создаете наши приложения. Это то, что я уже исправил пару ошибок благодаря этому. Просто перенеся его из чисто векторного хранилища в Graph RAG, они смогли видеть данные и работать с ними. И это действительно очень мощно. Это проявляется во времени разработки, когда вы создаете свои приложения. Это также проявляется для наших друзей в IT, которые беспокоятся о вещах, которые, возможно, не напрямую связаны с созданием приложения, а именно об объяснимости, аудируемости, управлении. Эта явная структура данных имеет вторичные эффекты, которые очень, очень мощны, когда вы работаете в продакшене и вам нужно объяснить, почему что-то произошло. Итак, более высокая точность, лучшие ответы, проще в создании, когда вы преодолеете трудности создания Knowledge Graph, а затем повышенная объяснимость и управление для него и бизнеса, верно? Это три вещи. Итак, как начать с Graph RAG? Я уже много об этом говорил. Как создать Knowledge Graph в первую очередь? Итак, здесь есть небольшой нюанс. По сути, существует три типа данных в мире, которые меня интересуют, когда я думаю о создании Knowledge Graph. Первый — это структурированные данные. Это ваши данные в Snowflake или чем-то подобном, или PostgreSQL, верно? Другой — это неструктурированные данные: PDF-файлы, необработанный текст с веб-страницы. И другой, третий — это смешанные. Люди склонны называть это полуструктурированными, но это не так. Свяжитесь со мной позже, и я расскажу вам, почему это не так. Но, по сути, что это такое, это структурированные данные, где некоторые поля — это длинный текст. По сути, мы отлично справляемся с первой категорией. В мире графов очень легко перейти от Snowflake, PostgreSQL, MySQL или Oracle к модели графа свойств. Неструктурированные данные — это действительно очень сложно, верно? Это сложно сделать в теории, и у инструментов для этого тоже долгое время были проблемы. Средняя категория — это на самом деле то, где находится большинство, по крайней мере, корпоративных производственных случаев использования в реальном мире. Итак, два с половиной минуты, это грубо. Существует два типа графов, и я не буду о них говорить. Я хочу поговорить о них. Лексические графы и доменные графы на самом деле очень актуальны, но я действительно хочу перейти к этому демо. Итак, я говорил о создании графов с неструктурированной информацией. Итак, мы только что создали этот новый инструмент, который мы запустили всего несколько недель назад, под названием Knowledge Graph Builder. И вы видите его здесь. Можете ли вы видеть экран? Хорошо. Итак, по сути, здесь вы можете перетаскивать свои PDF-файлы, вы можете вставлять ссылки на YouTube, ссылки на Википедию, вы можете указывать на свой облачный сервис-бакет, верно? И он может извлекать данные оттуда и создавать граф. Итак, я добавил несколько вещей. Я добавил PDF-файл из рассылки Эндрю Нинга, The Batch. Я добавил страницу Википедии об OpenAI. И я добавил YouTube от Swix и Алессио, вы знаете, подкаст «Четыре войны, лат и космос». Итак, я добавил все это и загрузил это в этот Knowledge Graph Builder. И когда я это делаю, он создает, если посмотрим сюда, я знал, что Ethernet-соединение это сделает. Он автоматически создал небольшой Knowledge Graph. Если он отобразится, подождите. Здесь написано «одна минута». Так что он должен отобразиться довольно скоро. Хорошо, давайте сделаем это снова. Пожалуйста, сработайте. О нет, да. О, мой, почему не работает? О, черт. О нет. И время идет. Хорошо, подождите. Подождите. Хорошо, вы можете это сделать. Можете это сделать. И я пытался сохранить его в этом. Хорошо. Давайте посмотрим. Думаю, мы здесь. А затем он говорит: «Покажи мне граф», и он не покажет мне граф. О, да, он покажет. Ну же, ты можешь это сделать. Хорошо. Да. Итак, что у нас здесь? Посмотрите на это. Я бы с удовольствием посидел здесь и насладился вашими аплодисментами, но нам нужно посмотреть на эти данные. Итак, посмотрите на это. Это документ «Четыре войны». Вот различные фрагменты, и вы можете взять фрагмент и развернуть его. Я вставил эмбеддинг, и вы можете, я увеличу масштаб здесь, и вы можете увидеть, что он извлекает логические концептуальные элементы из этого фрагмента, такие как машинное обучение. Они говорят о чем-то, что разработано аналогичным образом. Я даже не знаю, есть там какая-то компания, верно? И вы получаете весь этот граф всей этой информации. Кроме того, у меня действительно нет времени, чтобы показать это, но здесь также есть чат, который вы можете использовать, и вы можете исследовать полученный результат. Еще одна секунда. Возьмите свои телефоны, если думаете, что это выглядит круто. Сделайте фотографию этого QR-кода, и вы получите потрясающую целевую страницу, где у вас будет доступ ко всей этой информации. Вы можете начать работать самостоятельно. Спасибо за дополнительную минуту. Спасибо. Спасибо всем за внимание. [Музыка]