Архитектура ИИ-ассистента: LLM, память, инструменты, маршрутизация, наблюдаемость

«Как на самом деле создаются серьёзные ассистенты»

Содержимое страницы

Система AI-ассистента в продакшене — это не просто «LLM с промптом». Это система, которая принимает намерения пользователя, сохраняет состояние, решает, когда нужно извлечь данные или выполнить действие, и предоставляет достаточно деталей во время выполнения для отладки сбоев.

Такой системный взгляд на вещи рассматривается в кластере статей об AI-системах, когда ассистенты выходят за рамки однократного вызова модели.

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

Наиболее чистая архитектура разделяет ответственность на пять слоев: LLM, Память, Инструменты (Tooling), Маршрутизация (Routing) и Наблюдаемость (Observability). Такое разделение соответствует возможностям, предоставляемым API основных провайдеров, протоколу MCP, локальными средами выполнения, такими как vLLM и llama.cpp, а также реальными системами ассистентов, такими как OpenClaw и Hermes.

иллюстрация в светлых тонах многослойной архитектуры AI-ассистента с линиями потока данных, узлами памяти и серверами, без текста.

Память следует рассматривать не просто как «более длинный контекст». Системы извлечения (Retrieval) превращают внешние знания в явную непараметрическую память — то же пространство дизайна, которое подробно освещается в Retrieval-Augmented Generation (RAG) — и как руководства по контексту от Anthropic, так и статья «Lost in the Middle» предупреждают, что простое впихивание большего количества токенов в контекст не гарантирует надежного вспоминания.

Использование инструментов — это контрактная граница, а не магия. Вызов функций OpenAI, использование инструментов Anthropic и MCP полагаются на один и тот же паттерн: модель генерирует структурированный запрос, среда выполнения выполняет его, а результат попадает обратно в разговор. Если эта граница размыта, ассистент становится ненадежным.

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

Что такое система AI-ассистента

Практическое определение таково: система AI-ассистента — это среда выполнения, которая превращает намерения пользователя в ответ или действие, комбинируя интерфейс модели, сборку контекста, выполнение инструментов, управление состоянием и телеметрию. Именно поэтому полезные документы — это не просто карточки моделей. Полезные документы — это справочники API, контракты инструментов, руководства по извлечению данных, документы по маршрутизации и трассировке. Responses API от OpenAI предоставляет состояние взаимодействий, встроенные инструменты и вызов функций. Messages API от Anthropic предоставляет прямой доступ к сообщениям, а также Managed Agents. OpenClaw и Hermes идут на шаг дальше и показывают, что происходит, когда эти возможности выносятся за пределы постоянных шлюзов, каналов, сессий и памяти.

Другими словами, у системы ассистента более широкий контракт, чем у простого завершения чата. Хороший внутренний контракт выглядит примерно так:

AssistantRequest  = намерение пользователя + идентификатор + сессия + вложения + политика
AssistantResponse = ответ + действия + цитаты + изменения состояния + ID трассировки

Этот контракт важен, потому что каждое производственное несогласие в конечном итоге сводится к одному из этих вопросов: какой контекст был видим, какой инструмент был выполнен, какая модель ответила, какая память была прочитана или записана, и где трассировка показывает, что система потратила время. OpenTelemetry определяет трассировки как путь запроса через приложение, что является именно той абстракцией, которая нужна серьезным ассистентам. LangSmith и OpenLIT затем специализируют эту идею для LLM, инструментов, векторных хранилищ и рабочих процессов агентов.

Основные компоненты и интерфейсы

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

