Unisim Soft

Oracle провел прорывное онлайн-мероприятие с участием Хуана Лоаизы и Ларри Эллисона, которое Вы не захотите пропустить - объявление глобальной стратегии Oracle Database + AI.

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

^{Субтитры к видео:}

Кендалл Фишер: 0:09 Привет всем, добро пожаловать на глобальный запуск Oracle Database 23 Ai. Чтобы начать этот монументальный выпуск, у нас есть Хуан Лоаиса, исполнительный вице-президент по технологиям баз данных критического назначения, и особый гость, наш основатель и технический директор, Ларри Эллисон. Итак, без лишних слов, передаю слово вам, Хуан.

Хуан Лоаиса: 0:32 Спасибо, Кендалл. И спасибо, Ларри, что присоединились ко мне сегодня для обсуждения Oracle Database 23 Ai. Это революционный выпуск для индустрии, мы добавили более 300 основных новых функций в Oracle Database 23. И у нас есть тысячи улучшений. И есть три основные области, на которые мы смотрели. Одна из них - ИИ, другая - разработчики, и третья - миссионерски критические. И сегодня мы собираемся обсудить некоторые из основных функций, основные изменяющие игру функции в этом выпуске. Итак, начнем с ИИ. Наверное, самая важная функция в этом выпуске для ИИ - это векторный поиск ИИ. Чтобы дать всем немного предыстории, векторный поиск ИИ - это новая возможность, которая позволяет базе данных искать данные по их содержанию. Например, вы можете искать документы по их содержанию, не слова в нем, а общее содержание и концепции в нем. Вы можете искать изображения, вы можете искать видео, вы можете искать аудио, вы также можете искать реляционные данные по их концептуальному содержанию. Итак, ваши мысли о векторном поиске ИИ, Ларри?

Ларри Эллисон: 1:41 Ну, возможность смотреть на изображение, преобразовывая все в векторы, я преобразую изображение, преобразую строку пар оснований ДНК, сводя все к вектору, позволяет базе данных на самом деле находить похожие картинки. Так что если я хочу найти все картинки одной лаборатории в моем альбоме, я могу это сделать. На самом деле, я пробовал это вчера. Хуан, у меня нет ни одной твоей фотографии. Но но но я подтверждаю, что с помощью векторного поиска Oracle система позволяет нам, как вы говорите, искать содержание данных и находить сходства, у нас были векторы, векторные поиски и поиски сходства. Поиск сходства существует уже очень долго. Это не одна из новых вещей, новых вещей, но векторизация. Но теперь все это хранится в базе данных, все это мы можем преобразовать практически что угодно в язык, вот как работают большие языковые модели, они преобразуют язык в векторы. И они смотрят на фразы, которые похожи. Они могут связывать фразы, которые идентичны или почти идентичны, так они отслеживают плагиат, кстати, правильно? Правильно. Теперь плагиат практически невозможен. Потому что я могу сделать векторный поиск и это не обязательно должно быть точным совпадением с тем, что вы написали. Но если это очень похоже, очень похоже на то, что вы написали, векторный поиск найдет это, и тогда это интересная способность встраивать преобразование данных в векторы, а затем находить векторы, которые похожи друг на друга, то, что мы говорим, что они говорят, это близко в векторном пространстве.

Хуан Лоаиса: 3:23 Ларри, каковы ваши мысли о векторах? Должны ли они поставляться как отдельный продукт? Или они должны поставляться как функция базы данных?

