Как да внедрите AI модели

Как да внедрите AI модели

Кратък отговор: Разгръщането на AI модел означава избиране на модел на обслужване (в реално време, пакетно, стрийминг или edge), след което целият път да бъде възпроизводим, наблюдаем, сигурен и обратим. Когато версионирате всичко и сравнявате латентността на p95/p99 върху полезни товари, подобни на производствени, вие избягвате повечето грешки от типа „работи на моя лаптоп“.

Ключови изводи:

Модели на внедряване: Изберете в реално време, пакетно, стрийминг или периферно внедряване, преди да се ангажирате с инструменти.

Възпроизводимост: Версионирайте модела, функциите, кода и средата, за да предотвратите отклонение.

Наблюдаемост: Непрекъснато наблюдение на опашките на латентността, грешките, насищането и разпределенията на данните или изхода.

Безопасни внедрявания: Използвайте canary, blue-green или shadow тестване с автоматични прагове за връщане назад.

Сигурност и поверителност: Приложете управление на оторизация, ограничения на скоростта и тайни, както и минимизирайте PII в регистрационните файлове.

Как да внедрим AI модели? Инфографика

Статии, които може да ви харесат след тази: 

🔗 Как да измерим производителността на изкуствения интелект
Научете показатели, бенчмаркове и реални проверки за надеждни резултати от изкуствения интелект.

🔗 Как да автоматизирате задачи с изкуствен интелект
Превърнете повтарящата се работа в работни потоци, използвайки подкани, инструменти и интеграции.

🔗 Как да тестваме AI модели
Проектирайте оценки, набори от данни и точкуване, за да сравнявате моделите обективно.

🔗 Как да говорим с изкуствен интелект
Задавайте по-добри въпроси, задавайте контекст и получавайте по-ясни отговори бързо.

1) Какво всъщност означава „разгръщане“ (и защо не е просто API) 🧩

Когато хората казват „разполагане на модела“, те биха могли да имат предвид някое от следните:

Така че внедряването е по-малко „направете модела достъпен“ и по-скоро като:

Все едно е да отвориш ресторант. Важно е да приготвиш страхотно ястие, разбира се. Но все пак ти трябват сграда, персонал, хладилна техника, менюта, верига за доставки и начин да се справиш с наплива от храна за вечеря, без да плачеш във фризера. Не е перфектна метафора... но разбираш. 🍝

2) Какво прави една версия на „Как да внедрим AI модели“ добра ✅

„Доброто внедряване“ е скучно по най-добрия начин. То се държи предвидимо под напрежение, а когато не е така, можете бързо да го диагностицирате.

Ето как обикновено изглежда „доброто“:

  • Възпроизводими компилации.
    Същият код + същите зависимости = същото поведение. Няма зловещи вибрации от типа „работи на моя лаптоп“ 👻 ( Docker: Какво е контейнер? )

  • Ясен интерфейсен договор.
    Дефинирани са входове, изходи, схеми и гранични случаи. Няма изненадващи типове в 2 часа сутринта. ( OpenAPI: Какво е OpenAPI?, JSON схема )

  • Производителност, която съответства на реалността.
    Латентност и пропускателна способност, измерени на хардуер, подобен на производствен, и реалистични полезни товари.

  • Мониторинг със зъби.
    Метрики, лог файлове, следи и проверки за отклонение, които задействат действие (не само табла, които никой не отваря). ( Книга на SRE: Мониторинг на разпределени системи )

  • Стратегия за безопасно внедряване
    Canary или синьо-зелено, лесно връщане към предишни версии, версии, които не изискват „молитва“. ( Canary Release , Blue-Green Deployment )

  • Осведоменост за разходите
    „Бързо“ е чудесно, докато сметката не изглежда като телефонен номер 📞💸

  • Сигурност и поверителност, вградени в
    управлението на тайни, контрола на достъпа, обработката на лични данни и възможността за одит. ( Kubernetes Secrets , NIST SP 800-122 )

Ако можете да правите това последователно, вече сте пред повечето отбори. Нека бъдем честни.

3) Изберете правилния модел на внедряване (преди да изберете инструменти) 🧠

API извод в реално време ⚡

Най-добре, когато:

  • потребителите се нуждаят от незабавни резултати (препоръки, проверки за измами, чат, персонализация)

  • решенията трябва да се вземат по време на заявка