Слой	Основная ответственность	Типичный интерфейс	Примеры технологий
Слой LLM	Рассуждение, генерация, принятие решений, выпуск структурированных вызовов	Responses API, Messages API, endpoints совместимые с OpenAI или Anthropic	OpenAI, Anthropic, vLLM, llama.cpp, Ollama
Слой памяти	Хранение состояния сессии, долговременных заметок и поискового знания	эмбеддинги, векторный поиск, инструменты чтения/записи памяти, API извлечения	Эмбеддинги и векторные хранилища OpenAI, Pinecone, Weaviate, pgvector, Milvus, память Hermes, память OpenClaw
Слой инструментов	Чтение данных и выполнение действий вне модели	Инструменты на основе JSON-schema, инструменты MCP, поиск файлов и в вебе, нативные инструменты среды выполнения	Вызов функций OpenAI, использование инструментов Anthropic, MCP, инструменты LangChain, инструменты запросов LlamaIndex
Слой маршрутизации	Выбор модели, бэкенда, политики и пути для арендатора (tenant)	псевдонимы моделей, группы переключения при сбоях, проверки работоспособности, бюджеты, привязки каналов	LiteLLM, маршрутизация мультиагентов OpenClaw, разрешение провайдеров в среде выполнения Hermes
Слой наблюдаемости	Объяснение того, что произошло и почему	трассировки, спаны, логи, метрики, прогоны оценок (eval)	OpenTelemetry, LangSmith, OpenLIT

Таблица выше основана на официальных интерфейсах провайдеров, MCP, документации векторных баз данных и документации сред выполнения для vLLM, llama.cpp, OpenClaw и Hermes.

Слой LLM должен хорошо выполнять три вещи: потреблять текущий рабочий контекст, выпускать либо окончательный ответ, либо структурированный запрос на действие, и возвращать достаточно метаданных для поддержки повторных попыток и трассировки. Responses API от OpenAI явно разработан для состоятельных взаимодействий плюс встроенные инструменты и вызов функций. Messages API от Anthropic предоставляет тот же основной цикл через блоки tool_use и возвраты tool_result, в то время как Managed Agents дает вам размещенный каркас, если вы не хотите строить цикл самостоятельно. Локальные среды выполнения, такие как vLLM и llama.cpp, важны, потому что они сохраняют знакомые интерфейсы в стиле провайдеров, позволяя вам размещать инференс внутри собственной среды.

Слой памяти следует мысленно разделить на три категории: рабочая память, долговременная символьная память и поисковая семантическая память. Эмбеддинги OpenAI возвращают векторы, которые можно индексиовать и искать; Retrieval и File Search от OpenAI затем накладывают семантический и ключевой поиск поверх векторных хранилищ. Pinecone, Weaviate, pgvector и Milvus представляют четыре распространенные формы хранения: полностью управляемое, векторно-нативное с открытым исходным кодом, нативное для Postgres и распределенная векторная база данных. Hermes и OpenClaw добавляют полезное напоминание о том, что не вся память должна находиться в векторном хранилище: заметки на основе файлов, проверенные продвижения и снимки состояния сессии часто являются более честным дизайном. Системы памяти в AI-ассистентах отображает кросс-фреймворковую модель; Система памяти агента Hermes раскрывает ограниченную основную память и замороженные снимки сессии в одном продукте.

Слой инструментов — это место, где ассистент перестает быть суммаризатором и начинает быть программным обеспечением. Вызов функций OpenAI рассматривает инструменты как функциональность, определенную схемой, которую модель может решить вызвать. Anthropic говорит то же самое более явно: использование инструментов — это контракт между вашим приложением и моделью, и модель никогда не выполняет ничего самостоятельно. MCP обобщает этот контракт в протокол клиент-сервер, где хосты подключаются к одному или нескольким серверам, которые предоставляют инструменты, промпты и ресурсы — та же граница, описанная пошагово в Сервер MCP на Go. LangChain и LlamaIndex удобно помещаются здесь как библиотеки оркестровки: LangChain фокусируется на готовой архитектуре агента и интеграциях, в то время как LlamaIndex фокусируется на доступе к данным с дополнением контекста, движках запросов и рабочих процессах.

Слой маршрутизации существует потому, что «какая модель?» — это никогда не единственный вопрос. Вам также нужны «какой путь провайдера, какой арендатор, какой бюджет, какой класс задержки и какой резервный вариант?». LiteLLM полезен, потому что его официальная документация удивительно конкретна: взвешенный выбор, наименее загруженный, маршрутизация на основе задержки, на основе стоимости и ограниченные переключения при сбоях — все это первоклассные паттерны. OpenClaw расширяет маршрутизацию вверх до каналов и изоляции агентов, в то время как Hermes расширяет её вниз до слотов моделей для основных и вспомогательных задач, таких как суммаризация, сжатие контекста и маршрутизация инструментов MCP. Это правильная ментальная модель: маршрутизатор выбирает не просто модель, он выбирает полосу выполнения.

