LLMOps на практике: с чего начать эксплуатацию LLM

В команде из 3 человек LLMOps стоит начать с версионирования релизов, проверки качества перед выпуском, доступных для разбора трассировок и работающего отката. Дополните этот цикл маршрутизацией, контролем расходов и защитными проверками. Наращивайте инфраструктуру, когда этого потребует конкретный сбой или трудности с координацией работы.

Эксплуатировать нужно функцию продукта, которой пользуется клиент. Ассистент поддержки может выдать связный ответ и при этом получить данные другого клиента, вызвать не тот инструмент или исчерпать лимит повторных попыток. Доступность API модели ещё не говорит о том, что функция работает правильно.

Возможности продуктов и рекомендации по зависимостям, приведённые ниже, сверены с актуальной официальной документацией 23 октября 2026 года. Размеры команд и разобранный пример оценки — сценарии для планирования, а не ограничения поставщиков или результаты измерений в продакшене.

Что такое LLMOps?

LLMOps позволяет наблюдать за изменениями в приложении на основе большой языковой модели, проверять их и восстанавливать работу после сбоев. Аббревиатура расшифровывается как large language model operations — эксплуатация больших языковых моделей. В эту область входят промпты, версии моделей, оценка качества, трассировки, расходы, защитные проверки, шлюзы и ответственность за устранение сбоев.

Представьте мост, по которому уже ездят машины. Важна не только его конструкция, но и проверки перед перестройкой, ограничения движения, мониторинг и возможность закрыть опасный участок. Более прочный мост не избавляет от этих обязанностей. Более мощная модель — тоже.

Для ассистента поддержки рабочий цикл выглядит так: изменить инструкции по возвратам, проверить новую версию на типичных диалогах, постепенно выпустить её для пользователей, изучить результаты и превратить обнаруженные сбои в регрессионные тесты. Такой тест проверяет, что после очередного изменения старая ошибка не вернулась.

В результате на жалобу клиента можно ответить предметно: какой релиз обработал запрос, что произошло по ходу выполнения и что можно безопасно изменить? Промпт-инжиниринг улучшает инструкцию. LLMOps позволяет поддерживать это улучшение после того, как оно дошло до пользователей.

LLMOps и MLOps: в чём разница?

LLMOps расширяет практики эксплуатации систем машинного обучения — MLOps — с учётом поведения приложений на основе LLM. И там, и там нужны версионирование, оценка качества, контроль развёртывания и мониторинг. Ни один из подходов сам по себе не гарантирует детерминированности и не отменяет обычную инженерную работу над ПО.

В рассматриваемой здесь функции продукта модель редко приходится обучать самостоятельно. Вы выбираете готовую модель и управляете промптами, контекстом, обновлениями модели, доступом к инструментам и окружающим кодом. MLOps, ориентированный на обучение, также охватывает обучающие данные, эксперименты, артефакты моделей и переобучение. Если вы дообучаете модель или размещаете у себя инфраструктуру инференса, эти обязанности добавляются к задачам LLMOps.

Начните с той ошибки, с которой столкнулись. Если не хватает знаний о компании, возможно, стоит улучшить поиск, который подаёт модели нужные документы. Если модель раз за разом ведёт себя неправильно, могут помочь изменения промпта, а со временем — дообучение. Ни в одном из этих случаев для ответственной эксплуатации функции не требуется сначала заново строить платформу обучения.

Версионируйте релиз целиком

Версия промпта полезна, только если можно установить, какие ещё входные данные повлияли на поведение системы. Ведите манифест релиза — краткий перечень конфигурации, которая выпускается вместе:

• Ревизия приложения, ревизия промпта и выбранный идентификатор поставщика и модели.
• Параметры генерации и идентификатор модели из ответа, если поставщик его возвращает.
• Настройки поиска и ревизия документов или индекса.
• Описания инструментов, схемы выходных данных и политика авторизации.
• Файл фиксации зависимостей и идентификатор развёрнутого образа.
• Набор данных для оценки, критерии оценивания и конфигурация модели-судьи, с помощью которых одобрили изменение.

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

Допустим, промпт ассистента по возвратам не менялся. Обновление документов всё равно может подставить в контекст новые правила, а изменение схемы инструмента — повлиять на допустимые параметры действия. Откат одного промпта оставит оба изменения на месте. Поэтому целевой релиз для отката должен задавать совместимую конфигурацию приложения, включая соответствующие версии поиска и политик.