Внимание:

Групово оценяване 📦

Най-добре, когато:

  • прогнозите могат да бъдат забавени (оценка на риска за една нощ, прогнозиране на отпадане, обогатяване на ETL) ( Amazon SageMaker Batch Transform )

  • искате рентабилност и по-прости операции

Внимание:

  • актуалност на данните и запълвания

  • поддържане на логиката на характеристиките в съответствие с обучението

Стрийминг на изводи 🌊

Най-добре, когато:

  • обработвате събития непрекъснато (IoT, clickstreams, системи за мониторинг)

  • искате решения в почти реално време, без стриктно запитване и отговор

Внимание:

Разгръщане на ръба 📱

Най-добре, когато:

Внимание:

Първо изберете шаблона, след това изберете стека. В противен случай ще наложите квадратен модел да се изпълнява с кръгъл режим. Или нещо подобно. 😬

4) Опаковане на модела, така че да оцелее при контакт с производството 📦🧯

Това е мястото, където повечето „лесни внедрявания“ тихо умират.

Версия на всичко (да, всичко)

  • Артефакт на модела (тегла, графика, токенизатор, карти на етикети)

  • Логика на характеристиките (трансформации, нормализация, енкодери)

  • Код за извод (предварителна/последваща обработка)

  • Среда (Python, CUDA, системни библиотеки)

Един прост подход, който работи:

  • третирайте модела като артефакт от изданието

  • запазете го с етикет за версия

  • изисква файл с метаданни, подобен на карта на модела: схема, показатели, бележки за моментни снимки на данни за обучение, известни ограничения ( Карти на модели за отчитане на модели )

Контейнерите помагат, но не им се покланяйте 🐳

Контейнерите са чудесни, защото:

  • замразяване на зависимости ( Docker: Какво е контейнер? )

  • стандартизиране на компилации

  • опростяване на целите за внедряване

Но все пак трябва да се справите с:

  • актуализации на базовите изображения

  • Съвместимост на драйверите на графичния процесор

  • сканиране за сигурност

  • размер на изображението (никой не харесва 9GB „здравей свят“) ( най-добри практики за изграждане на Docker )

Стандартизирайте интерфейса

Определете предварително вашия входно/изходен формат:

И моля, валидирайте входните данни. Невалидните входни данни са основната причина за грешките от типа „защо връща безсмислени данни“. ( OpenAPI: Какво е OpenAPI?, JSON Schema )

5) Опции за обслужване - от „прост API“ до пълноценни сървъри 🧰

Има два често срещани маршрута:

Вариант A: Сървър на приложения + код за извод (подход в стил FastAPI) 🧪

Пишете API, който зарежда модела и връща прогнози. ( FastAPI )

Плюсове:

  • лесен за персонализиране

  • чудесно за по-прости модели или продукти в ранен етап

  • лесно удостоверяване, маршрутизиране и интеграция

Недостатъци:

  • собствено настройване на производителността (пакетиране, нишки, използване на графичния процесор)

  • Ще преоткриеш някои неща, може би зле в началото

Вариант Б: Моделен сървър (подход в стил TorchServe / Triton) 🏎️

Специализирани сървъри, които обработват:

Плюсове:

  • по-добри модели на производителност веднага след инсталирането им

  • по-ясно разделение между обслужването и бизнес логиката

Недостатъци:

  • допълнителна оперативна сложност

  • конфигурацията може да се усеща... трудна, като регулиране на температурата на душа

Хибридният модел е много често срещан:

6) Сравнителна таблица - популярни начини за разполагане (с честни вибрации) 📊😌

По-долу е даден практичен преглед на опциите, които хората действително използват, когато разбират как да внедрят модели с изкуствен интелект .