Слой наблюдаемости — это то, что предотвращает превращение архитектуры в фольклор. OpenTelemetry дает вам абстракцию трассировки. LangSmith дает вам сквозную видимость шагов приложения LLM и поддерживает облачные, гибридные и локальные формы развертывания. OpenLIT предоставляет вам наблюдаемость AI на базе OpenTelemetry с вариантами инструментации без кода и ручной, включая поддержку LLM, фреймворков агентов, векторных баз данных и GPU. Для производственных метрик, трассировок и паттернов SLO в инференсе и рабочих процессах агентов см. Наблюдаемость для систем LLM. Если у вашего ассистента нет трассировки на запрос, нет спана на вызов модели и нет истории событий для выполнения инструментов, у вас еще нет архитектуры. У вас есть «вайбы».

Захват, обогащение, ответ

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

sequenceDiagram participant U as User or Channel participant G as Gateway or UI participant R as Router participant M as Memory and Retrieval participant L as LLM participant T as Tools or MCP participant O as Observability U->>G: message, file, or command G->>O: start root trace G->>R: request + identity + session + policy R->>M: load session state and retrieve context M-->>R: notes, chunks, metadata R->>L: prompt + context + tool schemas L-->>R: answer or tool call alt tool call R->>T: execute tool or MCP action T-->>R: tool result R->>L: tool result + updated context L-->>R: final answer end R->>M: persist session changes and memory candidates R->>O: spans, metrics, eval events G-->>U: response

Шаг захвата обычно важнее, чем кажется. И OpenClaw, и Hermes помещают постоянный шлюз перед ассистентом, потому что входящий трафик — это не просто ввод текста. Он включает метаданные каналов, идентификаторы, авторизацию, границы сессий, прямые сообщения, группы, cron-тики и семантику доставки. Если вы пропустите этот слой и полагаетесь на абстракцию виджета чата, вы в конце концов все равно прикрутите его обратно как ad hoc промежуточное ПО.

Шаг обогащения — это место, где зрелые системы расходятся с демонстрационными примерами. Retrieval и File Search от OpenAI делают извлечение явным через векторные хранилища и вызовы поиска. LlamaIndex формализует тот же паттерн через коннекторы данных, индексы, движки запросов и рабочие процессы. Hermes идет дальше, разделяя парк моделей на основные и вспомогательные слоты, перекладывая такие задачи, как сжатие, суммаризация и маршрутизация, на более мелкие или специализированные модели. Это паттерн дизайна, который стоит украсть: не тратьте токены самой дорогой модели на рутину.

Шаг ответа — это не «генерация текста». Это «закрытие текущего цикла». Если модель может ответить напрямую, она делает это. Если ей нужен инструмент, она выпускает структурированный запрос. Контракт на использование инструментов от Anthropic и руководство по вызову функций от OpenAI делают это явным. Причина, по которой это важно с архитектурной точки зрения, заключается в том, что выходные данные теперь включают как язык, так и поток управления. Ваш объект ответа — это частично проза, частично план среды выполнения.

Шаг записи — это место, где проявляются семантики согласованности. Pinecone разделяет пути записи и чтения и обрабатывает записи после долговременного подтверждения. Память Hermes инжектируется как замороженный снимок на сессию, чтобы сохранить производительность префиксного кэширования, что означает, что новые записи не автоматически появляются в промпте текущей сессии. Система Dreaming в OpenClaw продвигает только проверенные, заземленные кандидаты в MEMORY.md, и это опция, а не всегда включенная функция. Практический урок заключается в том, что память редко бывает по-настоящему read-after-write (чтение после записи) во всех слоях. Вам нужно проектировать поэтапную видимость.

OpenClaw и Hermes как референсные системы

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

