5% ИИ, 100% инженерии: почему агенты зависят от инфраструктуры
Что такое doc-to-chat pipeline
Doc-to-chat pipeline принимает корпоративные документы, нормализует и стандартизирует их, накладывает требования управления, индексирует эмбеддинги рядом со структурными фичами и предоставляет поиск + генерацию через аутентифицированные API с контрольными точками human-in-the-loop (HITL). Это практическая архитектура для агентных Q&A, копилотов и автоматизации рабочих процессов, где ответы должны соблюдать права доступа и быть готовыми к аудиту.
На production это обычно RAG (retrieval-augmented generation), усиленный guardrails, политиками и трассировкой на базе OpenTelemetry для воспроизводимости.
Как интегрироваться в существующий стек
Используйте стандартные сервисные границы (REST/JSON, gRPC) и хранилище, которому доверяет организация. Для табличных данных Iceberg дает ACID, эволюцию схем и партиций, и снапшоты—это важно для повторяемых извлечений и бэкофов. Для векторов выбирайте стратегию, совместимую с SQL-фильтрами:
- pgvector размещает эмбеддинги вместе с бизнес-ключами и ACL-тегами в PostgreSQL, что позволяет точные джойны и применение политик в одном запросе.
- Специализированные движки вроде Milvus обеспечивают высокую QPS и горизонтальную масштабируемость с раздельным хранением и вычислением.
Во многих командах используют оба подхода: SQL+pgvector для транзакционных джойнов и политик, Milvus для интенсивного retrieval.
Основные компоненты и их свойства
- Таблицы Iceberg: ACID, скрытое партиционирование, изоляция снапшотов, поддержка у вендоров.
- pgvector: SQL + векторное сходство в одном плане для точных джойнов и контроля доступа.
- Milvus: слоистая, горизонтально масштабируемая архитектура для поиска по сходству.
Координация агентов, людей и рабочих процессов
Production-агенты требуют явных точек координации, где люди одобряют, правят или эскалируют результаты. AWS A2I предоставляет управляемые HITL-петли (private workforces, flow definitions) и служит реальным примером для гейтинга низко-уверенных выводов.
Фреймворки вроде LangGraph моделируют эти проверки как шаги в графе агента, чтобы одобрения были первоклассными узлами DAG, а не ad hoc callback’ами. Используйте такие ворота для публикации сводок, создания тикетов или коммитов кода. Сохраняйте все артефакты (промпты, наборы извлечений, решения) для аудита и повторных прогонов.
Схема: LLM → проверки уверенности/guardrails → HITL-ворота → побочные эффекты.
Надежность до модели
Надежность — это многослойная защита:
- Языковые и контентные guardrails: предвалидация входа/выхода на безопасность и соответствие политике (например, Bedrock Guardrails или OSS NeMo Guardrails, Guardrails AI, Llama Guard).
- Обнаружение/редакция PII: анализируйте и исходники, и ввод/вывод модели; Microsoft Presidio распознает и маскирует PII, но его стоит комбинировать с дополнительными контролями.
- Контроль доступа и линия данных: применяйте row-/column-level ACL и аудит через каталоги (Unity Catalog), чтобы retrieval уважал права; унифицируйте lineage и политики доступа между рабочими пространствами.
- Качество retrieval: оценивайте RAG метриками без эталона (faithfulness, context precision/recall) и блокируйте или понижайте плохие контексты.
Большинство инцидентов — не регрессии модели, а проблемы данных, прав доступа, деградация retrieval или отсутствие телеметрии.
Масштабирование индексации и поиска
Два направления важны: throughput при ingest и конкурентность запросов.
- Ingest: нормализуйте на краю lakehouse и пишите в Iceberg для версионированных снапшотов; эмбеддинг выполняйте асинхронно для детерминированных пересборок и реиндексаций по точке времени.
- Vector serving: архитектура Milvus с shared-storage и дисагрегированным compute поддерживает горизонтальное масштабирование; используйте гибриды HNSW/IVF/Flat и replica set’ы для баланса recall/латентности.
- SQL + vector: держите бизнес-джойны на сервере (pgvector), например WHERE tenant_id = ? AND acl_tag @> … ORDER BY embedding <-> :q LIMIT k, чтобы избежать N+1 и соблюдать политики.
- Chunking/embedding: настраивайте размер чанка, overlap и семантические границы; плохой чанкинг тихо убивает recall.
Для смешанных данных (структурированные + неструктурированные) предпочитайте гибридный retrieval (BM25 + ANN + reranker) и храните структурные признаки рядом с векторами для фильтров и реранкинга.
Наблюдаемость выше логов
Связывайте трассы, метрики и оценки:
- Распределенная трассировка: эмитируйте OpenTelemetry-спаны через инжест, retrieval, вызовы моделей и инструменты; LangSmith нативно принимает OTEL и интегрируется с APM (Jaeger, Datadog, Elastic) для полного тайминга, промптов и стоимости запросов.
- Платформы LLM-observability: сравнивайте LangSmith, Arize Phoenix, LangFuse, Datadog по возможностям трассировки, evals и учету затрат.
- Непрерывная оценка: планируйте RAG-evals на canary-наборах и воспроизведениях live-трафика; отслеживайте faithfulness и дрейф grounding со временем.
Добавляйте профилирование схем/маппинг на этапе ingest, чтобы observability оставалась связанной с изменениями формы данных и объясняла регрессии retrieval при смене upstream-источников.
Пример референс-флоу
Ingest: connectors → text extraction → normalization → Iceberg write (ACID, snapshots). Govern: PII scan (Presidio) → redact/mask → catalog registration with ACL policies. Index: embedding jobs → pgvector (policy-aware joins) and Milvus (high-QPS ANN). Serve: REST/gRPC → hybrid retrieval → guardrails → LLM → tool use. HITL: low-confidence paths route to A2I/LangGraph approval steps. Observe: OTEL traces to LangSmith/APM + scheduled RAG evaluations.
Почему ‘5% ИИ, 100% инженерии’
Ключ к надежным, безопасным и правдоподобным агентам — не выбор модели, а инженерные контролы: ACID-таблицы, каталоги ACL, PII-guardrails, гибридный retrieval, телеметрия и человеческие ворота. Эти механизмы определяют, будет ли выбранная модель безопасной, быстрой и заслуживающей доверия. Меняйте модель позже, но сначала вкладывайтесь в инфраструктуру и процессы.