Ларри Эллисон: 3:34 Я думаю, я думаю, это функция. И, знаете, были базы данных XML, если кто-то достаточно стар, чтобы помнить базы данных XML. Каждый раз, когда появлялся новый тип данных, если хотите, каждый раз, когда появлялась новая функция, кто-то думал, что это отличная возможность для разработки очень быстро разработать и предоставить новый вид базы данных. И, опять же, XML - это, пожалуй, мой любимый пример, он не продержался очень долго. Но но у нас были объектные базы данных, у нас есть реляционные базы данных, у нас есть встроенные, но ответ, я думаю, ответ всегда заключается в том, что все ваши данные должны быть в одном месте, это просто делает жизнь намного проще, чтобы задать вопрос как запрос, который охватывает охватывает, вы не знаете, какой запрос вы хотели бы иметь. Обычно самая сложная проблема - это найти данные. И но если вы храните все данные в одной, одной базе данных, которая требует, чтобы эта база данных обрабатывала каждый тип данных, будь то графический тип данных, будь то вектор, будь то XML, будь то смежный смежный документ, будь то таблица SQL. Так что мы думаем, что правильный способ подхода к этой проблеме - это иметь базу данных, которая может управлять всеми вашими данными, а затем может и делать это высокопроизводительным очень и очень экономичным способом.

Хуан Лоаиса: 4:58 Это интересная новая технология. Да, и вы знаете, другие области находят аномалии, которые могут быть такими вещами, как мошенничество или сломанные части на заводе, такие вещи. Так что у неё есть много разных применений. И, конечно, одно из основных - это сочетание её с LLM с AI чатом. Так что теперь вы можете в основном вести естественный языковой AI чат с данными в вашей базе данных. Например, вы можете задать вопросы о вашем банковском счете, или о вашем телефонном счете или о вашей медицинской истории. И мы, локальная база данных, возьмем этот вопрос и используем векторный поиск ИИ, чтобы найти соответствующие данные в базе данных. Так что ваши медицинские записи, данные вашего счета, ваши телефонные записи, и затем мы можем ответить на вопрос снова используя LM, используя естественный язык. Так что это большая новинка. Да.

Ларри Эллисон: 5:46 Ну, это означает, что они называют это поколением с усиленным извлечением, где мы можем сделать это несколькими способами. Мы можем сделать это с помощью инженерии запросов, где вы можете фактически включить некоторые данные в вас, прежде чем вы зададите свой вопрос, вы как бы говорите большой языковой модели, дайте ей некоторый контекст, прежде чем задать свой вопрос. Но на самом деле, это не очень хорошо масштабируется. И, специализируя и персонализируя большие языковые модели с вашими данными, это то, что вы можете сделать с векторной базой данных Oracle. Так что у вас есть обученная, основная модель, которая обучена, но она не знает Adobe, у неё нет ваших резервных записей. И у неё нет вашей личной электронной почты, вы знаете, что это не публичные данные, на которых обучаются эти большие языковые модели. Но вы можете специализировать эти большие языковые модели с вашими личными данными, это одна из вещей, которые мы можем сделать, вы можете специализировать эти большие языковые модели с последними клиническими исследовательскими работами, которые были написаны и вышли в последний месяц или около того. И убедитесь, что основная модель актуальна, и её обучение актуально до минуты, потому что самые последние новости находятся в векторной базе данных. Остальное доступно было доступно, когда основная модель была изначально обучена.

Хуан Лоаиса: 7:09 Да, так что это сочетание базы данных и LLM будет потрясающим для пользователей. Так много удивительных новых возможностей, которые раньше были невозможны. Мы также добавили ИИ повсюду, мы добавили ускоренный ИИ exa dated, мы добавили данные, ИИ к Golden Gate. Так что вы можете распределить ваши векторы по всему вашему предприятию, вы можете загрузить данные в Oracle Database 23, которые вы хотите векторизировать и выполнить поиск, не обновляя сразу вашу производственную базу данных. Так что есть много новых возможностей. Хотите описать нашу философию ценообразования и эту технологию ИИ внутри базы данных Oracle.

Ларри Эллисон: 7:49 Как вы и я обсуждали, прежде чем мы приняли решение. Мы думаем, что это трансформационная технология, искусственный интеллект. И мы думаем, что база данных Oracle, векторная база данных Oracle, это высокомасштабируемая, очень мощная, высоко защищенная система, которая может хранить ваши личные данные, высоко защищенные данные, данные медицинских записей, такие вещи, сохранять эти данные очень, очень безопасно. использовать эти данные, чтобы сделать нейронную сеть умнее. И мы думаем, что это так важно, мы хотим побудить вас, мы хотим, чтобы многие люди увидели эту возможность и использовали эту возможность как можно скорее. Поэтому, как говорила бы моя мать, это приходит с почтой. За эти возможности ИИ не взимается дополнительная плата. Они встроены в 23 Ai, последнюю версию нашей базы данных, и каждый, каждый может их использовать. Да.