Архитектурная проблема	Маппинг OpenClaw	Маппинг Hermes
Входящий трафик и поверхности	Самостоятельный шлюз, соединяющий приложения чата и поверхности каналов	Единый фоновый шлюз сообщений, соединяющий множество внешних платформ
Оркестровка	Контрольная плоскость, ориентированная на шлюз, для каналов и AI-взаимодействий	Цикл `AIAgent`, обрабатывающий сборку промпта, выбор провайдера, диспетчирование инструментов, повторные попытки и переключение при сбоях
Маршрутизация	Маршрутизация мультиагентов связывает входящий трафик с изолированными агентами с отдельными рабочими пространствами и сессиями	Основные и вспомогательные слоты моделей разделяют основное рассуждение на сжатие, суммаризацию, одобрения и маршрутизацию MCP
Память	Память на основе файлов плюс необязательная активная память и фоновое продвижение Dreaming	`MEMORY.md` и `USER.md` инжектируются как замороженный снимок сессии, плюс внешние провайдеры памяти
Инструменты и расширения	Встроенные инструменты, инструменты сессии, плагины провайдеров, кастомные и локальные endpoints	40+ инструментов, встроенный клиент MCP, наборы инструментов, навыки и плагины провайдеров памяти

Это сопоставление основано на официальной документации и репозиториях OpenClaw и Hermes. OpenClaw документирует архитектуру шлюза, маршрутизацию мультиагентов, поддержку кастомных и локальных провайдеров, включая vLLM и Ollama, необязательную активную память и продвижение на основе Dreaming. Hermes документирует шлюз сообщений, центральный цикл AIAgent, основные и вспомогательные слоты моделей, встроенную память и нативную интеграцию MCP.

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

Практический гибридный стек, вдохновленный обеими системами, выглядит так:

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

Этот стек — это обоснованный паттерн развертывания, а не предписанная вендором схема. Он работает, потому что официальные интерфейсы согласуются: OpenAI и Anthropic предоставляют API, ориентированные на инструменты, vLLM и llama.cpp эмулируют endpoints в стиле провайдеров, Ollama обрабатывает локальные модели и эмбеддинги, MCP стандартизирует внешние инструменты, LiteLLM обрабатывает маршрутизацию и переключение при сбоях, а платформы, совместимые с OpenTelemetry, могут трассировать весь путь.

Паттерны, таблицы и компромиссы

Есть несколько повторяющихся паттернов ассистентов, которые стоит назвать. Управляемый ассистент держит большую часть среды выполнения внутри API провайдера. Ассистент, ориентированный на извлечение, рассматривает память и поиск как основное отличие. Ассистент, ориентированный на инструменты, ведет себя больше как оператор, чем как чат-бот. Шлюзовый ассистент приоритизирует постоянный доступ через поверхности сообщений. Специализированная сеть декомпозирует работу на нескольких агентов или маршруты. Официальная документация OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw и Hermes поддерживает версии этих паттернов, даже если они называют их по-разному.

Паттерн	На что оптимизирует	Лучший случай использования	Скрытая стоимость
Управляемый ассистент	Скорость доставки	Внутренние ко-пилоты и боты поддержки	Привязка к провайдеру и меньший контроль над деталями среды выполнения
Ассистент, ориентированный на извлечение	Заземленные ответы на основе собственных данных	Документация, поддержка, интеллектуальная работа	Качество извлечения становится реальным продуктом
Ассистент, ориентированный на инструменты	Действие вместо разговора	Операционные рабочие процессы, выборка данных, автоматизация	Побочные эффекты, повторные попытки и одобрения становятся ключевыми проблемами
Шлюзовый ассистент	Повсеместный доступ	Персональные и командные ассистенты поверх поверхностей чата	Сложность идентификации, сессий и безопасности
Специализированная сеть	Разделение труда	Сложные рабочие процессы с реальными границами ответственности	Более сложная отладка, оркестровка и дизайн оценок (eval)

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

Форма опции	Типичные компоненты	Сила	Слабость
Управляемая	OpenAI Responses или Anthropic Managed Agents, размещенный поиск файлов или векторные хранилища	Самый быстрый путь, меньше движущихся частей, размещенные инструменты	Наименьший контроль над путем данных и семантикой среды выполнения
Гибридная	API провайдера плюс локальная маршрутизация и векторное хранилище	Хороший баланс скорости и контроля	Больше контрактов для поддержки
Локальная (Self-hosted)	vLLM или llama.cpp или Ollama, MCP, локальная векторная БД, OTel	Сильная конфиденциальность и контроль развертывания	Наибольшая операционная нагрузка, накладные расходы на оборудование и настройку

