Топ-5 инструментов и полное руководство по стеку для локальной LLM: от Ollama до RAG-архитектуры

В контексте локального развертывания LLM, метафорическое понятие «тряпка» (или «полотно») скорее всего относится к комплексному, связующему стеку (The Glue Stack), который позволяет собрать из разрозненных компонентов (модель, векторная база, логика приложения) единое, работающее целое. Это не один конкретный инструмент, а скорее архитектурный подход.

Саммари статьи

ChatGPT

Google AI

Grok

Perplexity

Что это за «стек»? Это набор программных компонентов, которые решают проблему интеграции и управления контекстом. Если Ollama — это двигатель (сама модель), а векторная БД — это память, то «тряпка» — это каркас, который заставляет их работать вместе, обеспечивая правильный поток данных (запрос $\rightarrow$ поиск $\rightarrow$ контекст $\rightarrow$ генерация $\rightarrow$ ответ).

Ключевые компоненты, которые формируют этот «стек»:

1. Локальный LLM-раннер: Инструмент для запуска самой модели (например, Ollama). Он предоставляет API-интерфейс.

2. Векторная база данных: Хранилище знаний, из которого извлекается релевантный контекст (например, ChromaDB, FAISS). Это основа RAG.

3. Оркестратор/Фреймворк: Библиотека, которая управляет последовательностью шагов: парсинг запроса, запрос к БД, формирование промпта и вызов API LLM (например, LangChain или LlamaIndex).

Как начать работу? Начинать нужно с самого простого: запустить первую модель. Установите Ollama и скачайте небольшую, но функциональную модель (например, llama2). Это даст вам первый, минимальный, работающий API-вызов. После этого вы постепенно добавляете компоненты: подключаете векторную БД, а затем — логику извлечения контекста. Этот итеративный подход — ключ к освоению локального стека.

Раздел 1: Архитектура и Инструменты — Выбор основы для локальной LLM

На предыдущем этапе мы определили, что под «стеком для локальной LLM» подразумевается не единый инструмент, а связка из нескольких компонентов: движка для запуска моделей, базы знаний и логики извлечения контекста. Теперь, когда концептуальная основа ясна, необходимо глубоко погрузиться в архитектуру. Этот раздел посвящен выбору фундаментальных строительных блоков. Мы разберем, что именно означает запуск LLM локально и почему концепция RAG стала стандартом де-факто для придания моделям актуальных знаний.

Далее мы проведем сравнительный анализ ключевых инструментов, которые формируют этот стек. Сравнение таких решений, как Ollama, LM Studio и прямые API-обертки, поможет вам понять, какой подход лучше всего соответствует вашим задачам — от простого тестирования до промышленной интеграции.

1.1. Понимание концепции: Зачем локальная LLM и что такое RAG?

В контексте разработки и работы с большими языковыми моделями (LLM) термин «тряпка для локальной LLM» — это, скорее всего, метафора, обозначающая некий комплексный, готовый к использованию, «оберточный» (wrapper) стек или унифицированный рабочий процесс. Это не конкретный инструмент, а скорее решение проблемы: как взять сырую, сложную модель и сделать ее легко интегрируемой, надежной и функциональной для реального приложения.

Зачем вообще локальная LLM?

Основная причина — это контроль, приватность и стоимость. Когда вы используете облачные API (OpenAI, Anthropic), вы полагаетесь на сторонний сервис, передаете туда чувствительные данные и платите за каждый токен. Локальный стек позволяет:

• Гарантировать приватность: Данные никогда не покидают вашу машину. Критично для корпоративных систем и работы с персональными данными.

• Контролировать расходы: После первоначальной настройки затраты сводятся к электроэнергии, а не к оплате API-вызовов.

• Работать офлайн: Полная автономность — идеальный сценарий для полевых вычислений или систем с нестабильным интернетом.

Что такое RAG и почему это критично?

Сами по себе LLM — это блестящие, но «галлюцинирующие» генераторы текста, обученные на огромном, но устаревшем массиве данных. Они не знают о ваших последних документах, внутренней документации компании или специфических данных, которые вы только что загрузили. Здесь на сцену выходит Retrieval Augmented Generation (RAG).

RAG — это архитектурный паттерн, который заставляет LLM не просто «угадывать» ответ, а сначала найти релевантную информацию в вашей базе знаний (документах, базах данных) и затем использовать эту информацию как контекст для генерации ответа. Это превращает LLM из «умного болтуна» в «эксперта, цитирующего источники».