Инструмент / Подход Аудитория Цена Защо работи
Docker + FastAPI (или подобен) Малки екипи, стартиращи компании Свободно Лесно, гъвкаво, бързо за доставка - ще „усетите“ всеки проблем с мащабирането ( Docker , FastAPI )
Кубернетс (Направи си сам) Екипи на платформата Инфра-зависим Контрол + мащабируемост… също така, много копчета, някои от които са прокълнати ( Kubernetes HPA )
Управлявана ML платформа (облачна ML услуга) Отбори, които искат по-малко операции Плащане при ползване Вградени работни потоци за внедряване, куки за наблюдение - понякога скъпи за крайни точки, които са винаги включени ( внедряване на Vertex AI , извод в реално време на SageMaker )
Безсървърни функции (за леки изводи) Приложения, управлявани от събития Плащане за употреба Чудесно за пикови натоварвания - но студените стартирания и размерът на модела могат да ви съсипят деня 😬 ( студени стартирания на AWS Lambda )
NVIDIA Triton Inference Server Екипи, фокусирани върху производителността Безплатен софтуер, цена на инфраструктурата Отлично използване на графичния процесор, пакетиране, многомоделност - конфигурацията изисква търпение ( Triton: Динамично пакетиране )
TorchServe Екипи, силно базирани на PyTorch Безплатен софтуер Добри модели на обслужване по подразбиране - може да се наложи настройване за голям мащаб ( документация на TorchServe )
BentoML (опаковка + сервиране) Инженери по машинно обучение Безплатно ядро, екстрите варират Гладка опаковка, приятно изживяване за разработчици - все още се нуждаете от избор на инфраструктура ( BentoML опаковка за внедряване )
Рей Серв Хора, работещи с разпределени системи Инфра-зависим Мащабира се хоризонтално, подходящо за тръбопроводи - усеща се „голямо“ за малки проекти ( документация на Ray Serve )

Забележка за масата: „Безплатно“ е терминология от реалния живот. Защото никога не е безплатно. Винаги има сметка някъде, дори и да е за съня ви. 😴

7) Производителност и мащабиране - латентност, пропускателна способност и истината 🏁

Настройката на производителността е мястото, където внедряването се превръща в занаят. Целта не е „бързо“. Целта е постоянно достатъчно бързо .

Ключови показатели, които са важни

Често срещани лостове за издърпване

  • Пакетиране
    Комбинирайте заявки, за да увеличите максимално използването на графичния процесор. Чудесно за пропускателна способност, но може да навреди на латентността, ако прекалите. ( Triton: Динамично пакетиране )

  • Квантиране.
    По-ниската точност (като INT8) може да ускори извода и да намали паметта. Може леко да влоши точността. Понякога не, изненадващо. ( Квантиране след обучение )

  • Компилация / оптимизация
    ONNX експорт, оптимизатори на графи, потоци, подобни на TensorRT. Мощен, но дебъгването може да стане пикантно 🌶️ ( ONNX , ONNX Runtime модел оптимизации )

  • Кеширане.
    Ако входните данни се повтарят (или можете да кеширате вграждания), можете да спестите много.

  • Автоматично
    мащабиране. Мащабиране според използването на процесора/графичния процесор, дълбочината на опашката или честотата на заявките. Дълбочината на опашката е подценена. ( Kubernetes HPA )

Странен, но верен съвет: измервайте с размери на полезния товар, подобни на производствените. Малките тестови полезни товари ви лъжат. Те се усмихват учтиво и след това ви предават.

8) Мониторинг и наблюдаемост - не действайте на сляпо 👀📈

Мониторингът на модела не е просто наблюдение на времето за работа. Искате да знаете дали:

Какво да се наблюдава (минимално жизнеспособен набор)

Състояние на услугата

Поведение на модела

  • разпределения на входни характеристики (основни статистики)

  • норми за вграждане (за модели за вграждане)

  • разпределения на резултатите (увереност, състав на класовете, диапазони на резултатите)

  • откриване на аномалии на входовете (входни, изходни грешки)

Дрейф на данните и дрейф на концепциите

Записване на данни, но не подходът „записване на всичко завинаги“ 🪵

Дневник:

  • идентификатори на заявки

  • версия на модела

  • резултати от валидирането на схемата ( OpenAPI: Какво е OpenAPI? )

  • метаданни за минимално структуриран полезен поток (не сурова лична информация) ( NIST SP 800-122 )

Бъдете внимателни с поверителността. Не искате вашите регистрационни файлове да станат източник на изтичане на данни. ( NIST SP 800-122 )

9) CI/CD и стратегии за внедряване - третирайте моделите като истински издания 🧱🚦

Ако искате надеждни внедрявания, изградете конвейер. Дори и прост.

