Генеративный ИИ: модели, поиск, инструменты и приложения — это не одно и то же

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

Что на самом деле означает «генеративный ИИ»?

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

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

Простейшая полезная модель системы генеративного ИИ

Для первой мысленной модели представьте корпоративного ассистента, отвечающего: «Может ли этот клиент получить возврат сегодня?» Полезный ответ может потребовать нескольких разных обязанностей. Языковая модель может интерпретировать вопрос и написать объяснение, но текущее состояние заказа может поступить из инструмента базы данных, политика возврата может поступить из поиска по документам, разрешения могут обеспечиваться приложением, а окончательное действие может потребовать контролируемого вызова API.

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

Шесть границ, которые имеют значение

1. Модель: генерация — её основная обязанность

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

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

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

2. Поиск: нахождение внешних доказательств — это отдельная операция

Поиск выбирает информацию из внешнего источника до или во время генерации. Работа 2020 года «Retrieval-Augmented Generation» Льюиса и соавторов сделала это разделение явным, объединив параметрическую генеративную модель с извлечённой непараметрической памятью. Современные продакшн-системы используют множество вариантов поиска, но архитектурная идея остаётся: полезные доказательства можно извлекать во время инференса, а не полагаться только на то, что модель выучила во время обучения.

Поиск может использовать лексический поиск, эмбеддинги, векторный поиск, гибридный поиск, SQL, графы знаний, фильтры по метаданным, API или другие механизмы отбора. Таким образом, векторная база данных — это лишь один из возможных компонентов поиска, а не определение RAG.

3. Инструменты: доступ и действие — это не знания модели

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

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

Таким образом, использование инструментов порождает два отдельных вопроса: Может ли модель запросить эту возможность? и Авторизует и выполнит ли это приложение? Продакшн-система не должна путать намерение модели с разрешением на побочный эффект.

4. Контекст: то, что модель видит прямо сейчас

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

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

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

5. Среда выполнения и оркестрация: координация цикла

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

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

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

6. Приложение: где ИИ становится продуктом

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

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

Как части работают вместе в реальном запросе

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

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

Разные ИИ-продукты используют разные комбинации

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

Доказательство реализации: Aaasaasa AI Client

Aaasaasa AI Client — это локальное настольное ИИ-рабочее пространство, созданное с использованием Nuxt 4, Electron и TypeScript. Его AI Hub намеренно разделяет агента/клиента, провайдера, модель, расположение среды выполнения, разрешения и веб-клиент, вместо того чтобы рассматривать их как одну настройку «ИИ».

Это разделение создаёт конкретное поведение. Direct Chat может общаться с моделями без инструментов файловой системы или оболочки. Агент Codex может использовать выбранное рабочее пространство и профиль разрешений. Ollama может обеспечивать прямой локальный вывод, в то время как LM Studio и настраиваемые конечные точки, совместимые с OpenAI, представляют другие пути провайдеров. Локально запущенный процесс Codex всё ещё может использовать облачную модель, поэтому пользовательский интерфейс и архитектура не приравнивают локальную среду выполнения к локальному выводу.

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

Типичные категориальные ошибки

Режимы отказа при разрушении границ

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

Что стабильно, а что зависит от версии?

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

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

Тест границ компонентов ИИ

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

Чем генеративный ИИ не является

Генеративный ИИ не является синонимом LLM, хотя LLM — это крупный класс генеративных моделей. Он также не является синонимом RAG, векторной базы данных, агента, протокола инструментов, чат-интерфейса или приложения.

Эти концепции могут быть связаны, но каждая отвечает на свой архитектурный вопрос. LLM отвечает на вопрос, как создаётся языковой вывод. Поиск отвечает на вопрос, откуда берутся внешние доказательства. Инструменты отвечают на вопрос, как предоставляются внешние возможности. Контекст отвечает на вопрос, что модель может видеть. Среда выполнения отвечает на вопрос, как координируется исполнение. Приложение отвечает на вопрос, как возможность становится контролируемым продуктом.

Куда двигаться дальше в графе знаний

Когда эти границы ясны, более глубокие темы становится легче разместить. RAG относится к поиску и построению контекста. Retrieval Trigger решает, когда требуются внешние доказательства. Память агента касается того, что сохраняется во времени. Вызов инструментов и MCP относятся к доступу к возможностям. Обвязки агентов относятся к оркестрации среды выполнения. RBAC, изоляция арендаторов и доменная авторизация относятся к границе безопасности приложения и платформы.

Ограничения

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

Терминология также различается у поставщиков и в исследованиях. «Агент», «среда выполнения», «память», «инструмент», «коннектор» и «контекст» могут определяться по-разному. Определения здесь выбраны так, чтобы сделать операционное владение и диагностику сбоев явными, а не утверждать, что каждый фреймворк использует идентичный словарь.

Раздел об AI-клиенте Aaasaasa документирует один шаблон реализации. Он демонстрирует, что явные границы практичны, но не доказывает, что такая же компоновка компонентов оптимальна для каждого AI-продукта.

Что могло бы изменить этот ответ?

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

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

Заключение

Генеративный ИИ становится проще проектировать, как только «ИИ» перестаёт рассматриваться как один чёрный ящик. Модель — это генеративный компонент, а не полный продукт. Извлечение предоставляет внешние доказательства. Инструменты открывают возможности. Контекст переносит выбранную информацию в текущий вывод. Среда выполнения координирует исполнение. Приложение владеет авторитетной границей продукта.

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

Таким образом, устойчивый архитектурный вопрос — не «Какую модель ИИ мы используем?» Он таков: какую ответственность несёт каждый компонент, какие доказательства пересекают каждую границу и какому уровню разрешено изменять реальное состояние?

Часто задаваемые вопросы

Глоссарий

Первоисточники и доказательства реализации

Приведённые ниже стабильные определения опираются на стандарты и исследования; быстро меняющиеся примеры реализации используют актуальную официальную инженерную документацию. Aaasaasa AI Client является оригинальным доказательством реализации и был проверен на соответствие состоянию его кодовой базы и документации на 26 июля 2026 года.