Хуан Лоаиса: 8:49 Так что это просто там. Так что ИИ - это новая норма. Это будет везде. И мы убедимся, что это доступно для всех ваших данных. Так что давайте перейдем к другой теме разработчиков. Так что еще один большой акцент для нас - сделать разработчиков более продуктивными, сделать данные более удобными для использования разработчиками. Так что большой акцент наш был на унификации JSON графа в реляционном. Так что у нас были JSON и граф доступны в базе данных Oracle много лет, у нас буквально ведущие в отрасли технологии. Но до сих пор вам приходилось выбирать один. Так что вы форматируете свои данные либо как реляционный JSON, либо как граф. И как только вы выбрали этот один формат, вы получаете все преимущества этого формата. Но вы также получаете все ограничения и недостатки этого формата. Так что большая новинка в 23 AI - это то, что мы унифицировали их. Так что теперь вы можете хранить свои данные один раз. И затем одна часть приложения может рассматривать их как реляционные и получать к ним доступ с помощью SQL. Другая часть приложения может рассматривать их как JSON, читать и записывать их как JSON, используя JSON API. Так что вы получаете все преимущества JSON, а затем другая часть может рассматривать их как граф и выполнять графические запросы. Так что мы думаем, что это огромное развитие, не только для нас, но и для всей индустрии. И это значительно упростит разработку и сделает разработчиков намного более продуктивными. Так что вы были вокруг этого, это целое представление объектов объектами было проблемой для баз данных на протяжении десятилетий. И вы видели эволюцию этой вещи. Каковы ваши мысли об этой новой технологии?

Ларри Эллисон: 10:19 Ну, я могу просто сказать вам из нашего собственного опыта в создании приложений, первое, первое, что люди решают, ну, я не собираюсь строить фундаментально объектную схему, или я собираюсь строить фундаментально реляционную схему, вы знаете, двумерные массивы. И, казалось, нет правильного ответа, потому что в Oracle мы построили некоторые из наших приложений с объектными схемами, в основном объектными схемами, которые мы должны были управлять в приложении на уровне приложения. И мы построили некоторые из них с основными реляционными схемами. И теперь, но да, и затем мы делаем сопоставление между, но мы всегда будем делать сопоставление между объектами и отношениями, потому что многие транзакции, многие вводы данных намного удобнее в JSON и JSON объектах. И люди плюс люди не любят, прежде чем они начнут программировать, полностью определять свою реляционную схему, многие программисты сопротивляются равным и я имею в виду, что no SQL раньше означало, что no SQL теперь означает не только SQL, они решили, что они действительно не хотят полностью отказываться от SQL. Но многие программисты хотят начать строить свое приложение и начать собирать информацию как можно скорее. И они не хотят заранее выяснять, какой будет их схема. Так что то, что мы сделали, это позволило вам определить ваши JSON объекты. И мы сгенерируем реляционную схему из этого. И красота этого в том, что вы можете затем запрашивать все ваши данные, что очень трудно сделать, если вы действительно используете объектную базу данных. Наличие мощного языка запросов - это не то, что идет с объектными базами данных. И это фундаментально для реляционных. Так что у нас есть вся мощь языка запросов SQL, чтобы сидеть поверх объектов. Но мы делаем вы можете рассматривать их как объекты, JSON объекты, или как реальные как отношения, они сосуществуют, вам не нужно предварительно определять схему, вы программист, вы можете начать писать свое приложение. Но во что они попадают, когда они пишут свое приложение без предварительного определения схемы, если они хотят внести изменения, они хотят развивать эту схему, они хотят добавлять вещи к ней, они хотят изменять вещи, это очень трудно сделать с объектной схемой с основной реляционной схемой, эволюция схемы довольно легка. Так что есть преимущества объектов, есть преимущества отношений к двумерным таблицам. С Oracle 23. Ai, вы получаете оба вы получаете все преимущества объектов, вы можете использовать объекты, вы с вашей точки зрения, вы можете думать об этом полностью как об объектной базе данных. После этого вы сказали подождите секунду, мне нужен мощный язык запросов и мне нужно сделать некоторую эволюцию схемы. Нет проблем. Это действительно оба. Вы получаете лучшее из обоих миров с этой унификацией. И это совершенно бесшовно. Я, некоторые пользователи могут думать об этом одним способом, а кто-то просто думает, но другим способом. Все работает.