Таким образом, «стек» — это не просто запуск модели (Ollama), а полный цикл: Загрузка данных $ ightarrow$ Векторизация $ ightarrow$ Поиск (Retrieval) $ ightarrow$ Генерация (LLM). И именно этот полный цикл и является тем, что нужно «упаковать» в удобный рабочий процесс.

1.2. Сравнение

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

Основное различие между инструментами заключается в их фокусе: Ollama — это, прежде всего, сервер и универсальный API-слой для запуска моделей. Он решает проблему запуска и доступа к модели. LM Studio — это, скорее, GUI-оболочка для новичков, которая упрощает скачивание и тестирование моделей без написания кода. Они решают проблему удобства.

Для разработчика, который строит полноценное приложение, критически важна абстракция. Здесь в игру вступают Python-фреймворки (LangChain, LlamaIndex). Они выступают в роли оркестратора, который знает, как последовательно вызвать Ollama, как обработать документы и как сформировать финальный промпт. Они решают проблему логики.

Сравнение по ключевым параметрам:

• Ollama: Идеален для бэкенда. Предоставляет стабильный, легко интегрируемый локальный API. Фокус на производительности и простоте вызова.

• LM Studio: Идеален для прототипирования и тестирования. Отлично подходит для быстрого сравнения моделей без написания кода.

• Python-фреймворки (LangChain/LlamaIndex): Не являются заменой, а надстройкой. Они берут API от Ollama и добавляют сложную бизнес-логику (например, поиск по базе векторов, цепочки вызовов).

Таким образом, «идеальный стек» — это комбинация: Ollama (движок) $\rightarrow$ Vector Store (память) $\rightarrow$ Python-фреймворк (логика).

Инструменты для локального запуска LLM (Ollama vs LM Studio vs API Wrappers)

Выбор правильного инструмента для локального запуска LLM — это критический этап, определяющий скорость разработки и стабильность продакшн-стека. Важно понимать, что нет универсального «волшебного» инструмента; скорее, это комбинация специализированных решений, каждое из которых решает свою задачу. Если под «тряпкой» вы подразумеваете единую, простую в использовании оболочку, которая сделает всё — от загрузки модели до вызова API, то вам нужно рассмотреть три основных категории инструментов.

Ollama: Это, безусловно, де-факто стандарт для разработчиков. Ollama предоставляет минималистичный, но мощный API-сервер. Его главное преимущество — простота развертывания и стандартизированный интерфейс, который позволяет легко интегрировать локально запущенную модель в любой Python-код или сервис. Он фокусируется на работе с моделью, а не на её визуальном тестировании.

LM Studio: Этот инструмент ориентирован на конечного пользователя (end-user) и исследователя. Он предоставляет богатый графический интерфейс (GUI) для скачивания, тестирования и сравнения моделей без написания кода. Он идеален для быстрой отладки и понимания возможностей модели, но для интеграции в автоматизированный пайплайн его API-слой часто менее гибок, чем у Ollama.

API Wrappers (LangChain, LlamaIndex и т.п.): Эти фреймворки не являются инструментами для запуска модели, а скорее оркестраторами логики. Они служат «клеем», который связывает ваш код с API, будь то OpenAI, или, в нашем случае, с локальным API, предоставленным Ollama. Они абстрагируют сложность вызовов, позволяя вам сосредоточиться на логике RAG (встраивание, извлечение, генерация).

Сравнительная таблица для выбора:

Для построения надежного, масштабируемого RAG-приложения, Ollama должен выступать в роли бэкенда, а LangChain/LlamaIndex — в роли архитектора, управляющего потоком данных.

Раздел 2: Практическая Реализация — Пошаговый запуск и связывание компонентов

На предыдущем этапе мы определили ключевые компоненты стека: Ollama как движок, и понимание роли RAG. Теперь пришло время перейти от теории к практике. Этот раздел — ваш пошаговый путеводитель по превращению набора отдельных инструментов в работающее, связное приложение. Мы не просто устанавливаем компоненты; мы учимся их оркестрировать.

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

2.1. Установка и настройка: Идеальный рабочий процесс с Ollama (CLI и API)

Перейдем от теории к практике. Если в предыдущем разделе мы определили, что Ollama — это наш основной двигатель для локальной генерации, то здесь мы научимся заставить его работать в связке с кодом. Идеальный рабочий процесс строится на использовании командной строки (CLI) для управления моделями и их последующей интеграции через API.

1. Установка и базовый запуск через CLI

Установка Ollama — это первый и самый простой шаг. После установки вы можете начать скачивать и запускать модели одной командой. Например, для запуска популярной модели Llama 3:

ollama run llama3

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

2. Использование Ollama как локального API-сервера