Плътен поток

  • Единични тестове за предварителна и последваща обработка

  • Интеграционен тест с известно „златно множество“ входно-изходни данни

  • Базов тест за натоварване (дори и олекотен)

  • Изграждане на артефакт (контейнер + модел) ( най-добри практики за изграждане на Docker )

  • Разгръщане в подготвителна фаза

  • Пускане на Canary към малък сегмент от трафика ( Canary Release )

  • Увеличавайте постепенно

  • Автоматично връщане назад при ключови прагове ( Синьо-зелено внедряване )

Модели на разгръщане, които ще ви спасят здравия разум

  • Canary : първо пускане за 1-5% трафик ( Canary Release )

  • Синьо-зелено : стартирайте новата версия заедно със старата, обърнете я, когато сте готови ( Синьо-зелено внедряване )

  • Shadow testing : изпращайте реален трафик към новия модел, но не използвайте резултатите (чудесно за оценка) ( Microsoft: Shadow testing )

И версионирайте крайните точки или маршрута си по версия на модела. Бъдещето ще ви благодари. Настоящето също ще ви благодари, но тихо.

10) Сигурност, поверителност и „моля, не изпускайте информация“ 🔐🙃

Охраната е склонна да се появява късно, като неканен гост. По-добре е да я поканите по-рано.

Практически контролен списък

  • Удостоверяване и оторизация (кой може да извика модела?)

  • Ограничаване на скоростта (защита от злоупотреба и случайни бури) ( API Gateway throttling )

  • Управление на тайни (няма ключове в кода, няма ключове и в конфигурационните файлове...) ( AWS Secrets Manager , Kubernetes Secrets )

  • Мрежови контроли (частни подмрежи, политики за комуникация между услуги)

  • Журнали за одит (особено за чувствителни прогнози)

  • Минимизиране на данните (съхранявайте само това, което е необходимо) ( NIST SP 800-122 )

Ако моделът засяга лични данни:

  • идентификатори за редактиране или хеширане

  • избягвайте регистрирането на сурови полезни товари ( NIST SP 800-122 )

  • дефиниране на правила за съхранение

  • поток от данни за документи (скучен, но защитен)

Също така, незабавното инжектиране и злоупотребата с изхода могат да имат значение за генеративните модели. Добавете: ( OWASP Топ 10 за LLM приложения , OWASP: Prompt Injection )

  • правила за дезинфекция на входни данни

  • филтриране на изхода, където е уместно

  • предпазни мерки за извикване на инструменти или действия в базата данни

Никоя система не е перфектна, но можете да я направите по-малко крехка.

11) Често срещани клопки (известни още като обичайните капани) 🪤

Ето класиките:

  • Предварителната
    обработка се различава между обучението и продукцията. Точността внезапно спада и никой не знае защо. ( Валидиране на данни от TensorFlow: откриване на отклонение при обучението )

  • Няма валидиране на схемата.
    Една промяна в горния код разваля всичко. Не винаги и шумно... ( JSON Schema , OpenAPI: Какво е OpenAPI? )

  • Пренебрегването на латентността на опашката
    p99 е мястото, където потребителите живеят, когато са ядосани. ( Опашката в мащаб )

  • Да забравите за разходите,
    когато крайните точки на графичния процесор работят бездействащо, е все едно да оставите всяка лампа в къщата си включена, но крушките са направени от пари.

  • Няма план за отмяна.
    „Просто ще се преразположим“ не е план. Това е надежда, облечена в тренчкот. ( Синьо-зелено разполагане )

  • Мониторинг само на времето за работа.
    Услугата може да работи, дори когато моделът е грешен. Това е може би по-лошо. ( Vertex AI: Monitor feature skew and drift , Amazon SageMaker Model Monitor )

Ако четете това и си мислите „да, правим две такива“, добре дошли в клуба. Клубът предлага закуски и лек стрес. 🍪

12) Заключение - Как да внедрите AI модели, без да губите ума си 😄✅

Внедряването е мястото, където изкуственият интелект се превръща в истински продукт. Не е бляскаво, но е мястото, където се печели доверие.

Бързо обобщение

И да, „Как да внедрим AI модели“ може да се усеща като жонглиране с горящи топки за боулинг в началото. Но след като вашият процес на внедряване е стабилен, става странно удовлетворяващо. Като най-накрая да организирате претрупано чекмедже… само че чекмеджето е производствен трафик. 🔥🎳

ЧЗВ

Какво означава внедряването на AI модел в производство