Хуан Лоаиса: 13:13 Да. Так что это проблема, которую мы пытались решить на протяжении десятилетий. И мы чувствуем, что мы там. Теперь. Это оно, знаете, на самом деле, как только вы это поймете, это намного проще, чем тогда некоторые вещи, которые мы пробовали в прошлом. Это интересно.
Ларри Эллисон: 13:27 О, это все автоматизировано, раньше нам приходилось делать это на уровне приложения, правильно, нам приходилось делать многое, это никогда не было полностью прозрачным, чтобы перейти от объектов к отношениям. Приложение должно было знать об этом. Теперь это не так. Разработчик приложения, пользователи могут видеть объекты, если они хотят, знаете, нажать переключатель, и они видят те же данные в отношениях, они могут работать, работать через оба набора.

Хуан Лоаиса: 13:54 API, правильно? И граф - это еще одно преимущество, которое позволяет выполнять эти графические запросы для навигации. Верно?

Ларри Эллисон: 14:00 Да, нет, граф - это еще один пример модели, которую мы включили. Так что мы действительно объединили три отдельные модели в 23. Ai, верно.

Хуан Лоаиса: 14:10 И это даже не приложение за приложением, это вопрос использования. Так что вы можете использовать его, знаете, один формат, затем использовать другой формат.

Ларри Эллисон: 14:18 О, точно, точно. Так что вы можете построить все ваши приложения для ввода данных, используя схему JSON. И вы можете построить все ваши аналитические приложения, используя SQL-таблицы. И на языке SQL, и эти два человека и эти два разных случая использования, одно и то же приложение, те же данные, все то же самое, просто разные случаи использования, аналитика против ввода данных.

Хуан Лоаиса: 14:40 Да. Да, это здорово. Так что вы упомянули, что нет SQL, так что в последнем десятилетии был большой толчок к no SQL и также к избавлению от транзакций, транзакции считались своего рода, в лучшем случае раздражением, а в худшем - проблемой. И поэтому было движение, движение управления транзакциями в приложение. Теперь одна из вещей, которые мы сделали с Oracle Database 23, это то, что мы решили некоторые давние проблемы с транзакциями, потому что у транзакций были некоторые проблемы. Так что среди них - транзакции без состояния. Так что как транзакции отдыха, знаете, как мы читаем данные и записываем их обратно и убеждаемся, что никто их не записал? Ну, ну, пока я смотрел на это, еще одно - это долгосрочные транзакции. Мы не хотим блокировать строку на долгое время, что блокирует других пользователей. И еще одно - это микросервисы, как вы поддерживаете консистентность микросервисов? Так что это области, в которые мы вложили много работы. Так что я думаю, вы знаете, уже что тенденция к переносу транзакций в приложение действительно как бы умирает, потому что люди пытались, это не работает так хорошо. Так что теперь я думаю, что действительно нужно вернуться к, знаете, целостности данных. Я имею в виду, что вся идея целостности данных как бы многие люди потеряли из виду эту консистентность данных. Так что ваши мысли по этому поводу?

