Transcription
Привет всем! Доброе утро, добрый день и добрый вечер всем зрителям! На самом деле, наши замечательные люди… на самом деле, на этот раз у нас Мэтт и Рид, два давних друга, более десяти лет. Мы очень-очень рады видеть их здесь с нами во время этого вебкаста. И тема сегодня — о важности инфраструктуры в генеративном ИИ, особенно для предприятий.
Прежде чем я начну, давайте начнём с Мэтта. Мэтт, вы хотели бы представиться?
Босс: Да, конечно. Меня зовут Мэтью Грей. Большую часть моей работы составляет облачная инфраструктура. В последнее время это связано с проектированием облачной инфраструктуры специально для платформ ИИ. Моя жена и я владеем и управляем небольшой консалтинговой фирмой по разработке программного обеспечения в Оксфорде, штат Миссисипи, под названием Hatboy Software. И я рад быть здесь.
Это здорово! Спасибо, Мэтт, за то, что вы это делаете. Я ценю это. М, Рид, ваш ход, босс.
Привет, Ло! Спасибо большое, что пригласили меня. Я тоже очень рад быть здесь. Итак, меня зовут Рид Патрик, и я — Azure MVP. Было девять, надеюсь, десять раз. Мы готовимся к продлению, нужно заполнить всю эту бумажную работу. Но, как и Мэтт, мы с Мэттом много работаем вместе, и мы довольно долго проектируем и создаём облачные платформы сами или вместе. И большую часть года, хотя это кажется собачьими годами, за последний год мы создавали инфраструктуру Azure OpenAI. У меня большой опыт работы с Bicep, Terraform, PowerShell и так далее. И мы любим создавать вещи, которые работают, и мы любим создавать вещи, которые масштабируются, особенно с помощью кода. Да, я рад поговорить об этом. Это новый мир, Ло.
Это здорово, мужик! Да, и я имел удовольствие и честь работать с вами обоими над многими крупными проектами корпоративного уровня, которые требуют серьёзной инфраструктуры с AKS, с ACAs, с изобилием безопасности. Многому научился у вас, ребята. Большое спасибо! И я подумал, что было бы неплохо нам провести, может быть, 30-минутную беседу, и я уверен, что многим людям будет интересно узнать о шрамах, которые вы оба получили, создавая инфраструктуру для генеративного ИИ. Так что позвольте мне начать. Мы выберем одного из вас. Давайте начнём с Мэтта, например. Мой первый вопрос к вам, Мэтт: насколько важна хорошо спроектированная инфраструктура для ИИ корпоративного уровня? Следует ли вам создавать всю архитектуру с самого начала или плыть по течению?
Ну, очень важно подумать о вашем варианте использования. Например, проектируете ли вы для большой организации, которая должна обслуживать большое количество пользователей, например, университет? Вам нужно уметь работать в масштабе. Как вы это учитываете? Есть ряд различных факторов, которые необходимо учитывать. Кроме того, каковы ваши варианты использования? Будете ли вы использовать векторизованные индексные хранилища для шаблонов дополнения поиска? И как вы будете это поддерживать? Итак, есть много вещей, которые нужно учитывать, когда вы это делаете, в том смысле, что вы хотите убедиться, что ваша инфраструктура спроектирована так, чтобы минимизировать задержки и при этом обслуживать объём трафика, специфичный для вашего варианта использования.
Один из вопросов, вероятно, для вас обоих, ребята. Извините, я просто хочу убедиться… Что для вас обоих является ошибкой, которую даже опытный инженер по инфраструктуре… они спроектировали что-то для GenAI, и через пару месяцев, типа: «О, не стоило так делать. Сделай это асинхронно».
Да, и я думаю, что одна из ключевых вещей, которые мы видели с решениями, которые быстро создаются разработчиками, — все хотят заниматься ИИ, мы хотим сделать это быстро, все компании говорят: «Да, вы можете сделать это так быстро». И всё такое, но скорость и предприятие не очень хорошо сочетаются, верно? И одна из вещей, которые мы видели, важна, и это не только ИИ, Ло, это для всего, что связано с облаком, всё, что вы создаёте быстро, — это то, что значением по умолчанию для облака является использование ваших учетных данных, то есть ваш идентификатор входа, это единственный ров, это единственный элемент безопасности, и это не сработает в компании, вам нужно подумать о безопасности сети, методах шифрования, где хранятся данные, как к ним получить доступ и даже кто может получить к ним доступ. Одна из вещей, которые мы много видели с этими решениями ИИ, особенно в сценарии типа ChatGPT, где люди задают вопросы, загружают файлы и тому подобное, — это весь этот мусор. Что они спрашивают? Что они загрузили? Если компания берёт решение и предоставляет его всем своим сотрудникам, и первое, что они делают, — это заходят на свой жёсткий диск, находят, например, PDF-файл одного из своих счетов и публикуют его, задавая ему вопросы, хорошо, вы просто храните чью-то личную информацию, очень трудно помешать кому-то сделать это, и тот же вариант использования, если они делают что-то для работы, эти вещи должны быть защищены. Поэтому мы действительно заинтересованы не только в том, кто вы, но и в том, как настроена остальная часть сети, безопасность сети и Azure, используя частные ссылки и брандмауэры для исследования и просмотра этих данных, а затем где хранятся эти данные, зашифрованы ли они, как вы можете получить к ним доступ, просто висят ли эти учетные записи хранения в Интернете и тому подобное. Поэтому я думаю, что это своего рода мышление следующего порядка для построения и продвижения к этому решению. И другая вещь — это идентификаторы — это ключи. Я знаю, что у Мэтта сегодня уже был тяжёлый день с этим, но идентификаторы и ключи, когда мы создаём решения, например, в Azure, и, очевидно, все остальные облака тоже имеют эти возможности, вам действительно нужно использовать роли, вам нужно использовать RBAC, систему, например, откуда она берёт информацию, как, например, если у вас есть API, и ему нужно получить доступ к данным в учетной записи хранения, как он это делает, использует ли он просто ключ, потому что если это так, вы не можете сказать, что я хочу ключ только для одного API, если у вас есть ключ, у вас есть ключ, и если кто-то украдёт этот ключ, если у них есть сетевой доступ к нему, вернёмся к частной сети, они могут получить доступ к чему угодно, каждому отдельному вопросу, каждому отдельному идентификатору пользователя, каждому отдельному документу, который был обновлён или загружен и тому подобное. Поэтому я думаю, что все стандартные вещи применяются, помимо использования ролей IM. Да, я имею в виду, что это как любое другое корпоративное решение, вы можете создать что-то в разработке или создать что-то в ПК быстро, но дьявол всегда будет в деталях, и именно здесь всё действительно становится сложным. Я и Мэтт потратили, я даже не знаю, сколько дней, месяцев и лет, разговаривая с людьми о группах безопасности сети и брандмауэрах, частных ссылках и тому подобное, чтобы защитить эти решения, и я могу это отслеживать и видеть, что вы, ребята, делаете каждый день. Посмотрите на все седые волосы. Кстати, Риду 23 года, я просто хочу вам сообщить.
Да, да.
Ладно, теперь я задам вам второй вопрос. Давайте возьмём этот вопрос для вас, Рид, и этот вопрос очень близок к нашим сердцам, вы и я, потому что мы проводим много учебных курсов, у меня есть один по Terraform, но вопрос в том, как компании должны выбирать между Bicep и Terraform, особенно если они развертывают только в Azure. Я знаю ответ на этот вопрос, но я хотел бы поделиться им с остальным миром, как принять это решение. И это не единственные два продукта, есть ещё пять или шесть других продуктов, которые помогут вам сделать это, но эти, особенно для людей Azure, всегда хотят спросить, стоит ли мне использовать Terraform или Bicep, и почему?
Ну, типичный ответ на подобное был бы таким: используйте Terraform, потому что вы можете использовать его в других местах, вы можете использовать его в GCP, вы можете использовать его с VMware, вы можете использовать его практически с чем угодно, вы можете заказать пиццу Domino’s с его помощью, понимаете? Это единственная причина, по которой я его использую, на самом деле…
Совершенно верно!
Вам нужна петля для нескольких начинок из сыра или чего-то ещё. Я думаю, что для меня… я посмотрю на это по-другому и сделаю это довольно просто, и мне интересно услышать, что Мэтт думает об этом тоже, но с моей точки зрения… если у вас есть существующая кодовая база и у вас есть люди, которые умеют писать Terraform, вы знаете, это условие «если-то-иначе», используйте Terraform, вы можете также использовать его, но на один уровень выше было бы то, что если вы действительно собираетесь выполнить только одноразовое выполнение и забыть, Bicep подойдёт, вот моя точка зрения на это, если вы, вы знаете, честно говоря, я думаю, что Terraform проще, чем Bicep, это просто моё мнение, может быть, потому что я использовал Terraform намного больше, но, вы знаете, если вы собираетесь управлять этой инфраструктурой и вы хотите знать, что она делает, и знать её состояние и обновлять её, тогда я бы использовал Terraform, потому что это не просто действие «выполнить и забыть», конечно, вы можете написать Terraform и использовать его только один раз, я имею в виду, что вы можете, но для меня Bicep больше похож на то, что я хочу начать с известной конфигурации, а после этого, вероятно, он просто будет сидеть там или я внесу несколько изменений на портале, может быть, использую CLI и тому подобное, но для меня, если вы собираетесь управлять этим, Terraform был бы тем способом, которым я бы это сделал, и я также сказал бы, что такое, как Terraform, действительно сияет, когда мы можем написать базовый набор конфигураций, а затем просто использовать некоторые переменные для наличия нескольких сред, и у Terraform есть что-то отличное, что называется рабочими пространствами, что чрезвычайно мощно, так что это моя точка зрения на это, быстрый горячий взгляд, мне было бы интересно услышать, что Мэтт скажет об этом.
Ну, я имею в виду, вы знаете, я согласен на 100%, если бы это зависело от меня, на проекте Greenfield, Brownfield или другом, Terraform, просто без сомнений, но именно там лежит большая часть моего опыта в области инфраструктуры как кода. Теперь Bicep совершенно нормальный, и если вы лучше знакомы с Bicep, отлично, для меня это просто ещё один уровень абстракции от шаблонов ARM, и много людей хорошо знакомы с шаблонами ARM, и в этом отношении он очень хорошо сопоставляется один к одному между Bicep и шаблонами ARM, и если вы чувствуете себя комфортно, используйте это, но Terraform предоставляет много дополнительных преимуществ, которых вы не получаете, используя Bicep ARM. Итак, одна вещь, которую я хотел бы добавить, потому что то, что вы только что сказали, заставило меня задуматься о чём-то, это то, что провайдеры Terraform всегда отстают, это правда, и одна вещь с OpenAI — это движение, как вы знаете, каждый… никто никогда не слышал о DeepSeek, а затем он разрушил весь Интернет, а затем, вы знаете, через две недели или что-то в этом роде, он доступен как новое развёртывание в OpenAI… доступен как новое развёртывание. Честно говоря, я не знаю, можно ли использовать Terraform для размещения DeepSeek. Я действительно не знаю, я не пытался этого сделать, но мой ход мыслей таков, что когда что-то попадает в API ARM, то есть вы можете написать для него шаблон ARM, он сразу становится доступен вам и покупается чем-то, проверка кода может быть не обновлена в коде, она может быть такой: «О, я не знаю, о чём вы говорите», но вы получите от этого выгоду. Поэтому, если вы действительно выходите за рамки с вещами, это может быть причиной, чтобы придерживаться Bicep, потому что это будет просто быстро, у вас не будет этой задержки, и мы определённо видели это в прошлом, когда мы пишем большой гигантский… у нас есть огромная кодовая база Terraform, и вдруг мы делаем вызовы REST в коде Terraform, чтобы поместить что-то в Azure, что кажется странным, но если… или я имею в виду, если вы так склонны и думаете, что Go — это потрясающий язык, вы можете пойти обновить провайдера Azure Terraform, хотя, вы знаете, они, вероятно, не улучшат ваши PR, понимаете? Open… я думаю, что они утверждают PR быстрее, по крайней мере, так я видел, поэтому я дам вам свои пять копеек по этому поводу, ребята. Я имею в виду, вы, ребята, боги, когда дело доходит до инфраструктуры, но я такой же, как вы, я сертифицирован по Terraform, у меня есть очень хорошо принятый курс по Terraform на Udemy.com, но главное — я вижу, что Bicep для меня, особенно для Azure, превосходит Terraform в одном, я привык к Terraform, всегда, когда я делаю план, а затем применяю, если план завершается успешно, есть большая вероятность, что применение не завершится успешно, потому что я стреляю снаружи, с Bicep я стреляю изнутри, Bicep идёт напрямую, и если он завершается успешно, он завершится успешно, но Terraform, даже если план завершается успешно, я всё ещё стреляю снаружи, он не пройдёт всю проверку внутри ваших ресурсов, если у вас есть политики, если у вас есть… вот что мне нравится, если это только Azure, если вы делаете какие-либо другие облака, помимо Azure, это Terraform 100%, имеет ли это смысл?
Да, вы знаете, обратное тому, Ло, — это то, что иногда я очень хотел бы знать, что собирается сделать Bicep, вы знаете, пожалуйста, просто скажите мне, что вы собираетесь делать, тогда как Terraform, по крайней мере, пытается… кстати, это не всегда правильно, понимаете? Я тоже это вижу, но, черт возьми, иногда я хотел бы знать… эти проекты AZD, над которыми я и Мэтт работаем с фанатами ИИ, мы хотим, чтобы Bicep дал нам цитаты, да, дайте нам знать, где, почему и как он это сделал. Это довольно круто.
Ладно, позвольте мне спросить, мы вернёмся к Мэтту, и у меня есть третий вопрос для вас, босс. Как безопасность зависит от планов инфраструктуры для проектов генеративного ИИ? Я знаю, что Рид фактически начал с этого, но я хочу углубиться немного глубже, я хочу поговорить о RBAC и Payback для политик, и как инфраструктура для безопасности чрезвычайно важна для предприятия.
Итак, это очень важно, потому что, просто наивно используя OpenAI или любую другую подобную платформу генеративного ИИ, вы слепо отправляете запросы, и это нормально, если вы единственный пользователь, использующий службу генеративного ИИ, но если вы не планируете безопасность, если вы не планируете гранулярный контроль этих данных и данных, которые создаются из них, куда они направляются и кто имеет к ним доступ, это большой потенциальный вектор угроз, это может быть, в зависимости от того, что передаётся, в зависимости от ваших пользователей и того, что они делают с вашей платформой генеративного ИИ, какова цель, это может быть довольно значительным нарушением данных, и поэтому, если вы не планируете должным образом, не только инфраструктуру, но и программное обеспечение за ней, и как оно управляет и обрабатывает эти данные и ограничивает доступ к информации запроса, информации ответа, любому внешнему источнику данных, который он может использовать в части своего анализа, то вы открываете себя для довольно опасной ситуации, по моему мнению.
Да, я возьму то, что только что сказал Мэтт, и упрощу это немного. Допустим, у вас есть набор файловых ресурсов, старые добрые файловые ресурсы в компании, каждый ресурс назначен группе, вы добавляете человека в группу, они могут видеть все файлы, обычно это делается… я имею в виду, это делается миллион раз в день по всему миру, допустим, это больница, у вас есть медсёстры, они могут получить доступ к файловому ресурсу, где они получают шаблоны или документы Word или что-то в этом роде, или, может быть, там есть больше информации, может быть, там есть важная информация, например, частная информация о состоянии здоровья и тому подобное, только эти люди должны видеть всё, ну, то же самое может произойти в сценарии ИИ, когда вы векторизуете все эти файлы и позволяете людям искать их, вам нужен какой-то способ определить, кто должен видеть что, и без наличия политик, а затем RBAC для этих вещей или наличия агентов, которые настроены с этим RBAC, мы даже не думаем об этом, как говорит Мэтт, мы так привыкли к тому, что, ну, я задаю ChatGPT какой-то вопрос или что-то в этом роде, но это не то, что мы делаем, вы говорите о данных, специфичных для домена, это проприетарные данные, верно? Представьте себе сотрудника, который не должен иметь доступ к финансовым данным компании, который может просто задавать вопросы, получать информацию, которую он не должен иметь, а затем он покупает или продаёт акции на основе этой информации, ну, это инсайдерская торговля, и вы только что позволили этому произойти, и это страшно, человек должен был быть очень изолирован от данных, и вы можете открыть весь сарай, так что я думаю, что, как сказал Мэтт, это вопрос планирования, но также и наличие настроек программного обеспечения, которые используют это, наличие модели безопасности, наличие модели риска, а затем как вы её проверяете, знаете, всё такое. Итак, опять же, мы говорим больше об этих сценариях на основе предприятия, где вещи, которые мы думаем, что мы решили с NFS, например, в 1995 году, вдруг становятся в миллиард раз хуже, потому что вместо того, чтобы просто видеть, о, я могу видеть все эти файлы, я могу дважды щелкнуть и открыть их и прочитать их, теперь это просто как… я могу задать любой вопрос во всём мире, и особенно если все ваши данные находятся в SharePoint или что-то в этом роде, и вы векторизуете все эти вещи, я имею в виду, вау, поэтому это действительно большая проблема, это большая проблема.
Это очень большая проблема! Я имею в виду, мы втроём сталкиваемся с этим ежедневно, особенно для компаний финансовой отрасли и здравоохранения и так далее, где информация PII очень интенсивно используется, и это изобилие соответствия нормативным требованиям, и я вижу две разные вещи с безопасностью, которые всегда возникают, у некоторых людей тысячи документов в SharePoint, и они хотели бы, чтобы созданный индекс для этого источника данных следовал тем же разрешениям, которые были предоставлены SharePoint, что является совершенно другой вещью, хранилище векторов отличается от самого источника данных, да, и они хотят убедиться, например, что если вы действительно собираетесь векторизовать базу данных SQL Server, например, если есть столбец зарплаты, и у вас нет доступа к базе данных, векторизованная версия не должна давать вам доступ к зарплате генерального директора, поэтому необходимо внедрить много инфраструктуры, будь то безопасность на уровне столбцов, безопасность на уровне строк, маскировка, мы используем Microsoft Purview для работы с PII и всем этим, но безопасность — это огромная вещь, и каждая финансовая компания или компания в сфере здравоохранения всегда будут опрашивать вас по этому поводу, никто не хочет быть в новостях, поэтому это главное, что происходит прямо сейчас.
Абсолютно!
Это интересно по поводу исправления, знаете, если вы думаете об этом, где вы говорите себе, у вас есть набор данных, у вас есть список SharePoint или у вас есть база данных, и вы говорите, хорошо, это будет доступно там, где люди могут спрашивать об этом, может быть, нам нужно добавить некоторую безопасность на реальном уровне, может быть, вы этого раньше не делали, потому что был очень ограниченный набор пользователей, это не было так важно, но теперь вы пытаетесь сделать эти данные более доступными, но только те части, которые они должны видеть, вам почти нужно выполнить некоторую очистку, прежде чем вы попадёте в другое хранилище, даже так что это интересно.
Да, поэтому архитектура не только для инфраструктуры, но и архитектура индексов, собираетесь ли вы создавать несколько индексов и предоставлять разным людям разные разрешения или вы собираетесь создать один индекс, а затем разделить, кто может получить доступ к чему в индексе, есть много разных способов сделать это, но вы должны подумать об этом, это не готово к использованию. Вы заставляете меня задуматься.
Да, я боюсь. У меня есть ещё один вопрос для вас обоих, ребята. Я вернусь к Риду, и этот вопрос звучит так: как хранение данных и векторизация зависят от надёжного проектирования инфраструктуры для успеха предприятия? Это почти продолжение того, о чём мы только что говорили.
Абсолютно! Я хочу убедиться, что разница между хранилищем данных, которое является источником данных, и векторизацией, они не одинаковы, когда дело доходит до инфраструктуры. Давай.
Ну, я немного посмотрю на то, о чём мы говорили раньше. Я имею в виду, что минимум, с которого мы начинаем, это то, кто имеет доступ, что мы только что обсудили, а затем как вы получаете доступ, и как этот доступ ограничен, потому что, по-моему, это основа — самые важные вещи, прежде чем мы вообще начнём что-либо делать, верно? Учётные записи хранения, такие вещи, или даже, как вы говорите, например, Azure AI Search и тому подобное, места, где индексы используются… прежде всего, мой совет — используйте всё, что Microsoft предоставляет вам в Azure, хорошо? Не используйте лёгкую часть, используйте сложную часть, потому что сложная часть предназначена для безопасности, и не просто думайте об этом… так забавно, потому что до сих пор мы всегда думаем о доступе пользователей и доступе администраторов, но это не так важно, хорошо? Например, у меня есть кластер AKS, и этот кластер AKS имеет… если я просто получаю доступ к удостоверению системы для этой вещи к этому хранилищу векторов, ну, я могу выполнить развёртывание с помощью чего-то простого, что я использую для получения этих данных, а затем извлечь их, поэтому быть очень точным в отношении безопасности, не допускать лёгкого доступа, не оставляйте свою дверь незапертой или не оставляйте свой ключ под камнем на переднем дворе, понимаете? Я имею в виду, эти очень базовые вещи, эти примеры и мышление таким образом, я думаю, очень важны, для меня я — MVP по сетям Azure, поэтому я всегда думаю о сетях в первую очередь, верно? И я действительно… я имею в виду, возвращаясь к основам OSI-модели, верно? Как вы к этому получаете доступ? Как вы к нему обращаетесь? Как он зашифрован? Как приложения получают к нему доступ? А затем повторно применяйте все эти вещи и образ мышления с точки зрения архитектуры, не только пользователей, но и всего, что будет получать доступ к этой системе, поэтому, по-моему, это, вероятно, лучший ответ, который я могу придумать прямо сейчас. Что вы думаете, Мэтт?
Да, вы знаете, вы, по сути, высказали то, что я хотел сказать, если вы просто даёте общий доступ к ресурсу, всё, что нужно сделать, — это захватить этот ресурс, всё, что нужно, — это один злонамеренный субъект в организации, чтобы развернуть микросервис в ваш кластер AKS, чтобы, может быть, развернуть контейнер в одну из ваших служб приложений, которая имеет доступ ко всей вашей важной информации, как только они получили это, всё кончено, поэтому делайте всё возможное, чтобы ограничить доступ, используйте минимальные права не только для ваших пользователей, но и для ваших ресурсов, ограничивайте как можно больше доступ, который ресурсы имеют к другим ресурсам в облаке.
Мэтт, я просто хочу добавить к тому, что вы сказали, потому что, когда вы сказали минимальные привилегии, вы и я потратили кучу времени, когда мы смотрим на API, получающие доступ к вещам и тому подобное, вы и я и каждый другой человек на планете, мы — люди, а это значит, что мы ленивы, настолько легко сказать: «Я использую управляемые удостоверения, я назначаю им роли для получения доступа», и вы идёте и смотрите на роли, и все они говорят «сотрудник», потому что первое, что вы думаете себе, хорошо, давайте дадим ему доступ, ну, это лёгкий вариант, сотрудник, но в Azure есть так много встроенных ролей, например, и они очень мелкозернистые, поэтому вы можете быть ленивыми и дать… я не знаю, какой термин был бы таким, как вы знаете, дать слишком много прав, знаете, в основном, дать ему больше, чем нужно, вместо обратного, то есть дать ему только минимум, который ему может понадобиться, чтобы быть ленивым, вы можете быть действительно ленивыми и дать ему всё, но тогда какой смысл, я имею в виду, вы можете просто использовать ключ или что-то в этом роде, вы оставляете дверь нараспашку, да. Итак, например, и просто, вы знаете, одну вещь, которую я собираюсь добавить к этому, просто общее утверждение, если вы… если вы используете кластеры AKS, и вы не используете удостоверение рабочей нагрузки, вы делаете это неправильно, конец истории.
Да, точно, и не оставляйте этот API в Интернете, используйте частные ссылки, да ладно.
О, абсолютно, частная сеть, всё таким образом — это всё.
Абсолютно! Ребята, это был замечательный полчаса, я знаю, что время идёт быстро, не так ли? Оно идёт так быстро, но для меня всегда большая честь слушать, как вы, ребята, говорите о технических вещах, что просто потрясающе! Большое вам спасибо! Мы должны сделать это снова очень скоро, хорошо?
Абсолютно! Другая тема, и я уверен, что многим людям понравится услышать о всех шрамах, через которые мы все проходим, с приложениями и инфраструктурой корпоративного уровня. Спасибо, ребята, замечательного дня и отличных выходных! И увидимся скоро!
Спасибо!
Спасибо, Ло! Увидимся позже!
Спасибо, Ло! Не спеши! Пока, Рид!