Langfuse — платформа трассировки приложений и оценки качества. В её документации описаны централизованное хранение промптов, версионирование, метки развёртывания и связи между промптами и трассировками. Эти механизмы помогают связать ревизию промпта с результатами её работы. Но метка развёртывания остаётся изменяемым указателем: фиксируйте ревизию для каждого запроса и проводите смену указателя по установленным правилам выпуска. Управление промптами в Langfuse.

Если все изменения вносят инженеры, для начала храните промпты в существующем репозитории. Реестр промптов понадобится, когда сотрудникам без инженерной роли потребуется редактировать их под контролем или нескольким сервисам — использовать одну одобренную ревизию. Дополнительный компонент должен решать конкретную проблему совместной работы.

Сделайте оценку качества условием выпуска

Оценка становится инструментом управления, когда её результат может остановить релиз. Балл на дашборде, на который никто не обязан реагировать, остаётся просто измерением.

Соберите тестовые случаи из типичных запросов, известных сбоев и попыток злоупотребления, удалив или заменив чувствительные данные. Каждому случаю нужен ожидаемый результат или конкретный критерий. Например: определить применимое правило, сослаться на предоставленные доказательства, сформировать корректное предложение действия и отказаться от доступа к записи за пределами аккаунта вызывающего пользователя. Оставьте отдельный контрольный набор, под который авторы промптов не будут постоянно подстраивать свои решения.

Небольшой набор с понятными условиями допуска

Предположим, вы начинаете с 50 случаев: 30 типичных запросов, 10 пограничных ситуаций и 10 попыток злоупотребления. Это пример стартового упражнения, а не утверждение, что 50 примеров достаточно при вашем уровне риска.

Для обязательных полей, допустимых аргументов инструментов и границ прав доступа используйте детерминированные проверки — правила с однозначным результатом «пройдено» или «не пройдено». Такие качества, как соответствие ответа предоставленным сведениям, оценивайте с помощью людей и языковой модели-судьи. На время сравнения зафиксируйте критерии и конфигурацию модели-судьи и сопоставьте её решения с оценками людей на значимых примерах. Этот этап калибровки разобран в руководстве по LLM-as-a-judge.

Новая версия может улучшить результат с 46/50 до 49/50, то есть с 92% до 98%, и всё равно оказаться неприемлемой, если единственная оставшаяся ошибка раскрывает закрытую запись. Общий показатель качества не должен скрывать проблемы в критически важной категории запросов.

Для этого примера практические условия допуска к выпуску могут быть такими:

1. Ни одной критической ошибки в тестах прав доступа и действий.
2. Качество не ниже одобренного базового уровня в каждой важной категории запросов; неоднозначные и спорные случаи разобраны.
3. Задержки и потребление ресурсов укладываются в согласованные рабочие пределы функции.
4. Предыдущий совместимый релиз доступен, а за решение об откате отвечает конкретный человек.

Повторно прогоняйте важные или пограничные случаи, если вариативность ответов способна повлиять на решение. Успешное прохождение выбранных тестов даёт основания выпустить эту версию, но не доказывает, что в продакшене не будет сбоев.

LangSmith — платформа оценки качества и наблюдаемости. В её документации описаны офлайн-оценка на подготовленных наборах данных и онлайн-оценка реальных взаимодействий. Среди способов оценивания — код, проверка человеком, модели-судьи и попарное сравнение. Для эксплуатации это существенное различие: офлайн-проверки определяют, можно ли выпускать новую версию, а онлайн-проверки помогают находить сбои, которых не было в тестовом наборе. Документация по оценке в LangSmith.

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

Прослеживайте путь запроса и его результат

Трассировка должна объяснять, как запрос привёл к ответу. Спан — отдельная операция внутри трассировки, например поиск документов, вызов модели или выполнение инструмента.

Фиксируйте идентификатор релиза, разрешённые к сбору метаданные запроса, ссылки на найденные материалы, вызовы моделей, предложенные вызовы инструментов и их результаты, решения проверок, повторные попытки, время выполнения и расход токенов. Записывайте, какой маршрут выбрали и почему. Связывайте трассировку с результатом для продукта: устроил ли клиента ответ, понадобилось ли исправление или передача обращения человеку?

Например, при медленном ответе о возврате модель может занимать лишь малую часть времени, а основная задержка — приходиться на повторные обращения к недоступному сервису заказов. График задержек модели этого не объяснит. Трассировка с вызовом сервиса, повторными попытками и конечным результатом — объяснит.

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

Записывайте в логи только то содержимое, которое вам разрешено хранить. Удаляйте учётные данные до отправки телеметрии за пределы приложения, ограничивайте доступ к трассировкам и осознанно задавайте срок хранения. Отладочная запись может содержать те же сведения о клиенте, что и сам продукт. Если хранить полное содержимое неуместно, сохраняйте ссылки, структурированные решения и одобренные образцы с удалёнными чувствительными данными.