Ларри Эллисон: 15:53 Ну, опять же, это вопрос повторного открытия. Да. Транзакции могут иметь сложности, конечно, долгосрочные транзакции, удерживающие блокировки слишком долго. Вы знаете, у Oracle всегда была уникальная модель блокировки, у нас действительно нет, у нас есть блокировки обновления, у нас действительно нет блокировок чтения, что очень необычно, я не собираюсь тратить много времени на разговоры об этом. Но это решает множество проблем с долгосрочными транзакциями уже, но это не было. Но были определенные случаи, были определенные случаи, когда более долгосрочные транзакции были проблемами с базой данных Oracle также. И мы решили это и, кстати, перенося это в приложение, вы просто говорите: Хорошо, у меня есть эта замечательная идея, вместо того чтобы решить проблему один раз в базе данных, и разработчики приложений вообще не должны беспокоиться об этом. Но каждый раз, когда вы пишете приложение, вы должны обрабатывать тренд, у вас есть консистентность данных в приложении, о, это делает ваши данные, ваше приложение почти невозможным для написания. И это делает ваше приложение в 10 раз сложнее для чтения, это не очень хорошая идея. Чем больше вещей вы можете закрыть в стеке, тем лучше, чтобы убедиться, что у вас есть данные, данные. И то же самое с безопасностью. Если вы хотите закрыть это. Вы не хотите, чтобы разработчик приложений рисковал, но был ответственен за безопасность, вы не хотите, чтобы разработчик приложений был ответственен за приложение получает очень консистентность данных, это должна быть ответственность базы данных. Так что разработчик приложений сосредотачивается на выполнении работы, создании этого приложения и наследовании снизу из базы данных данных, как безопасность, консистентность, надежность, все это должно быть сделано на уровне базы данных, а не обязательство.

Хуан Лоаиса: 17:30 Да, идея о том, что целостность ваших данных настолько хороша, насколько хорош ваш худший разработчик в его худший день. Что вы думаете об этой идее? Ларри, это хороший план?

Ларри Эллисон: 17:40 Я думаю, потому что мы были очень необычным гиперскаляром. Мы оба предоставляем инфраструктуру, такие вещи, как автономный Linux и автономная база данных Oracle. И мы также строим много приложений, будь то в области здравоохранения, или ERP, или управление человеческими ресурсами, мы строим большое количество различных отраслей, мы строим много приложений. И, опять же, я думаю, вы хотите, чтобы эти разработчики приложений были высокопродуктивными. И поэтому вы не хотите обременять их проблемой получения консистентности данных, верно. И к тому же, вы действительно не хотите проверять каждое отдельное приложение, чтобы убедиться, что, знаете, консистентность данных запрограммирована правильно в приложении. Это должно быть то, что вы просто наследуете от основной инфраструктуры, от основной базы данных. Давайте сосредоточим разработчиков приложений на том, что делает приложение, а не на основных проблемах, таких как консистентность данных. Да.

Хуан Лоаиса: 18:40 Итак, вот еще одна связанная проблема, что появилась новая технология, которая заключается в кэшировании на среднем уровне. То есть кэширование базы данных на среднем уровне. Теперь на рынке есть ряд продуктов, которые кэшируют данные. И это работает так: разработчик приложений читает данные из бэкенда и вручную помещает их в кэш, а затем управляет их согласованностью в кэше. Вот что сейчас есть на рынке. Одной из функций, которую мы добавили в Oracle 23, называется True cache. И это действительно настоящий кэш, а не народный кэш. У нас есть кэш приложений на среднем уровне, разработчик просто выполняет обычные операции с базой данных против этого запроса SQL JSON, если данных нет, он автоматически извлекает данные из базы данных, вам не нужно делать это вручную. И когда он извлекает данные в базу данных, она автоматически поддерживает их согласованность. Так что вам не нужно беспокоиться о том, что кто-то изменил данные, когда у вас устаревшая копия данных. Теперь мне придется иметь с этим дело. Так что снова очень похожая вещь. Каковы ваши мысли по этому поводу кэширования на среднем уровне?