Примечания к таблице: Размещенный File Search от OpenAI — это управляемый инструмент, Anthropic предлагает управляемый каркас, Pinecone — управляемая векторная служба, в то время как vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, самодостаточный LangSmith и OpenLIT все поддерживают самостоятельное управление или гибридную работу в различной степени.

Векторное хранилище	Форма	Почему команды выбирают его	На что обратить внимание
Pinecone	Управляемая векторная служба	Сильная операционная простота и масштабируемая управляемая архитектура	Внешняя зависимость и экономика управляемой службы
Weaviate	Векторная база данных с открытым исходным кодом	Векторные плюс инвертированные индексы и гибкий выбор индексов	Больше настройки кластера, чем путь только с размещением
pgvector	Расширение Postgres	Храните векторы с реляционными данными и существующим стеком SQL	Не лучший вариант для каждой высоконагруженной задачи ANN
Milvus	Распределенная векторная база данных	Специально созданная масштабируемость и экосистема вокруг управляемого Zilliz Cloud	Еще один специализированный хранилище данных для обслуживания

Примечания к таблице: Pinecone документирует управляемую контрольную плоскость и региональные плоскости данных. Weaviate документирует векторные и инвертированные индексы с несколькими типами векторных индексов. pgvector добавляет точный и приближенный поиск ближайших соседей в Postgres. Milvus позиционирует себя как высокопроизводительную, масштабируемую векторную базу данных с открытым исходным кодом, с Zilliz Cloud как управляемым вариантом.

Опция LLM	Стиль интерфейса	Лучшее в	На что обратить внимание
OpenAI Responses	Состоятельные ответы плюс встроенные инструменты	Быстрый старт, размещенные инструменты, структурированные циклы	Вы наследуете специфичные для платформы абстракции
Anthropic Messages	Прямой доступ к модели с явным контрактом на использование инструментов	Четкие границы инструментов и хороший контроль в кастомных циклах	Больше среды выполнения — ваша ответственность, если вы не используете Managed Agents
vLLM	Локальная подача, совместимая с OpenAI и Anthropic	Инференс с высокой пропускной способностью на собственном хосте	Реальная инфраструктура и работа по подаче моделей
Ollama	Простая локальная среда выполнения моделей и эмбеддингов	Локальная разработка и небольшие локальные стеки	Не тот же класс системы подачи, что настроенная распределенная среда выполнения
llama.cpp	Легковесный локальный сервер с маршрутами, совместимыми с провайдерами	Крайние случаи, CPU-first, ограниченные среды	Вам нужно больше ручной настройки и сопоставления возможностей

Примечания к таблице: OpenAI документирует Responses как свой расширенный интерфейс для состоятельных ответов и встроенных инструментов. Anthropic документирует API Messages и контракт на использование инструментов отдельно от Managed Agents. vLLM предоставляет сервер, совместимый с OpenAI, плюс поддержку API Messages Anthropic. Ollama документирует локальные рабочие процессы эмбеддингов и моделей. llama.cpp документирует чат, ответы и маршруты эмбеддингов, совместимые с OpenAI, а также чат-завершения, совместимые с Anthropic.

Ограничение или компромисс	Склонность к управляемым	Склонность к локальным (self-hosted)	Практическое смягчение
Задержка	Часто лучше первая итерация и меньше задач по локальной настройке	Может выиграть, когда модель и данные размещены вместе и сохраняются в тепле	Используйте уровни маршрутизации, горячие кэши и более мелкие вспомогательные модели
Стоимость	Легко начать, переменная при масштабировании токенов	Лучшая амортизация при стабильной утилизации	Измеряйте реальный трафик перед оптимизацией по интуиции
Конфиденциальность и резидентность	Проще для несекретных данных	Более сильный контроль для конфиденциальных и регулируемых потоков	Используйте гибридные границы и храните только то, что должно двигаться
Согласованность	Размещенные инструменты все еще имеют семантику поэтапной видимости	Локальные конвейеры памяти также ставят на паузу и продвигают данные	Явно определяйте правила read-after-write по слоям
Масштабирование	Меньше боли с контрольной плоскостью	Лучшая настройка для стабильных, специализированных рабочих нагрузок	Используйте батчинг, очереди и изолированных арендаторов
Отлаживаемость	Легко пропустить непрозрачные внутренние процессы провайдера	Легко утонуть в собственной сложности	Трассируйте каждый запрос и оценивайте каждый маршрут