Настраивайте оповещения исходя из действий: кто отреагирует на рост числа неудачных действий, избыточных повторов, необычного расхода ресурсов или снижение доли принятых ответов? Сигнал без ответственного не поможет справиться с инцидентом. Для более подробного выбора инструментов используйте руководство по наблюдаемости для команд разного размера и сравнение LangSmith и Langfuse.

Управляйте маршрутизацией, повторами и расходами

Прежде чем оптимизировать выбор модели, ограничьте объём работы, который может запустить один запрос. Установите пределы длины ответа, времени выполнения, числа повторов, параллельных операций и шагов агента. Относите расход ресурсов к конкретной функции и арендатору — клиенту или организации, использующим общее приложение.

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

LiteLLM — шлюз и прокси для моделей. Его документация описывает единый интерфейс, аутентификацию, учёт расходов, бюджеты и балансировку нагрузки. Документация по маршрутизации охватывает повторы, резервные маршруты и тайм-ауты. Задавайте эти механизмы явными правилами: недоступность конечной точки может быть поводом переключиться на резервный маршрут, но только если вы одобрили его поведение и требования к обработке данных. Документация шлюза и документация маршрутизации.

Проверяйте ограничения на параллельных запросах и тех конечных точках API, которыми пользуетесь. Различайте оповещение и блокировку; учитывайте, как на итоговый расход влияют уже выполняющиеся запросы, повторы и вызовы по резервным маршрутам. Сохраняйте лимит на уровне отдельного запроса в приложении, даже если шлюз учитывает расходы.

Начните маршрутизацию с узкого правила: направляйте чётко определённую категорию запросов с низким риском на меньшую модель только после того, как она пройдёт соответствующие проверки. Неоднозначные задачи оставляйте на одобренном маршруте к более мощной модели. Как проверить такую политику выбора, разобрано в руководстве по маршрутизаторам моделей.

Добавляйте семантическое кэширование — повторное использование по смыслу, а не по полному совпадению текста — только там, где на равнозначные вопросы безопасно выдавать один ответ. Публичное пояснение из справочного центра подходит для первого опыта лучше, чем баланс счёта. Ограничивайте повторное использование правами доступа, нужными версиями и актуальностью; сбрасывайте кэш, когда эти условия меняются. Не выполняйте повторно действие, например возврат денег, на основании кэшированного ответа. До внедрения разберите границы применения семантического кэширования.

Проверяйте полномочия перед выполнением действий

Решать, что разрешено вызывающему пользователю, должно приложение, даже если модель уверенно предлагает действие. Защитные механизмы, или guardrails, — это проверки и ограничения для входных данных, ответов и действий. Классификатор контента решает лишь часть этой задачи.

В ассистенте по возвратам до выполнения операции проверяйте её и предложенные аргументы на соответствие полномочиям аутентифицированного клиента. Выдавайте инструменту только необходимые права. Там, где этого требуют последствия, предусматривайте отдельное согласование конкретного действия, а выходные данные проверяйте ещё раз перед передачей в другую систему. Не считайте найденные документы и ответы модели доверенными. Эти принципы следуют рекомендациям OWASP по предотвращению промпт-инъекций.

Определите и поведение при сбоях. Если обязательная проверка полномочий недоступна, действие не должно выполняться. Задержка необязательной оценки качества не обязана блокировать безобидный черновик. Зафиксируйте, какие проверки должны останавливать выполнение, а при сбое каких допустима передача задачи человеку.

Проверяйте и атаки, и правомерные запросы, чтобы слишком широкий фильтр незаметно не лишил продукт работоспособности. В руководстве по защитным механизмам ИИ эти проверки привязаны к точкам контроля, которые небольшая команда может реализовать в первую очередь.

Включите работу с инцидентами в жизненный цикл

Прежде чем выбирать способ восстановления, определите тип инцидента: ухудшение поведения, отказ сервиса или компрометация системы. Реакция в каждом случае будет разной.

Если поведение ухудшилось, остановите развёртывание, сохраните показательные трассировки, вернитесь к последнему совместимому релизу и добавьте сбой в набор проверок. При недоступности поставщика используйте проверенный резервный маршрут или понятный ответ о временном сбое. При подозрении на компрометацию изолируйте затронутую среду выполнения и подключите ответственного за безопасность: изменение промпта не восстановит доверие к скомпрометированному хосту.