Ларри Эллисон: 19:48 Ну, я думаю, что то, что люди делали на уровне приложений, создавая свои собственные кэши среднего уровня, было просто способом мониторинга рынка и понимания того, что они хотели лучшей производительности. Так что, знаете, кто-то однажды пошутил и сказал, что три способа улучшить производительность - это кэширование, кэширование и кэширование. Я думаю, что это немного упрощение. Но в этом есть доля правды. И поэтому наличие этого кэша среднего уровня для базы данных очень важно. Но опять же, это не должно делаться на уровне приложения, приложение должно просто ожидать, что база данных обеспечит такую производительность, храня согласованный кэш данных для них на среднем уровне, чтобы они получали улучшенную производительность, не прилагая никаких дополнительных усилий в своем приложении. И это то, что мы сделали, предоставив true cash.

Хуан Лоаиса: 20:38 Да, по сути, невозможно поддерживать его согласованность, даже если вы попытаетесь, так что это случай, когда неважно, что вы делаете, потому что вы не знаете, когда кто-то меняет данные в бэкенде, и ваши данные перемещаются вперед и назад во времени, потому что часть данных вы загрузили ранее и позже, и они изменились, и вы знаете, перемещаетесь вперед и назад во времени в приложении. Это сложная проблема.

Ларри Эллисон: 20:59 Это действительно сложная проблема. Но многое, что они берут на себя на уровне приложения, это то, что называется цифровым криком о помощи. Хорошо, смотрите, мне просто нужна эта производительность. Нет. Так что я собираюсь попробовать сделать это таким образом в обязательстве, потому что вы не предоставляете мне это. Так что мы наблюдали за тем, что происходило на рынке, мы поняли, что можем значительно улучшить производительность Oracle. Оттуда, где мы были, идея кэша среднего уровня была хорошей. Но давайте убедимся, что мы делаем это правильно и в базе данных, а не обременяем разработчика приложений с

Хуан Лоаиса: 21:32 Что? Да, это абсолютно верно. Так что еще одна вещь, давайте поговорим еще об одной вещи, которая является глобально распределенными данными. Так что теперь все больше и больше стран принимают законы о суверенитете данных, о проживании данных. Это означает, что данные страны должны храниться внутри страны. Однако, если вы предприятие, вы хотите видеть данные как единое глобальное целое, независимо от того, в какой стране они находятся, чтобы вы могли управлять своими операциями на этой основе. И для этого мы представили то, что раньше называли общедоступной базой данных. Теперь это называется глобально распределенной базой данных. И у нее есть две основные функции. Одна из них заключается в том, что вы можете разместить свои данные где угодно в мире. Так что европейские данные идут в Европу, индийские данные идут в Индию, американские данные идут в Америку, все довольны, и это все прозрачно. Другое, конечно, вы получаете гораздо большую масштабируемость. Так что это технология, над которой мы работали долгое время, мы улучшали ее в 23, мы улучшили это много. Мы добавили что-то, что называется репликацией raft, которая позволяет гораздо более быстрое переключение. Так что переключение в единичные секунды, когда у вас возникает какая-то проблема. Так что каковы ваши мысли по поводу всего регулирования данных, суверенитета данных, знаете, этой вещи, которая, предположительно, будет только увеличиваться со временем.

Ларри Эллисон: 22:41 Таким образом, мы сохраняем иллюзию единой базы данных. Хотя это и не единая база данных, она географически разделена, также существуют разделы, предназначенные для надежности и производительности. Вы знаете, есть кэши, и есть много копий этих данных. Но снова, автоматически, мы придерживаемся различных законов о суверенитете данных в каждой стране, шведские законы могут отличаться от украинских законов. И мы реализуем это, реализуем запись требований о том, какие данные должны быть в Швеции, какие данные должны быть в Украине, мы реализуем это все автоматически. И с точки зрения организации, которая владеет данными, которая запускает приложение, это выглядит как единая глобальная база данных. Но с точки зрения соблюдения нормативных требований, мы разделяем ее и соблюдаем все правила. Так что мы снова пытаемся облегчить жизнь людям, которые разрабатывают эти приложения и должны создавать глобальные приложения, но при этом соблюдать местные законы о суверенитете.

