Transcription
Итак, ИИ меняет то, как мы разрабатываем приложения, и вы это знаете, и вам не нужен целый букет модных доказательств от Гарварда, Venturebeat и Gartner, чтобы это понять. Вы сами это испытываете. Итак, мы это знаем, но то, почему мы должны создавать приложения, не меняется. Мы по-прежнему пытаемся решить какую-то бизнес-проблему, сопоставить бизнес-процесс с конкретным решением, найти ответы на вопросы. Так что, по сути, мы по-прежнему пытаемся решать бизнес-проблемы. Очевидно, у нас есть целый ряд новых инструментов, и что же меняется?
Итак, одно изменение с точки зрения данных заключается в том, что мы переходим от мира предопределенных рабочих процессов, где у вас есть простые модели данных CRUD (создание, чтение, обновление, удаление), к динамическим, контекстно-зависимым и автономным приложениям. Это агенты, которые координируют свои действия друг с другом, принимают решения в реальном времени, более проактивны, не действуют как функция кода и предопределенных правил. И, что важно, они обладают пониманием и действуют на основе контекста. Контекст как самого объекта, с которым вы работаете, так и субъекта, который с ним работает. Например, кто такой клиент и кто, возможно, является заинтересованным лицом внутри компании.
И если углубиться в это, есть пять конкретных паттернов, которые меняются. Первое — это переход от статической логики к динамическому рассуждению. В старом мире это возвращается к пункту CRUD и жестко закодированным правилам, которые определяются во время компиляции, когда вы пишете и компилируете код. А мы хотим перейти к возможности рассуждать заново, адаптироваться, принимать решения в реальном времени и, что важно, сосредоточиться на достижении ряда целей с, возможно, большей открытостью в отношении того, как вы собираетесь их достичь.
Второе — это переход от простого запроса-ответа к большей целеориентированности. Здесь я просто реагирую на ввод пользователя в старом мире, тогда как здесь я могу быть более проактивным в достижении ряда целей, оркеструя задачи и даже взаимодействуя с другими агентами, каждый из которых решает свои микроцели, чтобы решить какую-то более крупную макроцель. И я также хочу иметь возможность адаптироваться и учиться на обратной связи.
Вы также немного отходите от монолитов. Конечно, у вас были микросервисы, но компонуемые системы на самом деле более гибкие и представляют собой следующий уровень, безусловно, за пределами монолитов, но даже за пределами микросервисов. Таким образом, вы переходите от тесно связанных архитектур, где вы заранее знаете, как вещи будут взаимодействовать и в каком порядке, к различным агентам, которые могут взаимодействовать друг с другом различными способами, которые появляются почти в реальном времени по мере развития ситуации.
Это тоже очевидное изменение: переход от ориентации на код к ориентации на запросы. И последнее, но не менее важное: переход от CRUD. Я собираюсь получить определенную информацию только о том, что меня интересует, к пониманию того, каковы цели этой вещи? Каковы взаимодействия? Каким образом эта вещь вписывается в мир? И это контекст.
Вот так меняется программная инженерия. Теперь, как меняется уровень данных? Что означает для уровня данных возможность поддерживать такие требования? Особенно в мире, где сегодня большинство данных по-прежнему хранится в строках и столбцах, что может быть приемлемо для определенных видов использования. Но если данные распределены по разрозненным источникам, и вам нужно регулярно добавлять данные для решения новых типов проблем, то эта абстракция не обязательно является лучшей для тех видов знаний ИИ, с которыми мы работаем. Она хорошо работает, когда вы структурированы для статических данных и относительно фиксированных вопросов, но немного хуже справляется с большей открытостью, которая у вас есть. И здесь довольно много всего.
Каковы же тогда требования, теперь, когда мы обсудили требования и то, как меняется разработка приложений для агентских корпоративных знаний, какие знания нужны этим агентам и в какой форме, чтобы они могли выполнять все эти требования? Первое — это возможность получать обновления в реальном времени и выполнять извлечение с низкой задержкой, что означает, что я не могу иметь свои знания в модели, где у меня могут быть какие-то мировые знания в модели, которые всегда полезны, но знания о моей бизнес-домене, например, я не буду использовать свою модель как источник, потому что моя модель знает только о данных, на которых она была обучена, которые могут устареть. И модель не всегда способна обеспечить взаимодействие с очень низкой задержкой.
Второе — вы хотите иметь возможность хранить структурированные данные, а также полуструктурированные и неструктурированные. Так, много ценности в неструктурированных данных, что является частью того, что означает революция агентских систем и ИИ. Вы также хотите иметь возможность охватывать разрозненные источники, потому что да, у меня может быть очень узконаправленный ИИ, который решает конкретную узкую проблему внутри компании, но на самом деле Святой Грааль здесь с ИИ — это использование как можно большего объема знаний компании о клиенте, о продуктах, партнерах, цепочке поставок и так далее, других участниках, конкурентах, людях в компании. Чем больше у вас есть доступ к этому для каждого агентского решения в рамках того, что уместно и законно использовать в конкретном сценарии. Тогда мы переходим к управлению доступом в дальнейшем. Чем больше у вас есть доступ ко всем данным в предприятии, тем лучше вы сможете иметь интеллектуальный ИИ, который принимает хорошие решения.
Еще одно — вы хотите иметь возможность хранить агентскую память. То есть память о ваших взаимодействиях вместе с вашим корпусом RAG. А также вам нужен определенный уровень управления. Потому что агенты действительно не имеют, помимо того, что у них нет разбора того, какие данные уместны для какого типа использования, в зависимости от того, какую проблему они решают, каковы юридические требования, что говорят брандмауэры в разных частях банка, которые не должны общаться друг с другом. Каковы элементы управления конфиденциальностью. Таким образом, вы хотите иметь возможность контролировать знания, которые поступают в систему ИИ, в зависимости от уместности, и это включает этику, законность и конфиденциальность.
Что делают люди? Вот пример от ведущей игровой компании, которая строила приложение, где у них было 150 нетехнических сотрудников. Бизнес-аналитики пытались лучше понять свои данные, чтобы продвигать бизнес и иметь возможность задавать действительно сложные вопросы на естественном языке, не будучи привязанными к конкретному источнику. И они внедрили то, что я покажу на следующем слайде, уровень знаний ИИ, который основан на хранении данных в графе знаний, где даже в версии 1 он сократил время, затрачиваемое на ответы на рутинные запросы, на 92%, а затем получил в 10 раз более быстрые ответы, чем традиционные аналитические методы для проведения анализа. А некоторые анализы даже сократились с недель до секунд.
Я вижу это во многих компаниях, и это та же компания, описывающая свой уровень данных. По сути, у них есть какой-то разговорный ИИ, который имеет уровень API для многоагентной системы, а затем этой многоагентной системе нужен доступ к знаниям. Здесь это называлось семантическим уровнем, а откуда берутся эти данные? Ну, они поступают из всех различных разрозненных источников, которые у них есть, либо напрямую, либо, возможно, через что-то вроде Databricks, Snowflake или BigQuery, или какого-то другого озера данных или lakehouse или консолидации. И ключевая идея здесь заключается в том, что в стеке ИИ нужен новый уровень, а именно уровень знаний, чтобы иметь возможность удовлетворить все эти требования, о которых мы только что говорили. И этот уровень — это уровень, который превращает необработанные разрозненные данные в связанные, контекстуализированные знания.
И вот как это выглядит в общем виде: вместо того, чтобы разные агенты общались с разными разрозненными источниками, или агенты общались с озером данных, где у меня есть куча данных, но это как бы все данные во вселенной, я буду извлекать нужные данные. Это может быть 1% или 5% данных в lakehouse. И, что важно, он связывает их вместе. Насколько бы данные ни попадали в lakehouse вместе, часто у вас нет отношений в данных, чтобы обеспечить более богатый контекст, который вам нужен в контексте ИИ.
Итак, этот уровень знаний предоставляет следующие функции: он содержит структуру, контекст и смысл. Он предоставляет унифицированный слой памяти и извлечения для агентов. Таким образом, агенты не путаются из-за того, что каждый агент получает разную картину мира. Он связывает понимание человека и машины. Таким образом, вы хотите иметь уровень знаний, который не только понятен машинам, но и может быть понят и проверен людьми. А затем он связывает и унифицирует ваши различные источники данных и объекты.
И вы можете спросить, как это вписывается в мой существующий уровень данных? И это очень похоже на нашего клиента, которого я показывал ранее, эту большую игровую компанию. Вы, по сути, имеете ваши различные источники данных, либо напрямую питающие уровень знаний, либо питающие какой-то хранилище данных, lakehouse, который затем питает уровень знаний, и уровень знаний должен иметь все данные. С точки зрения методологии, вы действительно хотите иметь возможность начать с малого, решить одну проблему, реализовать ее за несколько месяцев, а затем вы всегда можете добавлять к уровню знаний по мере продвижения.
Какова правильная структура для этого уровня знаний? Я хочу указать на несколько недавних заявлений этого года, где Сатья на Build сказал: "Хорошо, модели являются частью уравнения, но это лишь часть уравнения". Для любого, кто создает агента, вам нужен действительно отличный доступ к реальному времени в Интернете, а также ко всему корпоративному графу знаний. Таким образом, корпоративный граф знаний — это структура, которую вы используете внутри своего уровня знаний ИИ для создания потрясающих агентов. А затем одна из вещей, которую вы можете сделать с этим графом знаний, — это создавать приложения RAG, которые не просто векторные RAG, а RAG с графом знаний, который известен как Graph RAG. Так что хорошо и полезно выполнять векторный поиск, но вы также хотите иметь доступ к графу.
Вот один пример с AWS re:Invent. Это предшествовало предыдущему немного, от Свами, который владеет их портфелем ИИ и данных, говоря о том, как снова граф знаний является идеальным способом хранения знаний, и вам действительно нужен уровень знаний ИИ для ваших корпоративных агентских приложений. И всего за последние пару месяцев я имел честь участвовать в конференциях, которые мы в Neo4j проводили, и на которых разные клиенты выступали на сцене и рассказывали, как им удалось успешно перейти к производству именно с такой архитектурой. Walmart — один из них, они даже написали статью об этом, которая есть на Archive, я дам ссылку немного позже, занимаясь операциями с персоналом для своих 1,6 миллиона сотрудников. И это одно из четырех приложений ИИ, которые работают и широко используются по всей компании. Еще одно от Adobe, создающее ИИ-агента, который мыслит связями. Опять же, ссылаясь на тот факт, что контекст требует связей между данными в вашей области и затем между разрозненными источниками. Еще одно было от AppV. Крупная фармацевтическая компания, которая занимается открытием лекарств, используя этот подход. Они потратили последние несколько лет, инвестируя в большую систему, которая консолидирует знания в одном месте, которое теперь является идеальным местом для отправки всех их ИИ-агентов. Uber имеет конфиденциальный граф знаний, который они используют при адаптации водителей в новых городах, чтобы помочь им детерминированно выполнять все правила, связанные с предоставлением агентам доступа к подробным знаниям о том, какие предложения доступны в каком городе и каковы критерии. И затем еще один пример — Discover, занимающийся анализом маркетинга и поведения клиентов. Таким образом, Customer 360 и Customer Journey.
Это действительно становится проверенным и надежным подходом, который отличает, возможно, 5%, 10% или 20% корпоративных приложений ИИ, которые добиваются успеха, от тех, которые, возможно, застряли в режиме прототипа, и вам трудно удовлетворить все требования для перехода к производству.
Итак, снова характеристики уровня знаний и почему графы в конечном итоге являются идеальной основой для этого: вы хотите уровень знаний, который может связывать разрозненные источники. Так, если у меня есть все различные места в предприятии, где у вас есть данные о клиентах, вы хотите иметь возможность иметь ИИ, который может смотреть на клиентов, а затем, хорошо, какие транзакции произошли с клиентами? Свяжем их вместе. Какие продукты были куплены в транзакциях и кем из клиентов? Свяжем их вместе. Если я всегда могу связать это с цепочкой поставок. Допустим, я хочу провести акцию и предложить продукты определенным клиентам, которые не только желанны для клиента, исходя из того, что он или члены его семьи купили и не купили, но и что есть на полке или скоро появится на полке, и так далее по всей компании. Таким образом, у компаний есть все эти знания, которые, в некотором смысле, логически хотят быть связаны вместе, но на самом деле не связаны просто из-за того, как возникли организации и структуры данных.
Еще одна вещь, которую вы хотите, — это чтобы уровень знаний ИИ был прозрачным. Я намекал на это ранее, что вы хотите, чтобы он был понятен людям и машинам. Итак, позвольте мне привести очень простой пример. Допустим, я пытаюсь представить яблоко. У яблока есть все эти различные характеристики: цвет, форма, размер, сочность, хрусткость, обонятельное ощущение и так далее. Но давайте предположим, что я векторизую это яблоко. Векторное представление полезно. Я могу провести векторное сходство между яблоком и апельсином, или яблоком и теннисным мячом, или яблоком и машиной и увидеть, что яблоко и машина не имеют ничего общего. Яблоко и апельсин немного более похожи. Яблоко и теннисный мяч все еще, возможно, похожи из-за формы и размера, но не похожи в других отношениях, но вы на самом деле не можете узнать, почему, основываясь на структуре вектора или операции сходства. И поэтому дополнение этого, скажем, декларативным представлением в графе знаний может быть очень полезным: я могу сказать, что меня интересует в любом данном яблоке, а затем отслеживать это и передавать это в мою систему ИИ, и иметь эту насыщенность, доступную как для системы ИИ, так и, в конечном итоге, для людей, которые смотрят на нее.
Точность — еще одно важное соображение. Помимо реальных примеров из практики, которые я упомянул, появляется довольно много различных оценок, показывающих, как вы фактически получаете гораздо лучшие результаты, получая контекст из графа знаний и передавая его модели. И есть два разных способа использования графа знаний. Один — я передаю контекст модели и позволяю модели рассуждать. Затем у меня все еще есть некоторая недетерминированность, и у меня нет полной объяснимости, но я немного больше знаю о том, что попало в модель. Так что, возможно, можно сказать, что это своего рода "серая коробка" объяснимости.
Другое, что вы можете сделать, — это на самом деле для сложных вопросов. Возьмем этот. Это был слайд, представленный Adobe, где у них есть некоторые сценарии информационной безопасности, где у них есть топология и куча информации в графе, и поскольку люди могут задавать более сложные вопросы, вопросы могут стать довольно сложными. Вот один, где говорится: "Каково количество уникальных устройств, используемых пятью наиболее активными пользователями с наибольшим количеством записей о входе в страну с наибольшим количеством использований IP-адресов?" Вы можете представить, что эквивалент SQL, вероятно, объединил бы несколько баз данных и множество таблиц, и вашей модели может быть трудно сгенерировать это. И если вы можете сгенерировать запрос, он, вероятно, будет очень большим и займет много времени для выполнения. А с графом они на самом деле могут иметь модель, генерирующую запрос за несколько шагов, и получать ответ на сложный вопрос. И возвращаясь к рассуждениям в этом случае, модель делегирует рассуждение, фактический ответ на этот сложный вопрос базе данных графа, вашему уровню знаний, который затем вычисляет это, потому что оказывается, что у этого есть точный ответ, и вы можете его получить, и это операция с довольно низкой задержкой, а затем роль модели заключается в преобразовании человеческого вопроса в вопрос на языке базы данных, а затем в получении результатов и их обратной передаче.
И что меня удивило, это пример слайда от Uber, но я видел похожие от других компаний, включая Comcast, Walmart и Adobe, как вы только что видели, что модели на самом деле лучше справляются со сложными вопросами при генерации Cypher. Который, кстати, теперь является стандартом ISO в форме GQL, который является родственным языком SQL. Так что это стандарт ISO, чем генерация SQL. Так что это стало сюрпризом даже для меня, как для давнего специалиста по графам. И это связано просто с природой этого вопроса. Оказывается, выразить этот вопрос на Cypher или GQL относительно тривиально, или, скажем так, намного проще, потому что язык больше подходит для этих сложных связанных вопросов. То, что мы видим в этой области, — это гораздо более низкий уровень ошибок для моделей, пытающихся решать сложные вопросы и поддерживать их, делегируя вопрос уровню данных.
Возвращаясь к объяснимости и различению. Таким образом, вы хотите иметь возможность получить, когда это возможно, объяснение того, почему модель приняла конкретное решение, и если вы делегируете обратно в виде запроса, то у меня есть запрос, у меня есть данные, я могу визуализировать их, я точно знаю, почему я получил конкретный ответ, и точно так же я точно знаю, какие базовые данные, чтобы я мог фильтровать их в соответствии с элементами управления доступом, как в этом примере здравоохранения, где врач имеет доступ к диагнозу, но сотрудник службы поддержки клиентов, разговаривающий с пациентом, не имеет.
Вот несколько примеров. Это тот, который я упомянул, который был опубликован. Вот ссылка на статью, где они говорят о своем HR-сценарии и о том, как выглядит общая архитектура. Но вы можете видеть здесь, они нарисовали ее горизонтально, а не вертикально, как у меня было раньше. Но у вас, по сути, есть пользователи с некоторыми агентами с кучей инструментов, а затем граф знаний справа. Вот пример от Uber, где снова похоже, они тоже сделали это слева направо. У вас есть ваш поставщик LLM. Я полагаю, слева от этого у вас есть пользователь, даже с агентом, с кучей сервисов и оценками и так далее, с доступом к графу с обеих сторон.
Давайте вернемся и посмотрим, какие проблемы ИИ существуют на предприятии и в какой степени мы их решим. Одна из них — мы все знаем, что ИИ может совершать ошибки. Это нормально для приложений с низкими ставками, но часто неприемлемо для критически важных приложений. ИИ — это черный ящик. Опять же, это нормально для суммирования документов, заметок о встречах, но если у меня есть что-то регулируемое или с более высокими ставками, многое из того, что ориентировано на клиента, вы хотите иметь возможность заглянуть в черный ящик, и это не означает, что каждая агентская операция проверяется человеком, но это означает, что в рамках вашего процесса контроля качества или, возможно, постфактум, если что-то пойдет не так, и вам нужно показать кому-то с бизнес-стороны или регулятору, что на самом деле произошло. Вы можете сделать это различение.
Это возвращается к использованию правильных данных в соответствии с конфиденциальностью, безопасностью или другими ограничениями, а также к отсутствию контекста, где мы определяем концепцию как сигнал, а не просто шум, и имеем связи, возможно, на несколько уровней вглубь. Так что у вас есть не просто факты о человеке или вещах, непосредственно окружающих его, а немного больше богатого, скажем так, более чем на один шаг, причинно-следственные связи и взаимодействия, и просто благодаря тому, о чем мы говорили, галлюцинации можно решить, делегируя определенные вопросы графу или просто получая более богатый контекст. Аналогично с проблемой черного ящика, аналогично с применением безопасности и контроля доступа и не обучая вашу модель на ваших проприетарных данных, а используя ее с контролем доступа внутри вашего уровня данных. И тогда, контекст — это, по сути, главное, что вы получаете из подхода на основе графа, — это возможность получить контекст и причинность на нескольких уровнях.
Хорошо. Я думал, я потрачу несколько минут перед тем, как закончить, просто говоря о некоторых строительных блоках, которые существуют для построения графа, потому что главный вопрос, который волнует многих людей, — это откуда берется мой граф? Обычно он может исходить либо из структурированного, либо из неструктурированного источника. Итак, я покажу вам некоторые из последних инструментов для обоих. Вот Neo4j Aura — это размещенный сервис Neo4j. Есть бесплатная версия, а затем три платных уровня с различным уровнем доступности, безопасности, поддержки и т. д. Здесь я подключусь к Snowflake. Я реверс-инжинирую схему слева. Я нажму кнопку. И то, что вы фактически получите менее чем за минуту, — это выведенная схема графа, где я могу нажать другую кнопку и просто загрузить все данные в граф, который затем я могу визуализировать. Раньше это занимало у нашей команды профессиональных услуг, работающей с клиентом, неделю, чтобы выполнить все это сопоставление. Теперь благодаря инструментам ИИ вы можете гораздо легче создавать графы из структурированных источников.
А затем другое интересное — это, конечно, неструктурированные источники. Так что, если вы хотите построить граф из неструктурированных данных, то LLM на самом деле оказываются довольно хорошими инструментами, по крайней мере, для создания версии вашего графа с точностью около 60% в первой версии, выполняя извлечение сущностей и отношений из документов или транскриптов, а затем оттуда вы можете выполнять уточнения. Возьмем, к примеру, страницу Википедии о Microsoft, которая, кстати, довольно длинная. Загрузим ее в инструмент под названием LLM Graph Builder, который является как открытым исходным кодом, так и размещенной версией, которую я использую здесь. Расскажем ему немного о том, на что смотреть. Итак, выкачаем эту страницу и извлечем сущности, которые являются людьми, которые, похоже, работают в компаниях, или компаниями, которые запускают технологии, или людьми, которые живут в каком-то месте, а затем просто построим граф, и он это сделает. Затем я могу задать вопрос, например: кто входит в совет директоров Microsoft? Он обратится к графу, прежде чем обратиться к своим собственным внутренним знаниям всего интернета, чтобы найти, какие данные были в документе. Оказывается, на странице Википедии конкретно указано, что по состоянию на декабрь 2023 года вот совет директоров. И я проверил, и это правильно. И вы можете нажать, откуда взялся ответ, и вы фактически увидите граф и получите объяснимость. Вот совет директоров, а затем вы можете увидеть, что некоторые из этих членов совета директоров либо в настоящее время, либо в прошлом работали в Microsoft, а затем под этим находится более крупный граф. Круто.
Если вы хотите узнать больше, есть масса информации. Вероятно, первое место, куда я бы пошел, — это место под названием Graph Academy, где есть куча бесплатных тренингов. Так что просто найдите Graph Academy или перейдите по этой ссылке или используйте QR-код. Еще одно — Deep Learning AI. У нас есть короткий курс по графам знаний и Graph RAG, и у нас есть новый, который был недавно записан и скоро выйдет. А затем есть книга под названием "Построение графов знаний", которая на самом деле вышла незадолго до запуска ChatGPT. Но тем не менее, она не включает информацию о последних инструментах, которые я показал, но это хорошая концептуальная основа о том, какие типы графов у вас есть, потому что у вас есть граф предметной области, граф вашего смысла, то есть онтология, и граф ваших векторов в вашей топологии и так далее.
Итак, я охватил многое, и я закончу здесь, и если у нас будет время для вопросов, я буду рад ответить на некоторые, иначе мы можем перейти дальше. >> Филипп, спасибо вам огромное за это. Это было потрясающе. Я хочу рассказать вам свою историю. Я проработал в Walmart несколько лет. >> О, потрясающе. И мы продвигали графы. Моя команда продвигала графы. Так что слово "обход" использовалось очень, очень обильно в компании, и мы использовали Neo4j. Мы использовали другие графы, мы строили графы сами, и, как оказалось, моя компания также называется Traversal. >> Traversal AI. >> Верно? Так что Neo4j — единственная компания, которая понимает, что означает "обход". Так что это немного, это немного, знаете ли, история происхождения для меня, потому что я искренне верю, что графы как бы являются, и это то, что мы сделали в той части, как я большой, видный, большой сторонник графов в любой форме, я имею в виду, и я также говорю, что не всему нужны графы, но вещи, которым нужен граф, они оставляют базы данных и все остальное позади на много порядков. Мы работаем с одной из компаний из списка Fortune 10, и то, что мы сделали, — это очень интересная реализация. Мы использовали информацию из транскриптов, например, у них есть 10-15 миллионов звонков в их колл-центр, и их транскрипты на этом. Так что мы создали граф знаний из этих транскриптов. Так что кто-то может спросить: "Что насчет трех основных проблем в первом квартале для всех наших клиентов?" Так что это может конденсировать эту информацию. Так что мы были на переднем крае Neo4j, и нам нравится, я говорил параллельно с несколькими людьми из Neo4j, но я просто хочу сказать, что это потрясающий продукт, и о нем знают меньше людей. Я знаю, здесь нет вопросов. Я просто говорю. >> Да. Да. Да. Да. Нет, это здорово, и очень круто слышать вашу историю, и вы правы, для правильного типа данных, которые, как я вижу, если ваша область сложна, скажем так, имеет форму сети, это действительно сводится к форме данных, и вам больше важны просто хранение и извлечение, вам важен контекст, вам важна причинность. Для меня это как бы триггерные слова, и, знаете ли, во многих отношениях я чувствую, что мы случайно создали продукт, который действительно полезен для ИИ, в том виде, в котором ИИ появился за последние несколько лет. >> Хорошо. Да. Джули, давайте перейдем к вопросам и ответам, может быть, зададим пару вопросов, а затем мы как бы, знаете ли, отпустим Филиппа. >> Да, звучит отлично. Я смотрю в чат. У нас довольно много вопросов. Позвольте мне посмотреть. Кто-то спрашивает: "Какие графы знаний лучше всего подходят для определенных отраслей?" >> Это... Да. Так что в финансовых услугах есть довольно большие платежные графы, потому что, прослеживая и изучая закономерности в платежах, вы можете действительно легко выявить вещи, которые иначе были почти невидимы, такие как отмывание денег или различные формы мошенничества. Еще одно — в, знаете ли, в чем-либо, связанном с рекомендациями, или попытках предсказать поведение пользователя. Оказывается, были некоторые социологические исследования, есть книга под названием "Связанные", которая говорит об этом, что если вы пытаетесь предсказать чье-то поведение, и, скажем так, у вас есть выбор между предоставлением кучи фактов о человеке или предоставлением поведения и взаимодействий людей, не их друзей, и даже друзей их друзей, или даже друзей их друзей, или людей, которых они не знают, даже их друзья их не знают. Оказывается, граф друзей ваших друзей, как их подграф взаимодействий, является лучшим предиктором вашего поведения, чем куча фактов о вас, что поражает. Так что, кстати, другой вывод: будьте осторожны, кто ваши друзья. И вы влияете на людей способами, которые вы даже не видите. Так что это довольно мощно. И поэтому в рекомендациях, путешествиях, например, в развлечениях, возможность предсказать, какой контент человек может захотеть посмотреть, путь пациента, открытие лекарств, где у меня есть граф биологии и все взаимодействия. Телекоммуникации. Я только что был на мероприятии ранее, и буквально основатель стартапа запрыгнул в мою машину и сказал: "Эй, я хочу поговорить с вами. Давайте просто поговорим по дороге домой, и вы можете высадить меня на вокзале, и я вернусь на поезде". И он фактически построил свою платформу наблюдения для анализа первопричин после того, как у меня возникло оповещение, и попытался выяснить, какие контейнеры Kubernetes и сервисы и что идет не так, и чтобы агенты выяснили все это. Все это было основано на графах, потому что, знаете ли, это очень сложная и связанная область. Так что довольно много, это несколько примеров из некоторых ведущих областей. >> Вау, это отличная история. Хорошо, у нас есть еще несколько вопросов из чата. Так что я просто перейду к первому, который я вижу. Итак, могут ли графы знаний использоваться для автоматизации BI в бизнес-группах по финансам, коммерции, цепочке поставок, маркетингу и НИОКР в биотехнологической компании? >> Да. Да, но я бы сосредоточился не на попытке воспроизвести виды BI, которые у вас уже есть, потому что есть куча отличных BI, таких как Looker, Tableau, и, знаете ли, Business Objects и так далее. Они отлично справляются с теми видами BI, которые они делают, которые больше связаны с нарезкой и анализом данных. Так что то, чем вы хотите это дополнить, довольно часто, скажем так, в биотехнологиях, это какие дополнительные сведения я могу получить, понимая связи либо внутри высокосвязанной области, либо между различными областями. Мы на самом деле недавно использовали ИИ для создания продукта, или, скорее, теперь предлагаем продукт для создания панелей мониторинга, который вы найдете, например, просто как часть нашего стандартного пользовательского интерфейса, и все инструменты, чтобы просто нажать кнопку и сказать "создать кучу панелей мониторинга", что довольно круто. Другое, что может быть удивительным во многих науках, — я расскажу вам историю об одном из наших первых клиентов из фармацевтической отрасли, который фактически использовал Neo4j. Они начали с сообщества, которое является открытым исходным кодом, а затем, конечно, для более серьезных вещей, они перешли на коммерческую версию, корпоративную, или теперь они используют облачную версию Aura. Но что они сделали, это сказали: "Давайте возьмем биологию различных взаимодействий между молекулами и экспрессией генов и белками и ферментами и так далее, и клетками и так далее, болезнями и состояниями". Давайте представим это как граф и визуализируем это как граф, так что вы фактически можете видеть узлы и отношения, представляющие взаимодействия, а теперь давайте привлечем кучу ученых, не ученых по данным, а людей, для которых биология является их основной областью, и пусть они посмотрят на это и увидят свою область по-новому, и оказывается, что это было так мощно для них, чтобы фактически увидеть взаимодействия в области, которую они изучали в течение многих лет, что они буквально выбежали из комнаты, схватили своих коллег и сказали: "Я вижу биологию, как впервые. Я действительно могу понять, как это работает". Так что я бы сказал, если вы можете расширить BI этими уникальными видами инсайтов и взаимодействий и различными видами визуальных выражений, наряду с вычислительными выражениями, то абсолютно. >> Вау. Я в восторге от ответа и от того, как вы его сформулировали. Филипп, спасибо вам огромное за ваше время. Это было потрясающе. Спасибо. Вы знаете, я знаю, что у вас был плотный график и все такое. Это честь иметь вас. Я уже давно являюсь большим, большим, большим сторонником графов, и я говорю людям, знаете ли, я преподаю в нескольких университетах и руковожу стартапом, и в каждом из них есть графы, у нас есть отдельная глава, посвященная только графам знаний от Neo4j, мы >> это потрясающе, ну, нам определенно стоит поговорить больше вне конференции, но так здорово встретиться здесь, и честь принадлежит мне, действительно спасибо всем вам, кто присутствовал, и всем, кто принимал. >> В моей книге о RAG я буквально написал главу о графах знаний, обучая, как использовать Cypher, и мы сделали кучу веселых вещей. В любом случае, Филипп, спасибо вам огромное. Спасибо вам огромное за то, что присоединились.