Инцидент с LiteLLM

21 октября 2026 года LiteLLM сообщил, что релиз 1.107.0 содержал вредоносное ПО для кражи учётных данных и средства удалённого выполнения кода. Среди затронутых тегов контейнеров были v1.107.0, latest, main-latest и main-stable; закрытый корпоративный реестр не пострадал. В официальном теге исходного кода вредоносных файлов не было: распространяемые артефакты поступили из репозитория под контролем злоумышленника. Отчёт LiteLLM об инциденте.

Отчёт предупреждает затронутых пользователей: не стоит начинать с pip install, поскольку хуки запуска Python могут снова выполнить вредоносный код. Предпочтительный путь — пересоздать среды и заменить учётные данные, до которых мог добраться скомпрометированный хост. На момент проверки для этой статьи расследование всё ещё было отмечено как продолжающееся; если затронута ваша установка, используйте актуальные сведения из отчёта о масштабе воздействия и устранении последствий.

Вывод для эксплуатации шире, чем история одного шлюза: фиксируйте и одобряйте именно тот артефакт, который развёртываете, а не только проверенную ревизию исходного кода.

Фиксируйте зависимости, но продолжайте их обновлять

Закрепляйте одобренные версии зависимостей и сохраняйте их хеши; образы контейнеров закрепляйте по дайджесту — идентификатору содержимого образа. Установка с проверкой хешей требует зафиксированных зависимостей с указанными хешами, а ссылки по дайджесту не позволяют незаметно перейти на новое содержимое изменяемого тега контейнера. Рекомендации по установке пакетов Python и закреплению контейнеров.

Эти меры подтверждают идентичность артефакта, а не его безвредность. Если закрепить вредоносный артефакт, он таким и останется. Проверяйте происхождение и сообщения об угрозах, тестируйте обновления изолированно и продвигайте через этапы развёртывания один и тот же одобренный артефакт. Назначьте ответственного за обновление закреплённых версий, чтобы воспроизводимость не обернулась бесконечным откладыванием работ по безопасности.

Инструкция по реагированию должна быть достаточно короткой, чтобы ею можно было воспользоваться под давлением: ответственный, способ аварийной остановки, перечень затронутых артефактов, последний одобренный релиз, область действия учётных данных, канал связи и условия восстановления сервиса. Отрепетируйте этот порядок на безвредных сбоях.

Инструменты LLMOps: минимум для команды из 3 человек

Используйте привычный процесс развёртывания и одну систему для просмотра трассировок и результатов оценки. Отдельный продукт для каждого этапа жизненного цикла сначала добавляет работу по интеграции и лишь потом — возможности контроля.

Это обязанности, а не пять новых сотрудников. Их можно совмещать, но ответственность всё равно нужно закрепить явно.

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

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

Добавляйте LiteLLM, когда общие правила и единый доступ к поставщикам моделей оправдывают эксплуатацию шлюза. Одно приложение с одним поставщиком может начать с проверок в собственном бэкенде. Когда нескольким сервисам понадобятся единообразные учётные данные, бюджеты или одобренные маршруты, польза централизации этих правил станет убедительнее. Учитывайте в эксплуатационной нагрузке базу данных шлюза, его учётные данные и обновления.

Что меняется в команде из 30 человек?

В команде из 30 человек главной задачей становится согласование изменений между ответственными. Дополнительные дашборды не определят, кто вправе перевести промпт в рабочую среду, одобрить резервный маршрут или просмотреть трассировку запроса клиента.

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

Унифицируйте метаданные релизов и поля трассировок, чтобы ход инцидента можно было проследить через несколько сервисов. Разделяйте среды и области доступа клиентов. Добавьте очереди на разбор спорных оценок. Запланируйте проверки уведомлений о выводе моделей из эксплуатации, предупреждений о зависимостях и дрейфа данных — изменений в запросах, поступающих в продукт.

Когда нужна общая платформа LLMOps?

Внедряйте общую платформу, когда повторяющиеся проблемы координации обходятся дороже её эксплуатации: несовместимые релизы промптов, дублирующаяся инфраструктура оценки, несогласованные политики доступа или инциденты, которые проходят через границы сервисов и остаются без ответственного.

Размер команды — сценарий для планирования, а не технический порог. Маленькой команде, чья система выполняет действия с серьёзными последствиями, строгие меры контроля могут понадобиться сразу. Большой команде с одной внутренней функцией и чётко ограниченными возможностями по-прежнему может хватать скромного набора инструментов. Масштабируйте контроль соразмерно возможному ущербу и сложности распределения ответственности.