Хуан Лоаиса: 23:58 Да. Да. В общем, мы говорили о ряде этих технологий, они не просто лучше, они делают вещи, которые раньше были невозможны. Так что ИИ, векторный поиск, LLM - это возможность проводить транзакции через микросервисы, долгосрочные распределенные. Вещи вроде true cash. Вы знаете, мы говорили о распределенной базе данных, о JSON, объединении с реляционным графом, объединении мировоззрения, это не просто дополнительные функции. Это вещи, которые были болевыми точками для всей индустрии управления данными на протяжении десятилетий, навсегда, которые мы решаем в этом исследовании. Это действительно, я верю, монументально. Так что вы думаете о всем пакете?

Ларри Эллисон: 24:36 Что ж, в целом пакет снова, мы решаем множество проблем. Объектно-реляционное объединение, я думаю, одно из самых больших сделок с логической точки зрения базы данных, одно из самых больших вещей, которые мы когда-либо делали хорошо, самые важные вещи, которые мы когда-либо делали с точки зрения завершения дебатов, должна ли это быть реляционная схема, или должна ли это быть объектная схема? И ответ просто да, это должно быть и то, и другое одновременно. потому что эти дебаты так и не закончились. Но теперь вы можете иметь лучшее из обоих миров, мы можем, мы действительно можем предоставить это ИИ, как вы говорите, это необычайная новая технология. И один из способов, которыми мы знаем, что эти модели обучены на всех данных в интернете, на всех языках в интернете, и на множестве изображений тоже. Это не только язык, на котором они обучаются. Но они не обучены на ваших личных данных, они не обучены на ваших корпоративных данных, вам не предоставлены и не обучены на множестве медицинских записей, потому что эти данные являются частными. Но замечательно то, что наша векторная база данных позволяет вам дополнить обучение основной модели, будь то check GPT от open AI, или grok, или llama, или что угодно, вы можете дополнить обучение этой модели вашими личными данными, вашими корпоративными вашими собственными корпоративными данными с частными данными без необходимости раскрывать эти данные людям, которые строят эти модели. Таким образом, вы можете специализировать ИИ для вашей компании для вас лично для конкретной темы, например, определенного типа рака, чтобы убедиться, что у вас есть все эти данные в одном месте. Так что модель будет умнее, чем она могла бы быть. Потому что вы можете безопасно добавить свои частные данные к этому. Так что потому что вы хотите, чтобы эти данные были анонимизированы. Идентификаторы пациентов не будут там, если вы собираете много данных о раке, но анонимизированные данные сделают гораздо лучшие рекомендации врачам о том, как лечить пациента с раком. Наличие этих данных означает, что у нас есть лучшие рекомендации о том, как врачи лечат рак. И я думаю, что это очень большое дело или как на Уолл-стрит, они захотят и гораздо лучшие рекомендации о том, какую акцию купить дальше, знаете, мы, мы сосредоточены на здравоохранении в Oracle, создаем приложения для здравоохранения. Но есть много приложений для этой технологии и..

Хуан Лоаиса: 27:16 Все новые возможности транзакций, прозрачное кэширование, вы знаете, распределенные данные. Так что я думаю, это не просто очередной релиз, это действительно своего рода монументальный веха в индустрии.

Ларри Эллисон: 27:26
Нет, абсолютно. Я имею в виду ИИ. Я помню, я давал презентацию недавно, является ли ИИ самой важной технологией в истории. И я думаю, я сказал, что, возможно, я ничего не стою, скоро узнаем. И ответ, вероятно, да. Да.

Хуан Лоаиса: 27:41
Может быть, может быть, транзисторы и ИИ. Это две большие вещи. Хорошо, это был отличный разговор, Ларри. Спасибо.

Кендалл Фишер: 27:51
Большое спасибо. Один и Ларри, какой захватывающий разговор, и эй, для всех вас, кто смотрит. Если вы хотите узнать больше о базе данных Oracle 23 Ai, перейдите на oracle.com/database.