AI-термины 2026: карта понятий от модели до агента
LLM генерирует текст на основе последовательности токенов, training обучает параметры модели, inference запускает готовую модель, а fine-tuning адаптирует её под конкретное поведение или набор задач. RAG добавляет в запрос найденные фрагменты внешних документов. MCP описывает стандартизированный способ подключать к AI-приложению инструменты, ресурсы и шаблоны. Opaque recurrence относится к повторяющимся внутренним вычислениям reasoning-модели, которые не представлены пользователю в виде прозрачной текстовой цепочки.
Эти термины описывают разные слои одной системы. LLM отвечает за генерацию, inference-движок за вычисление ответа, RAG за поиск знаний, MCP за подключение внешних возможностей, а AI-агент связывает компоненты в последовательность действий. Reasoning-модели добавляют отдельный вопрос: сколько вычислений модель выполняет перед финальным ответом и насколько этот процесс доступен для проверки.
Глоссарий нужен для чтения документации и новостей без терминологической путаницы. Каждый термин полезно проверять по четырём пунктам: что он описывает, на каком этапе применяется, что меняет на практике и какие ограничения создаёт.
Шесть уровней, на которых говорят об AI
| Уровень | Ключевые термины | Практический вопрос |
|---|---|---|
| Модель | LLM, Transformer, reasoning model, параметры | Что умеет модель и как она обрабатывает входной текст? |
| Обучение и адаптация | training, pretraining, post-training, fine-tuning, instruction tuning | Как модель получила способности и можно ли изменить её поведение? |
| Запуск | inference, prefill, decoding, KV-cache | Как модель считает ответ и какие ресурсы ей нужны? |
| Скорость | token throughput, tokens per second, TTFT, latency, batching | Как быстро система начинает отвечать и обрабатывает запросы? |
| Внешние знания | RAG, embeddings, chunking, reranking, vector database | Как передать модели актуальные документы? |
| Инструменты и действия | MCP, API, function calling, tools, workflow, AI-агент | Как система получает данные из сервисов и выполняет операции? |
Сквозной сценарий выглядит так: пользователь задаёт вопрос, приложение превращает его в токены и передаёт LLM через inference-движок. RAG ищет подходящие фрагменты во внутренней базе, а MCP может предоставить инструмент для запроса к CRM или файловому хранилищу. Модель выбирает следующий шаг согласно заданному workflow, получает результат инструмента и формирует ответ. Каждый слой можно заменить отдельно, поэтому ошибка в ответе не всегда связана с качеством самой LLM.
Как пользоваться глоссарием при чтении новостей и документации
- Определите объект. Термин может обозначать модель, процесс обучения, режим вычислений, метрику, протокол или компонент приложения.
- Найдите этап применения. Training происходит до публикации модели, inference запускается при каждом запросе, а RAG и MCP работают на уровне приложения.
- Свяжите термин с измеримым эффектом. Контекстное окно ограничивает объём входных данных, throughput описывает скорость, а fine-tuning меняет параметры или поведение модели.
- Проверьте ограничения. Большое контекстное окно не создаёт долговременную память, RAG не гарантирует правильный поиск, а подключённый tool расширяет поверхность риска.
У новых исследовательских терминов может не быть единого определения. Это особенно заметно в обсуждениях скрытого reasoning и opaque recurrence. В таких случаях нужно сверять значение со словарём конкретной статьи или документации, а не переносить термин в другой контекст без оговорок.
LLM: что это и как языковая модель обрабатывает запрос
LLM, large language model, это языковая модель, обученная работать с последовательностями токенов и предсказывать продолжение контекста. При генерации она получает входные токены, вычисляет вероятности возможных следующих токенов и постепенно формирует ответ. В типичной системе LLM окружена дополнительными слоями: чат-интерфейсом, шаблоном запроса, inference-сервером, хранилищем документов и инструментами.
Поэтому чат-приложение не равно модели. Модель может не иметь доступа к интернету, файлам или календарю, пока приложение не передаст ей соответствующий контекст или не подключит инструмент. Текстовый ответ выглядит цельным, но за ним стоят токенизация, вычисления внутри нейросети, выбор токенов и правила оркестрации.
Токены, контекстное окно и параметры
Токен это элемент, на который токенизатор разбивает текст. Токеном может быть целое слово, часть слова, знак препинания или пробел в зависимости от используемого словаря. Русский текст, редкие имена и технический код могут занимать больше токенов, чем визуально похожая по длине английская фраза.
Контекстное окно задаёт максимальный объём токенов, доступный модели в конкретном запросе. Если окно составляет 32 000 токенов, это ограничение относится к совокупности инструкции, истории диалога, найденных документов и генерируемого ответа. Контекстное окно не равно долговременной памяти: после завершения сессии модель сама не обязана хранить сведения о разговоре.
Параметры это числовые настройки нейросети, которые формируются при обучении. Их количество часто используют как грубый показатель размера модели, но оно не описывает качество на каждой задаче. Две модели с близким числом параметров могут различаться обучающими данными, архитектурой, постобучением, поддержкой инструментов и поведением при длинном контексте.
Большинство современных LLM используют Transformer или архитектуры, построенные вокруг его идей. Механизм attention помогает сопоставлять части контекста, а KV-cache сохраняет промежуточные представления уже обработанных токенов во время генерации. Поэтому длина контекста влияет не только на качество работы с длинным документом, но и на требования к памяти.
Почему LLM не равна поисковой системе и базе знаний
LLM генерирует наиболее вероятное продолжение на основе изученных закономерностей и переданного контекста. Поисковая система находит документы по индексу, а база знаний хранит структурированные записи с определённой схемой доступа. Эти механизмы могут работать вместе, но выполняют разные функции.
- Модель может сформулировать убедительный ответ без проверки актуальности фактов.
- Поиск может вернуть свежий документ, но не объяснить его содержание без дополнительной обработки.
- База данных способна точно вернуть запись по идентификатору, однако не заменяет генерацию естественного языка.
- RAG связывает поиск и генерацию, передавая найденные фрагменты в контекст LLM.
Запрос «какие правила действуют сегодня» требует источника с актуальными данными. Запрос «перепиши этот текст в форме технической инструкции» может решаться одной моделью, если в контексте уже есть нужный материал. Добавление RAG к задаче без подходящего индекса не исправит плохую структуру документов.
Базовые характеристики модели, которые встречаются в спецификациях
| Характеристика | Что она описывает | Чего она не гарантирует |
|---|---|---|
| Размер модели | Масштаб параметров и потенциальный объём вычислений | Автоматическое превосходство на каждой задаче |
| Контекстное окно | Объём токенов одного запроса и ответа | Надёжное запоминание всех деталей длинного текста |
| Формат весов | Способ представления параметров, например FP16 или квантованный формат | Одинаковое качество и скорость во всех inference-движках |
| Мультимодальность | Работу с текстом, изображениями, аудио или другими типами входных данных | Идентичную точность для всех модальностей |
| Специализация | Сильные стороны модели: код, диалог, анализ, перевод или reasoning | Хороший результат за пределами заявленного сценария |
При сравнении облачной и локальной LLM нужно смотреть на полный сценарий: формат модели, поддерживаемый inference-движок, лимит контекста, приватность данных, доступ к инструментам и условия лицензии. Одна строка в карточке модели не заменяет описание условий запуска.
Training: что это в машинном обучении, и чем он отличается от inference и fine-tuning
Training, или обучение, меняет параметры модели под воздействием данных и выбранной целевой функции. В процессе модель получает примеры, вычисляет ошибку предсказания, рассчитывает градиенты и обновляет параметры. Генерация ответа в чате использует уже полученные параметры и относится к inference.
Обучение и запуск требуют разных ресурсов. Training обычно работает с большими наборами данных, множеством итераций и распределёнными вычислениями. Inference должен обслуживать отдельные запросы или поток пользователей с приемлемыми задержкой и стоимостью.
Training что это в машинном обучении
Pretraining формирует базовые языковые закономерности на большом наборе данных. Модель учится продолжать последовательности и постепенно настраивает параметры. Конкретный состав корпуса, фильтры, цели обучения и архитектура зависят от разработчика и требуют проверки по документации конкретной модели.
Post-training объединяет последующие этапы подготовки модели. К ним могут относиться instruction tuning, обучение на предпочтениях, настройка формата ответа и специализированное дообучение. Названия и границы этапов различаются между командами, поэтому слово training в новости нужно читать вместе с описанием процесса.
Результат обучения не равен базе фактов с гарантией точности. Параметры кодируют статистические зависимости в данных. Модель может воспроизводить устаревшую информацию, смешивать похожие сущности или уверенно заполнять пробелы. Проверка на независимом наборе задач нужна даже после длительного обучения.
Inference: что происходит при запуске готовой модели
Inference начинается с подготовки входа: приложение применяет chat template, токенизирует инструкцию и передаёт получившуюся последовательность модели. Сначала выполняется обработка входного контекста, этот этап часто называют prefill. Затем модель генерирует выходные токены, этап называется decoding.
Во время decoding система обычно сохраняет ключи и значения attention в KV-cache. Это уменьшает необходимость повторно обрабатывать уже прочитанный контекст при каждом следующем токене, но требует дополнительной памяти. Длинный контекст, большой размер модели, высокая точность весов и несколько параллельных запросов увеличивают нагрузку на GPU или оперативную память.
Для локального пользователя inference связан с запуском модели в конкретном движке, например через сервер, библиотеку или приложение. Один и тот же набор весов может показывать разную скорость из-за формата квантования, поддержки GPU, настроек batching и версии движка. Универсальной цифры производительности для модели без условий измерения не существует.
Fine-tuning, instruction tuning и промптинг
| Подход | Что меняется | Когда подходит | Ограничение |
|---|---|---|---|
| Системный промпт | Инструкция в текущем запросе | Формат, тон, правила и роль ответа | Правила нужно передавать снова, модель не получает новых параметров |
| Few-shot | Примеры прямо в контексте | Показ нужного формата на нескольких примерах | Примеры расходуют контекст и не всегда обобщаются |
| RAG | Внешний контекст во время запроса | Актуальные документы и часто меняющиеся знания | Качество зависит от индекса, поиска и найденных фрагментов |
| Fine-tuning | Параметры или адаптеры модели | Устойчивая специализация поведения, формата или домена | Нужны данные, вычислительные ресурсы и контроль деградации общих навыков |
| Instruction tuning | Поведение по инструкциям на подготовленных примерах | Обучение следовать командам и заданному формату | Итог зависит от качества и разнообразия примеров |
Fine-tuning не заменяет RAG, когда документы часто обновляются. Дообучение может закрепить стиль ответа или узкую специализацию, а RAG подставляет актуальные сведения при каждом запросе. Иногда достаточно хорошего промпта, особенно если задача простая и не требует стабильного поведения на большом потоке запросов.
Решение выбирают по причине проблемы. Если модель знает формат, но не видит внутренние документы, нужен слой поиска. Если она видит сведения, но постоянно нарушает структуру результата, можно оценить few-shot, промптинг или fine-tuning. Если изменились только факты, обновлять веса обычно менее удобно, чем обновлять индекс документов.
GPU и VRAM: почему требования к training и inference различаются
VRAM хранит веса модели, KV-cache, временные тензоры и служебные буферы. При inference объём памяти зависит от размера весов, их точности, длины контекста и количества параллельных запросов. Квантование уменьшает размер представления весов, но может влиять на качество и производительность.
Training требует места для параметров, градиентов, состояний оптимизатора и мини-батчей. Поэтому память, достаточная для запуска готовой квантованной модели, не означает возможность полноценно обучать эту же модель. Для адаптации применяют более экономные методы с адаптерами, однако их требования тоже зависят от архитектуры, длины последовательности и размера набора данных.
При выборе локальной конфигурации нужно фиксировать четыре условия: модель и формат весов, длину контекста, число одновременных запросов и inference-движок. Без них рекомендация по VRAM остаётся приблизительной.
Reasoning-модели: chain-of-thought, latent reasoning и opaque recurrence
Reasoning-модель тратит дополнительные вычислительные шаги на задачу перед выдачей финального результата. Эти шаги могут быть видимыми в текстовом ответе, скрытыми или представлены внутренними состояниями. Дополнительный test-time compute иногда помогает на задачах, где короткая генерация часто приводит к ошибкам, но увеличивает задержку, расход токенов или вычислительную нагрузку.
Внешнее объяснение и фактический внутренний процесс нельзя автоматически считать одним и тем же. Модель может построить убедительную цепочку после выбора ответа, пропустить часть вычислений или сформулировать рационализацию, которая выглядит логично для читателя. Поэтому reasoning оценивают по качеству результата, устойчивости, стоимости и возможности контроля.
Chain-of-thought: текстовая цепочка промежуточных шагов
Chain-of-thought, CoT, это последовательность промежуточных шагов рассуждения, представленная в текстовом виде или используемая при генерации. Для задачи с вычислениями такая цепочка может содержать разбор условия, промежуточные значения и проверку результата. Дополнительный текст увеличивает расход выходных токенов и время генерации.
Текстовая цепочка удобна для отладки, анализа ошибок и оценки того, какие шаги модель считает нужными. Она не даёт гарантии правдивого отчёта о внутренних вычислениях. Читаемое объяснение может быть неполным, ошибочным или сформированным уже после того, как модель выбрала ответ.
Практические разборы reasoning-моделей показывают, насколько сильно результат может зависеть от шаблона запроса и специальных маркеров. Например, в материале о форсированном reasoning через chat template акцент сделан на связи между форматом входа и появлением развёрнутой цепочки. Это отдельный слой поведения, который нельзя путать с доказательством полной прозрачности модели.
Opaque recurrence: что означает непрозрачная рекуррентность
Opaque recurrence можно перевести как непрозрачная рекуррентность. В контексте reasoning это описание повторяющихся внутренних вычислительных шагов или обновлений скрытого состояния, которые не выводятся пользователю как последовательность понятных текстовых рассуждений.
Термин не задаёт одну общепринятую архитектуру. В одной публикации им могут описывать повторную обработку скрытого состояния, в другой, более широкую схему внутреннего углубления вычислений. Нельзя по одному слову заключать, что модель использует конкретный тип рекуррентной нейросети, полностью скрывает reasoning или обладает автономным планированием.
Практический смысл понятия состоит в различии между видимым текстом и внутренним состоянием. Модель может выполнить несколько обновлений скрытого представления и выдать один финальный ответ. Пользователь увидит результат, но не получит полный журнал промежуточных операций в форме, которую легко прочитать и проверить.
При чтении новости об opaque recurrence нужно искать четыре уточнения: какие именно состояния обновляются, сколько повторений выполняется, выводятся ли промежуточные представления и как автор измеряет качество или наблюдаемость. Если этих деталей нет, термин описывает направление или гипотезу, а не полностью зафиксированную спецификацию.
Opaque recurrence и chain-of-thought: в чём разница
| Признак | Chain-of-thought | Opaque recurrence |
|---|---|---|
| Форма промежуточных шагов | Текстовая последовательность токенов | Повторяющиеся скрытые вычисления или обновления состояния |
| Что видит пользователь | Часть или вся текстовая цепочка, если приложение её показывает | Обычно финальный ответ и ограниченные внешние сигналы |
| Расход токенов | Промежуточные шаги могут увеличивать число выходных токенов | Внутренние шаги могут не превращаться в видимый текст |
| Мониторинг | Можно анализировать текст, но его достоверность нужно проверять | Наблюдать процесс сложнее, нужны косвенные метрики и специальные методы анализа |
| Главное ограничение | Объяснение не гарантирует точное отражение внутренних причин | Скрытые состояния труднее интерпретировать и аудировать |
Оба подхода могут приводить к похожему финальному ответу. Разница находится в способе вычисления и доступности промежуточного процесса. Прозрачный текст не равен истинному журналу работы модели, а непрозрачные вычисления не означают автоматически плохое качество.
Почему непрозрачное рассуждение вызывает вопросы у исследователей безопасности
Безопасность AI требует наблюдать не только результат, но и признаки нежелательного поведения. Если промежуточные шаги представлены текстом, их можно использовать как один из сигналов для аудита, классификации и поиска несоответствий. Скрытые вычисления убирают этот сигнал или делают его менее прямым.
- Наблюдаемость. Инженер может видеть ответ, но не знать, какие внутренние представления привели к нему.
- Аудит. Проверка причин отказа или выбора действия становится сложнее, особенно в агентной системе с несколькими вызовами инструментов.
- Соответствие объяснения процессу. Даже видимая цепочка может не отражать реальные причины, а скрытый процесс ещё труднее сопоставить с объяснением.
- Анализ отказов. При ошибке нужно отделить проблему данных, промпта, поиска, инструмента и внутренних вычислений модели.
- Контроль действий. Если reasoning предшествует вызову инструмента, ограничений на финальный текст недостаточно, нужно журналировать и подтверждать сам вызов.
Эти пункты описывают классы рисков и открытые вопросы, а не доказанный вред каждой системы с opaque recurrence. Непрозрачное вычисление может снизить стоимость вывода текста или сократить объём служебного вывода, однако выигрыш нужно сопоставлять с возможностями мониторинга, тестирования и расследования инцидентов.
Отдельные эксперименты с моделями скрытого рассуждения показывают, что изменение поведения может быть связано с обучающими данными, шаблоном ответа и распределением выходных токенов. Это хорошо видно в разборе экспериментальной модели со скрытым reasoning. Такой пример полезен как иллюстрация необходимости проверять не только наличие рассуждений, но и итоговую точность на независимых задачах.
Related concepts: hidden reasoning, test-time compute и monitorability
| Термин | Смысл | Тип понятия |
|---|---|---|
| Hidden reasoning | Промежуточные шаги, которые не показываются пользователю | Свойство или режим поведения модели |
| Latent reasoning | Работа с промежуточными представлениями без обязательного вывода в текст | Описание внутреннего процесса |
| Test-time compute | Дополнительные вычисления во время ответа, а не при обучении | Режим использования вычислительных ресурсов |
| Monitorability | Насколько процесс и результаты можно наблюдать, оценивать и проверять | Исследовательская характеристика системы |
| Reasoning model | Модель, рассчитанная на дополнительные шаги обработки сложной задачи | Класс или маркетинговое обозначение модели |
При выборе reasoning-модели полезно отдельно измерять точность, latency, стоимость токенов, долю отказов и доступность диагностических сигналов. Наличие длинной цепочки в интерфейсе не заменяет такой оценки.
Token throughput: что это и как оценивать скорость AI-системы
Token throughput это скорость обработки или генерации токенов за единицу времени. В простом виде метрика рассчитывается как число токенов / время, но результат зависит от того, какие токены считаются, на каком этапе идёт измерение и сколько запросов обрабатывается одновременно.
В спецификации или тесте значение tokens per second без описания методики мало пригодно для прямого сравнения. На итог влияют длина входа и ответа, размер батча, квантование, тип GPU, версия inference-движка, температура, ограничение максимального числа токенов и наличие параллельных пользователей.
Input throughput, output throughput и tokens per second
Input throughput описывает скорость обработки входного контекста, то есть этап prefill. Большой документ может долго загружаться в вычислительный граф, даже если последующая генерация идёт быстро.
Output throughput описывает скорость decoding, когда модель выдаёт ответ токен за токеном. Именно этот показатель часто видит пользователь как скорость печати. Однако он не включает задержку подготовки большого контекста.
Tokens per second может относиться к любой из этих метрик. В отчёте нужно искать уточнения: input или output, размер запроса, длина ответа, batch size, число одновременных запросов и режим вычислений. Сравнение числа 40 tokens per second из одного теста с числом 50 из другого без этих условий не даёт надёжного вывода.
TTFT, latency и время полного ответа
| Метрика | Что измеряет | Когда особенно важна |
|---|---|---|
| TTFT | Время до первого сгенерированного токена | Интерактивный чат и голосовые интерфейсы |
| Latency | Задержку между запросом и ответом или отдельным событием | Сервисы с ограничением времени отклика |
| Output throughput | Скорость генерации выходных токенов | Длинные ответы и потоковая выдача |
| Полное время ответа | Сумму подготовки, обработки контекста, генерации и сетевых задержек | Оценка реального пользовательского опыта |
Высокий output throughput не гарантирует быстрый интерфейс. Система может быстро печатать текст после долгого prefill. Обратная ситуация тоже встречается: первый токен приходит быстро, но длинный ответ генерируется медленно.
Для интерактивного диалога важны TTFT и стабильная скорость streaming. Для пакетной обработки документов может быть важнее общий throughput группы запросов. Для одного короткого запроса разница между этапами может быть менее заметна, чем сетевая задержка и время подготовки промпта.
Что влияет на throughput в локальном запуске
- Размер и формат модели. Более крупные веса обычно требуют больше памяти и вычислений. Квантование сокращает требования, но его эффект зависит от движка и аппаратной поддержки.
- VRAM и размещение данных. Если часть вычислений уходит в оперативную память или на CPU, скорость может измениться. Конкретный эффект нужно измерять на выбранной конфигурации.
- Длина контекста. Большой вход увеличивает стоимость prefill и объём KV-cache.
- Inference-движок. Разные движки используют разные kernels, схемы управления памятью и способы batching.
- Batching. Пакетная обработка может повысить суммарный throughput, но увеличить latency отдельного запроса.
- Конкурентные запросы. Несколько пользователей делят память и вычислительные ресурсы, поэтому показатель для одного запроса не описывает многопользовательский режим.
Корректный локальный тест фиксирует модель, формат весов, prompt, длину контекста, длину ответа, температуру, batch size, число запросов и версию движка. Для практического выбора полезно записывать медианное и худшее время, а не одну наиболее удачную цифру.
RAG: что это и как модель работает с внешними документами
RAG, retrieval augmented generation, это архитектура, в которой система сначала ищет релевантные фрагменты во внешнем наборе данных, а затем передаёт их LLM для генерации ответа. Модель получает дополнительный контекст во время запроса, поэтому документы можно обновлять без полного переобучения весов.
RAG подходит для внутренних инструкций, технической документации, каталогов, регламентов и других коллекций, где источник знаний меняется чаще, чем модель. Качество ответа зависит от всей цепочки: подготовки документов, поиска, фильтрации, формирования контекста и генерации.
Как устроен RAG-пайплайн
- Подготовка документов. Система извлекает текст, заголовки, таблицы, метаданные и права доступа из исходных файлов.
- Chunking. Большие документы делятся на фрагменты. Слишком короткие куски теряют смысл, слишком длинные ухудшают точность поиска и расходуют контекст.
- Embeddings. Каждый фрагмент превращается в числовое представление, которое помогает сопоставлять смысл запроса и текста.
- Индекс. Векторная база данных или другой поисковый индекс сохраняет представления и метаданные фрагментов.
- Retrieval. Запрос пользователя преобразуется в поисковое представление, после чего система выбирает кандидатов.
- Reranking. Дополнительная модель или правило может переупорядочить найденные фрагменты по релевантности.
- Grounding. Отобранные сведения вставляются в контекст LLM вместе с инструкциями по использованию источников.
- Generation. Модель формирует ответ на основе вопроса и переданного контекста.
Ошибка на любом шаге меняет результат. Если нужный документ не попал в индекс, генератор не сможет восстановить его содержание из воздуха. Если chunking разорвал таблицу или заголовок оказался отдельно от текста, поиск может найти формально похожий, но практически бесполезный фрагмент.
RAG, fine-tuning и длинный контекст: что выбрать
| Подход | Основная цель | Подходящий сценарий | Ограничение |
|---|---|---|---|
| RAG | Подключить внешние и обновляемые знания | Ответы по внутренним документам и каталогам | Поиск может пропустить нужный фрагмент |
| Fine-tuning | Изменить поведение, стиль или специализацию модели | Стабильный формат классификации или доменная адаптация | Обновление фактов требует повторной работы с моделью |
| Длинный контекст | Передать большой объём текста в одном запросе | Анализ связного документа или нескольких материалов | Растут требования к памяти, задержка и риск потери важных деталей |
Эти подходы можно сочетать. Fine-tuning задаёт манеру обработки, RAG приносит актуальные сведения, а длинный контекст помогает сохранить больше связанных фрагментов. Выбор зависит от частоты обновления данных, требований к цитированию, бюджета вычислений и допустимой задержки.
Ограничения RAG и контроль качества
- Нерелевантный поиск. Система находит слова, похожие на запрос, но не отвечает на его смысл.
- Пропуски в индексе. Документ может не загрузиться, получить неверные права или потерять часть текста при извлечении.
- Устаревшие данные. RAG передаёт то, что есть в хранилище, поэтому индекс требует контроля версий и регулярного обновления.
- Дублирование. Несколько копий одного фрагмента занимают контекст и создают ложное ощущение подтверждения.
- Ошибки chunking. Разрыв таблиц, списков и ссылок между частями ухудшает понимание документа.
- Права доступа. Поиск должен учитывать пользователя, иначе модель может получить сведения, которые нельзя показывать.
- Генерация без опоры. Даже при наличии правильного фрагмента модель может неверно его интерпретировать.
Контроль качества разделяют на две части. Retrieval проверяют по тому, попал ли нужный фрагмент в выдачу и занял ли он подходящую позицию. Generation проверяют по точности, полноте, соблюдению ограничений и соответствию найденным данным. Полезно сохранять поисковые фрагменты и служебный журнал, чтобы разбирать ошибки по шагам.
MCP: что это и как протокол подключает модель к инструментам
MCP, Model Context Protocol, это протокол взаимодействия между AI-приложением и совместимыми компонентами, которые предоставляют контекст, инструменты или другие описанные возможности. Он задаёт общий способ обнаруживать доступные функции, передавать параметры и возвращать результат. MCP не заменяет LLM, inference-движок или агентный workflow.
В архитектуре с MCP модель обычно не подключается к серверу напрямую. Host-приложение управляет сессией, MCP-клиент внутри host устанавливает соединение с MCP-сервером, а сервер публикует доступные tools, resources и prompts. Конкретные детали зависят от версии спецификации и реализации, поэтому протокольные поля нужно сверять с актуальной документацией выбранного стека.
Host, client, server, tools, resources и prompts
| Компонент | Роль | Пример задачи |
|---|---|---|
| Host | Основное AI-приложение, которое управляет моделью, сессиями и подключениями | Рабочий чат или среда разработки с доступом к инструментам |
| Client | Компонент host, который устанавливает связь с MCP-сервером | Передача запроса на список доступных возможностей |
| Server | Процесс, публикующий инструменты, ресурсы или шаблоны | Адаптер к файловой системе, базе данных или API |
| Tools | Операции, которые система может вызвать с параметрами | Создать задачу, получить запись, выполнить поиск |
| Resources | Предоставляемый контекст или данные | Документ, схема, запись или другой доступный ресурс |
| Prompts | Подготовленные шаблоны инструкций или сценариев | Стартовый шаблон для типовой операции |
Доступность функции в MCP не означает, что модель обязательно вызовет её. Модель или оркестратор выбирает действие по описанию инструмента, текущему запросу и правилам приложения. В критичных сценариях вызов должен проходить проверку параметров и подтверждение пользователя.
MCP, API, function calling и RAG: не одно и то же
| Технология | Что она задаёт | Связь с моделью |
|---|---|---|
| API | Контракт конкретного сервиса: методы, параметры, ответы и авторизация | Модель обращается к нему через приложение или адаптер |
| Function calling | Формат, в котором модель предлагает вызвать функцию с аргументами | Оркестратор проверяет аргументы и запускает функцию |
| RAG | Поиск внешнего контекста и его передача в prompt | Модель использует найденные фрагменты при генерации |
| MCP | Общий протокол публикации инструментов, ресурсов и шаблонов | AI-приложение получает стандартизированный способ работать с совместимыми серверами |
Прямой API-вызов может быть самым простым решением для одного сервиса. Function calling описывает взаимодействие модели и функции, но не задаёт полноценную схему подключения разных серверов. RAG решает задачу поиска знаний. MCP может выступать транспортом и договорённостью между host, client и server, но сам по себе не создаёт память, планирование или автономность.
Безопасность MCP-интеграций
Подключение инструмента расширяет возможности системы вместе с зоной риска. Модель может сформировать корректный на вид вызов с опасными параметрами, а внешний контекст может содержать инструкцию, которую нельзя выполнять. Поэтому доверие к MCP-серверу, инструментам и данным разделяют по уровням.
- Выдавайте минимальные права: отдельные операции чтения и записи, ограниченные каталоги, конкретные проекты и окружения.
- Проверяйте аргументы до вызова инструмента: идентификаторы, пути, диапазоны значений и команды.
- Запрашивайте подтверждение пользователя перед удалением, публикацией, отправкой сообщений и изменением данных.
- Не передавайте серверу секреты, которые не нужны для конкретной операции.
- Журналируйте запрос модели, выбранный tool, аргументы, результат и решение пользователя.
- Учитывайте prompt injection в документах, веб-страницах и результатах инструментов.
- Разделяйте тестовую и рабочую среды, чтобы ошибка не затронула реальные данные.
Безопасность нельзя свести к скрытию текста reasoning. Контроль должен охватывать входные данные, права, сетевые соединения, вызовы инструментов, результаты и действия оркестратора.
AI-агенты на практике: как связаны LLM, RAG, MCP и inference
AI-агент это система, которая использует модель для интерпретации задачи, выбора следующего шага и работы с состоянием или инструментами по заданному workflow. Чат с одной кнопкой поиска ещё не обязательно агент. К агентной архитектуре добавляются цикл принятия решений, обработка результатов, ограничения, журналирование и правила остановки.
Минимальная схема AI-агента
запрос -> LLM -> выбор шага -> RAG или tool -> результат -> следующий шаг -> ответ
В минимальной конфигурации нужны LLM и inference-движок. Модель получает задачу, формирует ответ или предлагает действие, а приложение решает, разрешено ли его выполнить. RAG добавляют, когда системе нужны внешние документы. MCP используют, когда инструменты и ресурсы нужно подключать через общий протокол. Memory хранит состояние, которое должно пережить отдельный шаг или запрос.
Планирование может быть явным, когда приложение задаёт фиксированную последовательность, или динамическим, когда модель выбирает следующий инструмент. Фиксированный workflow проще тестировать и ограничивать. Динамическая схема гибче, но увеличивает число возможных ошибок и требует строгих лимитов по времени, числу шагов и доступным действиям.
При каждом шаге полезно сохранять входной контекст, выбранное действие, параметры, ответ инструмента и причину остановки. Такой журнал помогает понять, ошибка возникла в retrieval, LLM, API, MCP-сервере или бизнес-правиле.
Когда достаточно LLM, а когда нужны RAG, MCP или агентный workflow
| Задача | Минимальный слой | Что добавить при росте требований |
|---|---|---|
| Переписать, классифицировать или суммировать переданный текст | LLM и хороший prompt | Fine-tuning для стабильного формата на большом потоке |
| Ответить по внутренним документам | RAG с контролем доступа | Reranking, цитирование фрагментов и оценка retrieval |
| Получить данные из внешнего сервиса | API или function calling | MCP, если нужно подключать несколько совместимых серверов |
| Выполнить последовательность действий | Явный workflow | Agent loop с памятью, лимитами и подтверждением опасных операций |
| Автоматизировать процесс с изменением данных | Оркестратор и проверяемые tools | Разделение прав, журналирование, повтор операций и ручные точки контроля |
Избыточная архитектура усложняет поддержку. Для генерации шаблонного письма не нужны MCP и автономное планирование. Для ответа по регламенту RAG полезнее fine-tuning, если регламент регулярно меняется. Для операции с финансовыми или производственными данными нужен контролируемый workflow, даже если модель уверенно выбирает правильный tool.
Термины, которые влияют на выбор локальной или облачной модели
| Фактор | Локальный запуск | Облачный сервис |
|---|---|---|
| Приватность | Данные можно оставить внутри собственной инфраструктуры, но ответственность за защиту лежит на владельце | Нужно проверить правила хранения, обработки и передачи данных провайдеру |
| VRAM и квантование | Размер модели и формат весов напрямую ограничивают доступный сценарий | Аппаратные ограничения скрыты, но влияют на тариф и лимиты |
| Inference и throughput | Скорость зависит от GPU, движка, контекста и числа пользователей | Зависит от выбранной модели, нагрузки сервиса и сетевой задержки |
| Контекст | Длинный контекст увеличивает требования к собственной памяти | Лимит задан API и может различаться между моделями |
| Tools и MCP | Проще контролировать сеть, файлы и права, но интеграции нужно обслуживать самостоятельно | Удобнее подключать готовые сервисы, однако появляется зависимость от платформы |
| Стоимость | Основные расходы связаны с оборудованием, электричеством и обслуживанием | Расход зависит от входных и выходных токенов, запросов и дополнительных функций |
Для локальной LLM сначала оценивают задачу, нужный контекст, допустимую задержку и число пользователей. Потом подбирают формат весов, VRAM и движок. При сравнении моделей полезно фиксировать одинаковые условия, как рекомендует практический чек-лист оценки новых AI-моделей.
Обзор локальных решений нужно читать с учётом версии модели, контекста, KV-cache и стоимости inference. Эти параметры часто объясняют разницу между заявленной производительностью и реальным поведением на домашнем ПК, что подробно разбирается в материале о сравнении открытых LLM и условий их запуска.
Краткая шпаргалка: какой термин искать в документации
| Термин | О чём он | Какой вопрос закрывает |
|---|---|---|
| LLM | Языковая модель, работающая с токенами | Что генерирует текст и как устроен базовый ответ? |
| Training | Обучение параметров на данных | Как модель получила свои способности? |
| Inference | Запуск готовой модели | Как получить ответ и какие ресурсы нужны? |
| Fine-tuning | Адаптация параметров или адаптеров | Как закрепить специализированное поведение? |
| Token throughput | Скорость обработки или генерации токенов | Насколько быстро работает система при заданной методике? |
| Reasoning | Дополнительная обработка сложной задачи | Почему модель тратит больше времени или вычислений на ответ? |
| Opaque recurrence | Повторяющиеся скрытые вычисления или обновления состояния | Что означает непрозрачный внутренний reasoning и как его проверять? |
| RAG | Поиск внешних фрагментов перед генерацией | Как дать модели актуальные документы? |
| MCP | Протокол подключения контекста и инструментов | Как стандартизировать связь AI-приложения с внешними компонентами? |
| AI-агент | Система с моделью, состоянием, инструментами и workflow | Как организовать несколько шагов и действий по одной задаче? |
Для быстрой диагностики архитектуры задайте один вопрос: где находится проблема, в знаниях, поведении модели, вычислениях, поиске или инструментах? RAG помогает с внешними документами, fine-tuning меняет устойчивое поведение, MCP подключает совместимые возможности, а агентный workflow управляет последовательностью действий. Такой разбор помогает выбрать минимальный набор компонентов и заранее определить, что потребуется измерять и контролировать.