AI-стек с нуля: как устроены LLM, RAG, агенты и MCP под капотом
За последние три года AI-ландшафт разросся до размеров целой экосистемы: LLM, RAG, векторные базы, эмбеддинги, LangChain, LangGraph, MCP, агенты, prompt engineering — терминов больше, чем успеваешь запомнить. Многие разработчики прыгают сразу к агентам, не понимая фундамента, и получают системы, которые работают на демо, но падают в production. В этой статье мы пройдём весь путь от базовых принципов до production-архитектуры — без упрощений, которые вредят, и без лишней воды.
Что такое LLM и почему размер имеет значение
Большая языковая модель (Large Language Model, LLM) — это нейронная сеть, обученная предсказывать следующее слово в последовательности. Этот простой принцип масштабируется до поразительных результатов: модели вроде GPT-4, Claude и Gemini обучаются на триллионах токенов из тысяч доменов — медицины, права, программирования, науки. Токен — это примерно три четверти английского слова, и когда модель видит достаточно токенов, она начинает улавливать не только грамматику, но и логику, структуру аргументации, стилистические паттерны.
Ключевой параметр любой LLM — контекстное окно (context window), то есть объём текста, который модель может удерживать в "памяти" во время одного разговора. У GPT-4.1 это около миллиона токенов, у Claude 3 Opus — 200 тысяч, у Gemini 2.5 Pro — миллион. Но цифры обманчивы: даже в моделях с большим контекстным окном информация в середине длинного документа обрабатывается хуже, чем в начале или конце. Это ограничение имеет прямое следствие для архитектуры: нельзя просто засунуть всю корпоративную базу знаний в промпт и ожидать качественных ответов.
Представьте, что вы просите человека запомнить номер π до 50 знаков и затем процитировать его. Некоторые справятся, но большинство начнут путать цифры в середине. С LLM то же самое: чем дальше от начала контекста, тем выше вероятность искажения. Поэтому возникает необходимость в механизмах, которые отбирают только релевантную информацию — и здесь на сцену выходят эмбеддинги и векторные базы данных.
Эмбеддинги: когда смысл становится математикой
Эмбеддинг — это векторное представление текста. Специальная модель (например, OpenAI text-embedding-ada-002 или её аналоги) превращает фразу в массив чисел фиксированной длины — обычно 1536 измерений. Каждое измерение отвечает за какой-то семантический аспект: формальность, тематику, эмоциональную окраску, грамматическую роль.
Магия эмбеддингов в том, что похожие по смыслу тексты получают близкие векторы. "Отпуск" и "каникулы" будут математически ближе друг к другу, чем "отпуск" и "налоговая декларация". Это свойство позволяет находить семантически релевантные документы без ключевых слов: достаточно вычислить вектор запроса и найти ближайшие векторы в базе.
Без эмбеддингов поиск по базе знаний работал бы как Ctrl+F: ищешь точное совпадение, пропускаешь синонимы и перефразировки. С эмбеддингами поиск становится семантическим: он понимает, что "политика удалённой работы" и "правила работы из дома" — это одно и то же, даже если слова не совпадают. Это фундаментальное изменение, которое делает RAG возможным.
RAG: как научить LLM читать то, чего она не видела при обучении
RAG (Retrieval-Augmented Generation, генерация с дополненным поиском) решает центральную проблему LLM: их знания ограничены датой обучения и не включают приватные данные компании. Если спросить стандартную модель о внутренней политике вашей организации, она выдумает убедительный, но ложный ответ — явление, известное как галлюцинация.
RAG работает в два этапа. Сначала система получает запрос пользователя, превращает его в эмбеддинг и ищет в векторной базе наиболее похожие документы. Затем эти документы подставляются в промпт вместе с исходным вопросом, и модель генерирует ответ, опираясь на предоставленный контекст. Результат: ответы точные, проверяемые и привязанные к реальным документам, а не к обобщённым знаниям модели.
Но RAG — не волшебная палочка. Качество зависит от того, как документы разбиты на фрагменты (chunking). Если фрагменты слишком мелкие, теряется контекст. Если слишком крупные — в контекстное окно помещается мало документов, и релевантность падает. Для юридических текстов, где важна структура параграфов, используют paragraph-based chunking с умными перекрытиями. Для технической документации — разбиение по заголовкам и секциям. Выбор стратегии chunking напрямую влияет на качество ответов.
Векторные базы данных: где живут эмбеддинги
Векторная база данных — это хранилище, оптимизированное для поиска ближайших соседей в многомерном пространстве. Когда у вас миллионы документов, перебирать все векторы и вычислять расстояние до каждого — слишком медленно. Векторные базы используют специализированные индексы (HNSW, IVF) для приближённого поиска, который работает за миллисекунды даже на миллиардах векторов.
Популярные решения — Pinecone, Chroma, Weaviate, Milvus, pgvector. Выбор зависит от масштаба и инфраструктуры: Chroma подходит для прототипов, Pinecone — для managed-решений, pgvector — если вы уже используете PostgreSQL. Важно понимать, что векторная база — это не замена обычной базе данных, а дополнение к ней. Метаданные документов (автор, дата, категория) обычно хранятся в реляционной базе, а семантический поиск выполняется в векторной.
LangChain: абстракция над хаосом провайдеров
Когда вы начинаете строить AI-приложение, быстро обнаруживаете, что каждый провайдер LLM имеет свой SDK, свой формат запросов, свою систему ошибок. Переключение с OpenAI на Anthropic требует переписывания кода. LangChain решает эту проблему, предоставляя единый интерфейс для всех провайдеров.
LangChain — это не просто обёртка над API. Он предоставляет готовые компоненты для типичных задач: загрузка документов из разных источников, разбиение текста на фрагменты, вычисление эмбеддингов, поиск в векторных базах, управление памятью разговора. Вместо того чтобы писать сотни строк кода для подключения к Pinecone, вызываете один метод. Вместо ручного формирования промптов — используете шаблоны с переменными.
Но LangChain имеет и обратную сторону. Абстракция скрывает детали, и когда что-то идёт не так — например, модель возвращает неожиданный формат — отладка усложняется. Опытные разработчики часто начинают с LangChain для прототипирования, а в production переходят на собственные реализации критических компонентов. Главное правило: не использовать абстракцию ради абстракции, а понимать, что происходит под капотом.
LangGraph: когда линейного пайплайна недостаточно
Простые RAG-системы работают линейно: запрос → поиск → генерация ответа. Но реальные задачи редко бывают линейными. Представьте процесс проверки документа на соответствие GDPR: нужно найти политики конфиденциальности, извлечь ключевые положения, сравнить с текстом закона, выявить несоответствия, сгенерировать рекомендации. Это многошаговый процесс с ветвлениями, циклами и условными переходами.
LangGraph расширяет LangChain, позволяя строить графы состояний (state machines). Каждый узел графа отвечает за конкретную задачу: поиск документов, извлечение информации, анализ соответствия, генерация отчёта. Рёбра определяют переходы между узлами на основе условий. Результат — система, которая может обрабатывать сложные бизнес-процессы, а не просто отвечать на вопросы.
Важное отличие LangGraph от обычного кода: состояние явно определено и передаётся между узлами. Это делает систему предсказуемой и тестируемой. Вы можете остановить выполнение на любом шаге, проверить состояние, внести изменения и продолжить — то, что в обычном коде требует сложной отладки, в LangGraph работает из коробки.
MCP: универсальный порт для агентов
Model Context Protocol (MCP), представленный Anthropic в ноябре 2024, решает проблему интеграции агентов с внешними системами. Раньше для каждой интеграции — будь то база данных, GitHub, CRM — приходилось писать отдельный адаптер. MCP заменяет это на единый протокол, похожий на USB для AI.
MCP-сервер объявляет доступные инструменты с их параметрами и типами возвращаемых значений. Когда агент сталкивается с запросом, который требует доступа к внешней системе — например, "какой статус у заказа 12345?" — он сам решает, какой инструмент вызвать, формирует правильные параметры и обрабатывает ответ. Разработчику не нужно вручную прописывать логику вызова API: агент делает это автономно.
Ключевое преимущество MCP — экосистема. Сообщество разработчиков создаёт MCP-серверы для популярных инструментов: GitHub, GitLab, SQL-базы, Slack, Notion. Вы подключаете готовый сервер к своему агенту, и он сразу получает доступ к функциональности. Это меняет экономику разработки AI-приложений: вместо написания интеграций с нуля вы комбинируете готовые компоненты, как LEGO.
Агенты: от инструментов к автономии
Агент — это LLM, наделённая тремя свойствами: автономией (способность самостоятельно принимать решения), памятью (сохранение контекста между взаимодействиями) и инструментами (доступ к внешним системам через MCP или прямой API). Если обычный чат-бот просто генерирует ответ на основе промпта, агент может решать многошаговые задачи: проанализировать запрос клиента, найти релевантную информацию в базе знаний, проверить статус в CRM, сгенерировать ответ и создать тикет в поддержку.
Разница между традиционным ПО и агентом принципиальна. Традиционная программа следует жёстко заданной логике: если X, то Y. Агент сам определяет, какие шаги нужны для достижения цели. Это делает агентов гибкими, но и менее предсказуемыми: один и тот же запрос может привести к разным последовательностям действий в зависимости от контекста.
В production агенты требуют тщательного контроля. Без ограничений агент может зациклиться, вызвать дорогой API сотни раз или принять решение, которое нарушает бизнес-правила. Поэтому реальные системы используют guardrails — лимиты на количество шагов, списки разрешённых инструментов, человеческое одобрение для критических операций. Автономия агента — это мечта, но контролируемая автономия — это реальность production.
Промпт-инжиниринг: искусство общения с моделью
Несмотря на растущую сложность стека, промпт-инжиниринг остаётся фундаментальным навыком. Качество промпта напрямую влияет на качество ответа — независимо от того, используете ли вы простой RAG или многоузловой граф LangGraph.
Современный промпт-инжиниринг вышел за рамки трюков вроде "think step by step". Сегодня это проектирование системных инструкций, которые определяют роль модели, ограничения, формат вывода и стратегию обработки ошибок. Chain-of-thought prompting заставляет модель рассуждать вслух перед тем, как дать ответ, что повышает точность на сложных задачах. Few-shot prompting показывает модели примеры желаемого поведения, что особенно эффективно для структурированных форматов вроде JSON.
Важный принцип: промпт — это не статический текст, а динамический шаблон. Он комбинирует системную инструкцию, контекст из RAG, историю разговора и текущий запрос пользователя. Каждый компонент вносит свой вклад в финальный результат, и оптимизация одного компонента может улучшить или ухудшить общее качество.
Как всё это собирается вместе
Представьте корпоративного AI-ассистента для поддержки клиентов. Пользователь спрашивает: "Какая у вас политика возврата для повреждённого товара?"
Агент получает запрос и передаёт его в LangGraph-граф. Первый узел извлекает эмбеддинг запроса и ищет в векторной базе (Chroma или Pinecone) релевантные документы — политики возврата, инструкции по обработке претензий, прецеденты. Второй узел формирует промпт, комбинируя системную инструкцию, найденные документы и историю разговора. Третий узел вызывает LLM через LangChain-абстракцию, которая позволяет менять провайдера без изменения кода. Четвёртый узел проверяет, не нужно ли запросить дополнительную информацию через MCP-сервер CRM — например, статус конкретного заказа. Если нужно — агент делает вызов, получает данные и генерирует финальный ответ.
Весь процесс занимает секунды, но за ним стоит целый стек технологий: эмбеддинги для семантического поиска, векторная база для хранения, LangChain для абстракции, LangGraph для оркестрации, MCP для интеграций, LLM для генерации. Понимание каждого компонента необходимо для отладки: если ответы нерелевантны, проблема может быть в chunking, в качестве эмбеддингов, в промпте или в логике графа.
Часто задаваемые вопросы
Нужен ли LangChain для production?
Не обязательно. LangChain ускоряет прототипирование, но в production многие команды переходят на собственные реализации критических компонентов ради контроля и производительности. Используйте LangChain как учебный инструмент и стартовую площадку, но не бойтесь выбрасывать абстракции, когда они мешают.
Можно ли обойтись без векторной базы?
Для небольших наборов данных (до нескольких сотен документов) можно использовать эмбеддинги в памяти или даже полнотекстовый поиск. Но как только масштаб превышает тысячи документов, векторная база становится необходимостью для производительности. Выбор конкретной базы зависит от вашей инфраструктуры и требований к latency.
В чём разница между агентом и обычным чат-ботом?
Чат-бот отвечает на вопросы на основе заданной логики или retrieved контекста. Агент самостоятельно определяет последовательность действий для достижения цели, использует инструменты и адаптируется к ситуации. Чат-бот — это интерфейс, агент — это автономная система, которая может действовать во внешнем мире.
Итог
Современный AI-стек — это не одна технология, а сложная экосистема взаимосвязанных компонентов. LLM обеспечивают языковое понимание, эмбеддинги превращают смысл в математику, векторные базы делают поиск масштабируемым, RAG подключает модели к реальным данным, LangChain абстрагирует провайдеров, LangGraph оркестрирует сложные процессы, MCP стандартизирует интеграции, а агенты объединяют всё это в автономные системы.
Понимание каждого слоя этой пирамиды необходимо для построения надёжных AI-приложений. Нельзя строить агентов, не понимая, как работают эмбеддинги. Нельзя оптимизировать RAG, не зная ограничений контекстного окна. Нельзя проектировать графы LangGraph, не представляя, как LLM обрабатывает промпты.
Если вы только начинаете — не гонитесь за последними фреймворками. Потратьте время на фундамент: разберитесь, как эмбеддинги превращают текст в векторы, почему контекстное окно ограничено, и как RAG решает проблему галлюцинаций. Это знание не устареет вместе со следующим релизом LangChain.