Разгръщането на AI модел обикновено включва много повече от предоставяне на API за прогнозиране. На практика то включва пакетиране на модела и неговите зависимости, избор на модел на обслужване (в реално време, пакетно, стрийминг или edge), мащабиране с надеждност, наблюдение на състоянието и дрейфа, както и настройване на безопасни пътища за внедряване и връщане назад. Надеждното внедряване остава предвидимо стабилно при натоварване и остава диагностицируемо, когато нещо се обърка.

Как да изберете между внедряване в реално време, пакетно, стрийминг или edge внедряване

Изберете модела на внедряване въз основа на това кога са необходими прогнози и с какви ограничения работите. API-тата в реално време са подходящи за интерактивни преживявания, където латентността е от значение. Пакетното оценяване работи най-добре, когато забавянията са приемливи и ефективността на разходите е водеща. Стриймингът е подходящ за непрекъсната обработка на събития, особено когато семантиката на доставката стане трудна. Разгръщането на периферни устройства е идеално за офлайн работа, поверителност или изисквания за ултраниска латентност, въпреки че актуализациите и хардуерните вариации стават по-трудни за управление.

Каква версия да се използва, за да се избегнат грешки при внедряване „работи на моя лаптоп“

Версията е нещо повече от просто теглата на модела. Обикновено ще ви е необходим артефакт на модела с версии (включително токенизатори или карти на етикети), логика за предварителна обработка и функции, код за извод и пълната среда за изпълнение (библиотеки на Python/CUDA/системни системи). Третирайте модела като артефакт за издание с маркирани версии и леки метаданни, описващи очакванията за схемата, бележките за оценка и известните ограничения.

Дали да се внедри с проста услуга в стил FastAPI или със специален сървър за модели

Един прост сървър за приложения (подход в стил FastAPI) работи добре за ранни продукти или ясни модели, защото запазвате контрол върху маршрутизирането, удостоверяването и интеграцията. Сървър за модели (в стил TorchServe или NVIDIA Triton) може да осигури по-силно пакетиране, паралелизъм и ефективност на графичния процесор веднага щом го инсталирате. Много екипи се озовават на хибрид: сървър за модели за извод плюс тънък API слой за удостоверяване, оформяне на заявки и ограничения на скоростта.

Как да подобрим латентността и пропускателната способност, без да нарушаваме точността

Започнете с измерване на латентността на p95/p99 на хардуер, подобен на производствен, с реалистични полезни товари, тъй като малките тестове могат да подведат. Често срещани лостове включват пакетиране (по-добра пропускателна способност, потенциално по-лоша латентност), квантуване (по-малко и по-бързо, понякога с умерени компромиси с точността), потоци на компилация и оптимизация (подобни на ONNX/TensorRT) и кеширане на повтарящи се входове или вграждания. Автоматичното мащабиране, базирано на дълбочината на опашката, също може да предотврати нарастването на латентността на опашката.

Какъв мониторинг е необходим отвъд „крайната точка е активна“

Времето за работа не е достатъчно, защото една услуга може да изглежда здрава, докато качеството на прогнозите се влошава. Като минимум, наблюдавайте обема на заявките, процента на грешки и разпределението на латентността, както и сигнали за насищане, като CPU/GPU/памет и време на опашката. За поведение на модела, проследявайте разпределенията на входните и изходните данни, заедно с основните сигнали за аномалии. Добавете проверки за отклонение, които задействат действие, а не шумни предупреждения, и регистрирайте идентификатори на заявки, версии на модели и резултати от валидиране на схемата.

Как да внедрим новите версии на моделите безопасно и да се възстановим бързо

Третирайте моделите като пълни издания, с CI/CD конвейер, който тества предварителната и последващата обработка, извършва проверки за интеграция спрямо „златен набор“ и установява базова линия на натоварване. За внедряванията, canary релийзите постепенно увеличават трафика, докато blue-green запазват по-стара версия активна за незабавно връщане към предишна версия. Shadow тестването помага за оценка на нов модел върху реален трафик, без да засяга потребителите. Връщането към предишна версия трябва да бъде механизъм от първа класа, а не последваща мисъл.

Най-често срещаните клопки при изучаването на внедряването на AI модели

