Compound AI Systems

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

Как работают составные системы ИИ#

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

Управление может быть детерминированным, когда обычный код вызывает компоненты в фиксированной последовательности, или динамическим, когда слой AI agent orchestration выбирает инструменты и маршруты во время выполнения. AI orchestration координирует зависимости, повторные попытки, ресурсы и поток данных в приложении.

Распространенные шаблоны включают в себя retrieval-augmented generation, где поиск предоставляет контекст языковой модели, и конвейеры слияния датчиков, которые объединяют камеры, радар или другие входные данные. Более широкий переход от изолированных моделей к интегрированным системам описан в обзоре Berkeley AI Research overview of compound AI systems. (bair.berkeley.edu)

Почему составные системы имеют значение#

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

Эти преимущества влекут за собой компромиссы на уровне системы:

• Распространение сбоев: Неверное обнаружение, неудачный поиск или недоступный API могут повлиять на каждое последующее решение.
• Задержка и стоимость: Каждый вызов модели, сетевой запрос и этап проверки расходуют часть общего бюджета времени отклика.
• Дрейф интерфейсов: Обновление одной службы может изменить ее формат вывода или предположения и незаметно нарушить работу другого компонента.
• Сложная оценка: Сильный компонент не гарантирует сильный результат от начала до конца.

Следовательно, machine learning operations должны охватывать весь рабочий процесс. Руководство по наблюдаемости OpenTelemetry observability guidance объясняет, как трассировки, метрики и логи показывают, что произошло в распределенных службах, в то время как отслеживание экспериментов MLflow experiment tracking может записывать конфигурации моделей и результаты оценки. (opentelemetry.io)

Связанные концепции и ключевые различия#

Составная система ИИ — это не просто другое название сложной модели.

Ансамбль моделей model ensemble объединяет предсказания от нескольких моделей, часто с помощью голосования, усреднения или стекинга. Ансамбль может быть одним компонентом внутри составной системы, но в нем обычно отсутствуют базы данных, инструменты, логика рабочих процессов и операционные службы.

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

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

Реальные приложения#

• Manufacturing visual inspection: Камера захватывает продукты, модель Ultralytics YOLO26 model обнаруживает дефекты, логика на основе правил проверяет серьезность и местоположение, а производственная система отклоняет или одобряет каждый элемент. Неопределенные случаи могут быть направлены инспектору-человеку, в то время как сохраненные изображения поддерживают последующее переобучение.

• Traffic and parking analytics: Обнаружение идентифицирует транспортные средства, multi-object tracking поддерживает идентификаторы между кадрами, геометрическая логика определяет занятость полосы или зоны парковки, а панели мониторинга агрегируют счетчики и оповещения. Ошибки могут вызывать дублирование подсчетов, пропущенные события заторов или неверные оценки доступности, поэтому каждый этап необходимо тестировать вместе.

Следующий упрощенный пример показывает восприятие, питающее детерминированную логику принятия решений:

from ultralytics import YOLO

# Perception component
model = YOLO("yolo26n.pt")
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]

# Policy component
person_class = next(i for i, name in result.names.items() if name == "person")
person_count = int((result.boxes.cls == person_class).sum())
decision = "review" if person_count >= 4 else "continue"

print({"people_detected": person_count, "next_step": decision})
result.save(filename="compound_system_input.jpg")

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

Практические рекомендации по проектированию#

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

Используйте трассировки для отслеживания отдельных запросов, установите бюджеты задержки и стоимости, а также предоставьте повторные попытки или безопасные резервные варианты для недоступных служб. Проверки работоспособности Kubernetes health probes иллюстрируют, как развернутые службы могут предоставлять сигналы готовности и жизни.

Средства контроля рисков должны охватывать всю систему целиком, включая доступ к данным, внешние инструменты, ручное переопределение и последующие последствия. Структура управления рисками NIST AI Risk Management Framework предоставляет рекомендации, ориентированные на жизненный цикл, для управления, измерения и контроля этих рисков. Команды могут использовать Ultralytics Platform для подключения разметки наборов данных, обучения, развертывания и мониторинга в продакшене для компонентов зрения в рамках более широкого составного приложения. (nist.gov)