Какие ожидания от LLMOps завышены?

Обучение модели не является входным билетом. Если вы используете модель поставщика, у вас уже есть система, которую нужно оценивать и эксплуатировать. Сначала выстройте цикл выпуска, а затем решайте, устранит ли дообучение выявленную ошибку.

Высокая оценка модели-судьи — не универсальный сертификат качества. Она отражает заданные вами критерии на выбранных вами примерах. Сохраняйте проверку человеком и детерминированные тесты там, где ошибочное решение имеет конкретные последствия.

Автоматическая маршрутизация не делает все резервные варианты взаимозаменяемыми. Маршрут может изменить поведение модели, использование инструментов и то, куда отправляются данные. Одобряйте такие изменения осознанно.

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

Что выбрать: книгу или курс по LLMOps?

Выбирайте учебные материалы под рабочую задачу, которую пока не умеете решать. Книга помогает разобраться в архитектуре; курс полезен, если в упражнениях нужно создавать набор данных, исследовать трассировки, проверять релиз перед выпуском и восстанавливаться после сбоя. Программа, посвящённая только обучению моделей, оставит существенные пробелы для работы с функцией, построенной на API.

С чего начать в понедельник

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

1. 1

   Выберите одну функцию и определите, что считать сбоем

   Выберите самый важный сценарий работы в продакшене. Запишите допустимые результаты, запрещённые действия, ответственного и условия, при которых релиз следует остановить.

2. 2

   Зафиксируйте состав текущего релиза

   Зафиксируйте его промпт, модель, контекст, инструменты, политику и идентификаторы зависимостей. Свяжите эту запись с трассировкой запроса, из которой удалены чувствительные данные.

3. 3

   Превратите известные сбои в обязательные проверки

   Соберите репрезентативные тестовые случаи, прогоните текущий релиз для определения базового уровня и требуйте проверки перед принятием ухудшения в критически важной категории.

4. 4

   Отрепетируйте восстановление

   Покажите работу отката и аварийной остановки в безопасной среде. Прежде чем добавлять ещё одну платформу, назначьте ответственных за следующий разбор сбоя и проверку обновлений зависимостей.

Вопросы о LLMOps

Чем LLM отличается от LLMOps?

LLM — модель, которая генерирует ответ. LLMOps — практики эксплуатации приложения, использующего эту модель: управление изменениями, проверка поведения, наблюдение за запросами и восстановление после сбоев.

Как расшифровывается LLMOps?

LLMOps означает large language model operations — эксплуатацию больших языковых моделей. Для команды приложения это также работа с промптами, контекстом, инструментами и процессом выпуска — всем, что окружает модель.

В чём основные различия между LLMOps и AgentOps?

AgentOps уделяет дополнительное внимание многошаговому выполнению: действиям инструментов, сохраняемому состоянию, правам доступа, лимитам шагов и завершению задач. Агент — система, которая использует модель для выбора действий; эти действия должны подчиняться тем же правилам выпуска и реагирования на инциденты.

Какой курс по LLMOps лучше выбрать?

Для задач, описанных в статье, выбирайте курс, в котором итоговый оцениваемый проект включает оценку качества, трассировку, развёртывание и восстановление. Курс только об обучении модели не охватывает обязанности по эксплуатации уже работающей функции продукта.

Можно ли получить сертификат по MLOps бесплатно?

Доступность и условия экзамена зависят от организации, которая выдаёт сертификат; перед записью проверьте её актуальную страницу сертификации. Для внедрения описанных здесь механизмов контроля релизов сертификат не требуется.

Можно ли освоить машинное обучение за 3 месяца?

Используйте этот срок для учебного проекта с ограниченным объёмом, а не как обещание стать специалистом по продакшену. Для уже существующей функции на основе LLM полезным проектом будет версионируемое приложение с оценкой качества, трассировками и продемонстрированным восстановлением после сбоя.

Высоко ли оплачивается работа в машинном обучении?

Оплата зависит от роли, местоположения и опыта; само название должности LLMOps ничего не говорит о зарплате. При найме проверяйте, способен ли кандидат объяснить провал оценки и безопасно эксплуатировать релиз, подготовленный по итогам разбора.

Не поздно ли учить Python в 30 лет?

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

Сложно ли изучать ИИ и машинное обучение?

Зависит от объёма задачи. Эксплуатация функции, вызывающей готовую модель, и исследование новой модели — разные учебные проекты. Начните с разработки ПО и оценки качества, которые уже нужны вашей функции.

Практические руководства по разработке и эксплуатации функций на основе ИИ — в нашей рассылке.