Класическият случай е изкривяването между обучението и обслужването: предварителната обработка се различава между обучението и продукцията, а производителността тихо се влошава. Друг често срещан проблем е липсата на валидиране на схемата, при която промяна в началото на процеса нарушава входните данни по фини начини. Екипите също така подценяват латентността на опашката и прекалено се фокусират върху средните стойности, пренебрегват разходите (неактивните графични процесори се натрупват бързо) и пропускат планирането на връщане към предишните настройки. Мониторингът само на времето на работа е особено рискован, защото „работно време, но грешно“ може да е по-лошо от „неработно“.

Референции

  1. Amazon Web Services (AWS) - Amazon SageMaker: Извеждане в реално време - docs.aws.amazon.com

  2. Amazon Web Services (AWS) - Пакетна трансформация на Amazon SageMaker - docs.aws.amazon.com

  3. Amazon Web Services (AWS) - Монитор на модели на Amazon SageMaker - docs.aws.amazon.com

  4. Amazon Web Services (AWS) - Ограничаване на заявките към API Gateway - docs.aws.amazon.com

  5. Amazon Web Services (AWS) - AWS Secrets Manager: Въведение - docs.aws.amazon.com

  6. Amazon Web Services (AWS) - Жизнен цикъл на средата за изпълнение на AWS Lambda - docs.aws.amazon.com

  7. Google Cloud - Vertex AI: Разгръщане на модел към крайна точка - docs.cloud.google.com

  8. Google Cloud - Общ преглед на мониторинга на Vertex AI модела - docs.cloud.google.com

  9. Google Cloud - Vertex AI: Следене на изкривяването и отклонението на характеристиките - docs.cloud.google.com

  10. Блог на Google Cloud - Поток от данни: режими на стрийминг „точно веднъж“ срещу „поне веднъж“ - cloud.google.com

  11. Google Cloud - Режими на стрийминг на данни в облака - docs.cloud.google.com

  12. Книга на Google SRE - Мониторинг на разпределени системи - sre.google

  13. Google Research - Опашката в мащаб - research.google

  14. LiteRT (Google AI) - Общ преглед на LiteRT - ai.google.dev

  15. LiteRT (Google AI) - LiteRT извод на устройството - ai.google.dev

  16. Докер - Какво е контейнер? - docs.docker.com

  17. Docker - Най-добри практики за изграждане на Docker - docs.docker.com

  18. Kubernetes - Тайните на Kubernetes - kubernetes.io

  19. Kubernetes - Автоматично мащабиране на хоризонтални подове - kubernetes.io

  20. Мартин Фаулър - Canary Release - martinfowler.com

  21. Мартин Фаулър - Синьо-зелено внедряване - martinfowler.com

  22. Инициатива OpenAPI - Какво е OpenAPI? - openapis.org

  23. JSON схема - (цитиран сайт) - json-schema.org

  24. Буфери за протоколи - Общ преглед на буферите за протоколи - protobuf.dev

  25. FastAPI - (сайтът е цитиран) - fastapi.tiangolo.com

  26. NVIDIA - Triton: Динамично пакетиране и едновременно изпълнение на модели - docs.nvidia.com

  27. NVIDIA - Triton: Едновременно изпълнение на модели - docs.nvidia.com

  28. NVIDIA - Документация за Triton Inference Server - docs.nvidia.com

  29. PyTorch - Документация на TorchServe - docs.pytorch.org

  30. BentoML - Опаковка за внедряване - docs.bentoml.com

  31. Рей - Рей Сервира документи - docs.ray.io

  32. TensorFlow - Квантиране след обучение (Оптимизация на модела на TensorFlow) - tensorflow.org

  33. TensorFlow - Валидиране на данни от TensorFlow: откриване на отклонение при обучение - tensorflow.org

  34. ONNX - (цитиран сайт) - onnx.ai

  35. ONNX Runtime - Оптимизации на модела - onnxruntime.ai

  36. NIST (Национален институт за стандарти и технологии) - NIST SP 800-122 - csrc.nist.gov

  37. arXiv - Моделни карти за отчитане на модели - arxiv.org

  38. Microsoft - Тестване в сянка - microsoft.github.io

  39. OWASP - Топ 10 на OWASP за кандидатстване за магистърска степен по право (LLM) - owasp.org

  40. Проект за сигурност на OWASP GenAI - OWASP: Бързо инжектиране - genai.owasp.org

Намерете най-новия изкуствен интелект в официалния магазин за асистенти с изкуствен интелект

За нас

Обратно към блога