Ключевой момент для разработчика — это понимание, что Ollama автоматически поднимает локальный HTTP-сервер (обычно на http://localhost:11434). Это и есть наш «мост» к приложению. Вместо того чтобы писать сложный код для взаимодействия с моделью, мы просто отправляем HTTP-запросы, имитируя вызов облачного API, но используя локальные ресурсы.

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

Рабочий процесс:

1. Установка: Устанавливаем Ollama.

2. Загрузка: Скачиваем нужную модель (ollama pull model:tag).

3. Интеграция: Используем Python-библиотеки (например, requests или специализированные обертки) для отправки запросов к http://localhost:11434/api/generate.

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

2.2. Управление знаниями: Построение RAG-пайплайна для локальной базы данных

После того как мы настроили Ollama как надежный локальный API-сервер, следующим критически важным шагом является придание этой мощности реальной пользы — подключение к внешним знаниям. Именно здесь в игру вступает Retrieval-Augmented Generation (RAG). Если LLM — это мозг, то RAG — это библиотека, к которой этот мозг имеет мгновенный доступ. В контексте локальной генерации LLM, RAG позволяет нам обойти главную проблему: «галлюцинации» и ограниченность знаний модели на момент обучения.

Построение локального RAG-пайплайна состоит из трех ключевых этапов, которые должны работать в связке с вашим локальным LLM (запущенным через Ollama):

1. Загрузка и Разделение (Loading & Chunking): Ваши корпоративные документы (PDF, DOCX, Markdown) необходимо загрузить и разделить на небольшие, семантически связанные «куски» (chunks). Размер и стратегия чанкинга критически важны; слишком большие куски размывают контекст, слишком маленькие теряют смысл.

2. Векторизация (Embedding): Каждый текстовый кусок должен быть преобразован в числовой вектор (эмбеддинг). Для локального стека рекомендуется использовать локальные модели эмбеддингов (например, all-MiniLM-L6-v2 или специализированные модели от Hugging Face), которые можно запустить через Ollama или специализированные библиотеки.

3. Хранение и Поиск (Vector Store & Retrieval): Эти векторы сохраняются в векторную базу данных (например, ChromaDB, FAISS или Qdrant, запущенные локально). Когда пользователь задает вопрос, его вопрос также векторизуется, и база данных находит семантически наиболее близкие куски текста из вашей базы знаний. Эти извлеченные куски затем передаются в LLM вместе с промптом, формируя контекст для ответа.

Таким образом, ваш рабочий процесс выглядит так: Документы $\rightarrow$ Чанкинг $\rightarrow$ Эмбеддинги $\rightarrow$ Векторная БД $\rightarrow$ Поиск $\rightarrow$ Контекст $\rightarrow$ Ollama LLM $\rightarrow$ Ответ. Использование готовых фреймворков, таких как LlamaIndex или LangChain, значительно упрощает оркестровку этих компонентов, выступая в роли «клея» между всеми локальными частями стека.

2.3. Интеграция в приложение: От Python-скрипта до продакшн-готовности (API Calls)

После того как мы успешно настроили весь конвейер RAG — от загрузки документов до получения релевантного контекста из векторной БД — перед нами стоит задача: как это всё заставить работать в реальном приложении? На этом этапе мы переходим от лабораторного стенда к рабочему инструменту. Использование чистого CLI для вызовов становится неэффективным, поэтому ключевым шагом является обертывание всей логики в структурированный API-интерфейс.

Интеграция в приложение — это процесс создания «клея» (glue code), который связывает три ключевых элемента: Пользовательский ввод $\rightarrow$ Логика извлечения (RAG) $\rightarrow$ Локальный LLM (Ollama).

От Скрипта к Сервису: Управление Вызовами

На уровне Python-скрипта мы, вероятно, используем библиотеки вроде langchain или llama-index, которые абстрагируют низкоуровневые вызовы. Однако для продакшн-готовности необходимо понимать, что происходит «под капотом». Вместо прямого вызова ollama run model, мы должны взаимодействовать с HTTP API, который Ollama предоставляет по умолчанию (обычно http://localhost:11434/api/generate).

Ключевые аспекты API-интеграции:

1. Формирование Промпта (Prompt Construction): Это не просто передача вопроса. Мы должны динамически конструировать финальный промпт, который включает системную инструкцию, извлеченный контекст (из векторной БД) и сам вопрос пользователя. Это критически важно для сохранения контекста и тональности.

2. Обработка Ответа (Streaming vs. Batch): В реальном приложении пользователь ожидает не только финальный ответ, но и ощущение скорости. Поэтому крайне важно реализовать стриминг ответа, используя потоковые вызовы API, а не ждать полной генерации.

3. Обработка Ошибок и Таймаутов: Промышленный код должен уметь обрабатывать сбои сети, перегрузку локального GPU или превышение лимитов токенов. Реализация повторных попыток (retries) с экспоненциальной задержкой — стандартная практика.

Архитектурный Выбор: API-Слой

Для максимальной переносимости и возможности масштабирования, лучшей практикой является создание промежуточного API-слоя (например, на FastAPI). Этот слой принимает запрос от фронтенда (или другого микросервиса), выполняет всю сложную логику RAG (поиск, сборка промпта) и затем вызывает Ollama через его API. Это изолирует основное приложение от деталей работы с локальной LLM, позволяя вам менять бэкенд (например, с Ollama на vLLM) без переписывания всего фронтенда.

Раздел 3: Оптимизация и Масштабирование — Превращение MVP в промышленный продукт

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

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

3.1. Мастерство промпта: Как повысить точность на 80% с Prompt Engineering

Повышение точности — это не только вопрос выбора модели или базы данных; это прежде всего искусство управления контекстом и инструкциями, которое реализуется через Prompt Engineering. Если на предыдущих этапах мы научились запускать LLM и подключать RAG, то здесь мы учимся говорить с ней, чтобы она выдавала максимально релевантный и точный ответ. Повышение точности на 80% — это не магия, а систематический подход к структурированию запроса.

Анатомия идеального промпта для RAG

В контексте RAG-системы промпт должен выполнять роль не просто вопроса, а роли, контекстного фильтра и формата вывода. Идеальный промпт состоит из трех обязательных компонентов:

1. Системная роль (System Prompt): Это фундамент. Здесь вы задаете личность и правила игры для LLM. Вместо простого «Ответь на вопрос» используйте: «Ты — высококвалифицированный технический консультант, специализирующийся на архитектуре микросервисов. Твоя задача — отвечать строго на основе предоставленного контекста. Если информация отсутствует, ты обязан ответить фразой: «Согласно предоставленным документам, ответ не найден». Не додумывай!»

2. Контекст (Context): Это извлеченные куски знаний из вашей векторной БД. Он должен быть четко отделен от вопроса. Используйте разделители, например, --- КОНТЕКСТ ---.

3. Пользовательский запрос (User Query): Сам вопрос пользователя. Он должен быть максимально ясным, но его интерпретация должна быть ограничена правилами, заданными в Системной роли.

Продвинутые техники повышения точности

• Few-Shot Learning: Вместо того чтобы просто задать вопрос, предоставьте модели 2-3 примера идеального диалога (Вопрос $ ightarrow$ Контекст $ ightarrow$ Идеальный Ответ). Это «обучает» модель желаемому стилю и структуре ответа без переобучения.

• Chain-of-Thought (CoT): Это критически важно для сложных рассуждений. Вместо того чтобы просить «Ответ», просите модель «Сначала рассуждай по шагам, а затем давай финальный ответ». Это заставляет LLM выполнять внутреннюю проверку логики, значительно снижая галлюцинации.

• Self-Correction/Reflection: Внедрите в пайплайн этап, где LLM сама проверяет свой ответ на соответствие исходному контексту. Вы можете попросить ее: «Проверь свой ответ на предмет противоречий с предоставленным контекстом и исправь, если найдешь расхождение». Это имитирует цикл рецензирования.

Использование этих методов превращает LLM из простого «генератора текста» в контролируемый, логически выверенный поисковый движок, что и дает тот самый скачок в надежности, о котором говорят эксперты.

3.2. Аппаратный и программный чек-лист: Выбор модели под железо и задачу

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

Аппаратный чек-лист: Железо под LLM

Производительность локальной LLM критически зависит от трех компонентов: оперативной памяти (RAM), видеопамяти (VRAM) и процессора (CPU). Понимание их роли поможет избежать «бутылочных горлышек».

• VRAM (Видеопамять): Это самый важный ресурс. Большинство современных моделей (особенно 7B и 13B) загружаются в VRAM. Чем больше VRAM, тем больше и сложнее модель, которую вы можете запустить, без замедления.

• RAM (Оперативная память): Используется, когда модель не помещается полностью в VRAM (например, при квантовании до формата GGML/GGUF). Если вам нужно запустить модель, превышающую VRAM, система будет использовать RAM, что значительно снизит скорость инференса.

• CPU: Важен для предварительной обработки данных, работы векторной базы и, в случае отсутствия достаточной VRAM, для самого процесса инференса. Современные многоядерные процессоры с поддержкой AVX2 или AVX512 значительно ускорят работу.

Практический совет: Всегда начинайте с проверки требований к квантованию. Модели в формате GGUF (используемые Ollama) — это золотой стандарт для локального развертывания, так как они оптимизированы для эффективного использования как CPU, так и GPU.

Программный чек-лист: Выбор модели и фреймворка

Выбор модели — это не просто выбор «самой умной». Это выбор модели, которая оптимально соответствует вашей задаче и вашему железу. Неправильный выбор приведет к непредсказуемой задержке (latency).

Ключевые программные паттерны:

1. Оркестрация (The Glue): Не пытайтесь писать весь пайплайн с нуля. Используйте фреймворки типа LangChain или LlamaIndex. Они абстрагируют сложность вызова LLM, управления памятью и интеграции с векторными хранилищами.

2. Управление контекстом: В промышленном коде никогда не передавайте весь контекст в промпт. Используйте Retrieval-Augmented Generation (RAG), где контекст извлекается до вызова LLM, а затем подается в виде структурированного блока <context>...</context>.

3. Агенты и Планирование: Для сложных задач (например, «Проанализируй отчет и напиши резюме для руководства») используйте паттерн Агента. Агент — это не просто вызов LLM, это система, которая позволяет LLM самостоятельно решать, какой инструмент вызвать (поиск в БД, вызов API, выполнение кода) и в какой последовательности.

Постоянный мониторинг задержки (latency) и потребления памяти во время нагрузочного тестирования — это ваш главный инструмент оптимизации, который заменит «магию» и даст вам измеримые метрики производительности.

3.3. Продвинутые паттерны: Агенты, планирование задач и мониторинг локальной системы

Переход от работающего MVP к промышленному продукту требует не просто связывания компонентов, а внедрения сложных, многоступенчатых паттернов, которые имитируют когнитивные процессы человека. Здесь на сцену выходят Агенты (Agents), которые являются вершиной оркестрации локальных LLM. Если предыдущие шаги научили нас запрашивать информацию (RAG), то агенты учат систему действовать.

Агенты: От простого запроса к автономному действию

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

Заключение: Когда локальный стек LLM заменит облачные сервисы

Переход от локального MVP к замене облачных гигантов — это не вопрос «когда», а вопрос достаточной зрелости вашего проекта и критических требований к данным. Локальный стек LLM, построенный на базе Ollama и RAG, не просто «альтернатива»; это стратегическое преимущество, которое решает фундаментальные проблемы, присущие облачным API.

Когда локальный стек становится незаменимым?

Облачные сервисы (OpenAI, Anthropic и др.) предлагают непревзойденную мощность и простоту доступа. Однако они не могут гарантировать три вещи, которые критически важны для многих корпоративных и исследовательских задач:

1. Контроль данных (Data Sovereignty): Если ваши данные содержат коммерческую тайну, персональные данные (PII) или информацию, регулируемую строгим законодательством (например, GDPR), отправка их через сторонний API — это неприемлемый риск. Локальная генерация LLM гарантирует, что данные никогда не покидают вашу инфраструктуру.

2. Прогнозируемая стоимость и задержка (Cost & Latency): При высоком объеме запросов (миллионы токенов) облачные расходы становятся непредсказуемой статьей бюджета. Кроме того, зависимость от внешнего интернета и сетевой инфраструктуры вносит элемент непредсказуемой задержки. Локальный запуск обеспечивает гарантированную производительность.

3. Аудит и кастомизация (Auditability & Customization): Для глубокой отладки, аудита каждого вызова или тонкой настройки модели под узкоспециализированный домен, локальный контроль — это необходимость. Вы можете экспериментировать с разными версиями весов и архитектурами без оплаты за каждый тестовый прогон.

Сценарии, где локальный стек побеждает:

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

• Офлайн-режимы работы: Приложения, предназначенные для работы в местах с нестабильным или отсутствующим интернет-соединением (полевые выезды, удаленные офисы).

• Исследовательские лаборатории: Когда цель — не просто получить ответ, а понять почему модель ответила именно так, требуя полного контроля над пайплайном.

Эволюция от «Тряпки» к Промышленному Стандарту

Если вы начинали с метафоры «тряпки» — то есть, с поиска простого, универсального «обертывания» для работы с LLM — то ваш путь ведет к созданию собственного, контролируемого, локального API-слоя. Этот слой, который вы строите поверх Ollama, становится вашим инструментом для локальной LLM, который абстрагирует сложность работы с моделями, векторными базами и промптами. Он превращает набор разрозненных компонентов в единый, надежный, и главное — приватный сервис. Таким образом, локальный стек не просто заменяет облако; он переопределяет требования к безопасности и контролю в области ИИ.