Эта матрица компромиссов является архитектурным выводом из официальной документации, а не бенчмарком вендора. Строка согласованности важнее, чем многие блоги признают: Pinecone разделяет пути записи и чтения, Hermes замораживает память в промптах начала сессии, а OpenClaw продвигает долговременную память через поэтапный обзор. Это означает, что «память обновлена» и «память видна текущему ответу» часто являются разными истинами.

Режимы сбоя и смягчение

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

Где ломается	Типичный симптом	Обычная причина	Смягчение
Сборка промпта	Уверенный, но неточный ответ	Слишком много нерелевантного контекста, плохой порядок	Бюджетирование контекста, переутверждение (rerank), держите ключевые факты сверху
Извлечение	Правильный тон, неправильные факты	Плохое чанкирование, устаревший индекс, слабые фильтры	Оценивайте извлечение отдельно, добавляйте метаданные фильтры и гибридный поиск
Граница инструмента	Неправильное или дублирующее действие	Расплывчатые схемы, повторные попытки без идемпотентности	Тугие схемы, ключи идемпотентности, шлюзы одобрения
Маршрутизация	Дико不一致ное поведение по запросу	Маршрутизация по стоимости или задержке без контроля качества	Добавьте липкие сессии и оценки по маршрутам
Память	Устаревший или отравленный recall	Слишком жадные записи, слабый обзор, утечка между сессиями	Разделяйте рабочую и долговременную память, проверяйте продвижения
Наблюдаемость	Нет понятия, что произошло	Отсутствие трассировок или нет гранулярности спанов	Выпускайте корневые и подспаны для извлечения, модели и вызовов инструментов
Контроль галлюцинаций	Правдоподобные, но неподдерживаемые утверждения	Слабое заземление или отсутствие прохода валидации	Валидация по референсным документам, проверки самосогласованности, шлюзы оценок

База доказательств для этой таблицы широка, но последовательна. Документация инструментов Anthropic ясно показывает, что использование инструментов — это контрактная граница. Guardrails от OpenAI включает обнаружение галлюцинаций по референсной базе знаний через File Search. SelfCheckGPT показывает, что самосогласованность между выборками может помочь обнаружить неподдерживаемые утверждения. Результаты «Lost in the Middle» и руководство по контексту от Anthropic оба усиливают один и тот же операционный урок: больше токенов не устраняют необходимость в кураторстве контекста.

Предпочтительный стек смягчения может быть скучным и повторяющимся: трассируйте каждый запрос, версионируйте промпты, оценивайте извлечение независимо, держите инструменты идемпотентными и запускайте регрессионные оценки перед изменением маршрутов или политики памяти. Документация и репозиторий Evals от OpenAI прямо говорят, почему: без оценок трудно и затратно понять, как изменения модели или промпта влияют на ваш случай использования. Это applies так же к маршрутизаторам и извлечению, как и к промптам.

Дополнительное чтение

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

OpenAI: Обзор Responses, Вызов функций, Использование инструментов, Извлечение, Поиск файлов, Evals и MCP для удаленных серверов инструментов.
Anthropic: Обзор API, Использование инструментов, контракт на использование инструментов, Managed Agents, Контекстные окна и коннектор MCP.
Сам MCP: Обзор архитектуры и Спецификация стоит прочитать напрямую, потому что они четко объясняют хосты, клиенты, серверы, инструменты, промпты, ресурсы, транспорты и переговоры о возможностях.
Фреймворки и маршрутизация: Обзор LangChain, документы по дополнению контекста LlamaIndex, документы по маршрутизации LiteLLM, документы по наблюдаемости LangSmith.
Локальные среды выполнения и системы ассистентов: vLLM, сервер llama.cpp, эмбеддинги Ollama, документы и репозиторий OpenClaw, документы и репозиторий Hermes.
Хранение и наблюдаемость: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.
Исследовательские статьи: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle и SelfCheckGPT.