Часть 3. Финал: риски LLM-оркестрации в проде, польза LLM как ассистента, экономика и рост качества
1) Почему «LLM-оркестратор» в проде — риск
- Непредсказуемость и дрейф промптов. Один и тот же запрос может давать разные ответы из-за температуры, контекста и скрытых апдейтов модели. Для конвейера импорта это означает нестабильные маршруты и «случайные» DDL/касты.
- Галлюцинации и уверенная неправда. LLM может «уверенно» придумать схему таблицы или правила сопоставления там, где данных недостаточно. В результате — поломка загрузки, накладные расходы на откаты и репроцессинг.
- Невоспроизводимость. Решение, принятое вчера, сегодня может не воспроизвестись (новая версия модели, иной порядок сообщений). Без детерминированной опоры это превращается в «экзотику инженера», а не в промышленный процесс.
- Комплаенс/ПДн. Автоматическая маршрутизация через LLM рискует случайно «протолкнуть» PII в неподходящее хранилище или без маскирования — с последствиями для безопасности и аудита.
- Экономика. На «вспомогательные» задачи (определение разделителя, типов, маршрута) тратятся токены и цикл времени. Это не добавляет ценности, но накапливает счёт и задержки.
- Операционные риски. Подменять инженера black-box-агентом — это рост MTTR и падение доверия эксплуатации: непонятно, почему принято решение и как его быстро повторить/исправить.
Вывод: в критическом пути должен работать детерминизм — алгоритмы, правила, хэши, пороги, проверяемые эвристики и чёткие контракты. LLM — рядом, но не вместо.
2) Где LLM реально полезен (как ассистент)
- Документация и пояснения. Переводит «сухие» артефакты (сигнатура, выбор класса, DDL) в понятные краткие отчёты для инженера/архитектуры/менеджмента.
- Шаблонная разработка. Генерирует болванку DAG, DDL, конфигов, README; ускоряет рутину, где цена ошибки низкая, а ревью — простое.
- Диагностика и разбор инцидентов. По логам и артефактам объясняет, где «сломалось» сопоставление/загрузка, предлагает варианты фикса — но решение остаётся за инженером.
- Навигация по знаниям. Помогает искать похожие DatasetClass, сравнивать заголовки, находить дубликаты — как «умная лупа» поверх Онто.
- Контроль качества текста и UX. Причесывает сообщения об ошибках, делает инструкции яснее — снижает когнитивную нагрузку команды.
Золотое правило: алгоритмы принимают решения, LLM объясняет и ускоряет. Такой раздел ответственности и безопасен, и экономически оправдан.
3) Экономика: где мы выигрываем деньги и время
Состав TCO у «зоопарка» MVP: разрозненные скрипты, «одноразовые» пайплайны, много ручных перезапусков, разбор нестабильных решений LLM, рост нагрузки на инженеров поддержки.
Состав TCO у управляемого процесса:
- Один универсальный DAG (параметризуемый) вместо множества кастомных — меньше сопровождения.
- Переиспользуемые объекты Онто (DatasetClass/PipelineTemplate) — решение принимается один раз и живёт дальше; на новых источниках стоимость подключения падает.
- Storage-first и presigned — меньше сетевых «танцев» и откатов; сервер не проксирует гигабайты.
- LLM только там, где ускоряет — меньше «токенов на воздух».
Практический эффект: MVP за 3 дня одним экспертом, без «жёсткой» связки на капризную маршрутизацию LLM. Дальше масштабирование — это создание новых DatasetClass и правка шаблонов, а не переписывание конвейера.
4) Качество: как растёт предсказуемость и доверие
- Воспроизводимость. Каждая «проба» оставляет DatasetSignature, каждая развилка — RecognitionResult. Любое решение объяснимо и может быть повторено байт-в-байт.
- Управляемый онбординг источников. Новый файл → либо попадает в существующий DatasetClass, либо рождает draft, который инженер подтверждает. Человеческий контроль остаётся там, где он обязателен.
- Снижение инцидентов. Порог/джаккард/хэши защищают от «ложноположительных» совпадений; StorageConfig выставляет понятные рамки (куда и что кладём).
- Быстрые ревью и обучение команды. Шаблоны дают общий язык; отчёты читаемы и одинаковы для всех.
5) Операционная модель: как «встроить» это в прод
- Правила в устав: storage-first, без проксирования байтов, LLM-assistant only, один DAG — много параметров, всё фиксируем в Онто.
- Контракты и SLO. Контракт conf для DAG, SLO на шаги (проба, выбор, загрузка, импорт), понятные метрики (время полного прохода, % воспроизводимых маршрутов, доля auto-match vs draft).
- Процедуры ревью. Чётко: кто утверждает DatasetClass, кто правит PipelineTemplate, при каких условиях переводим из draft в active.
- Безопасность/ПДн. Маскирование в шаблоне, запрет загрузки без профиля PII, минимальные права на бакеты.
- Обратная связь в модель. Любой инцидент — обновление правил/шаблонов, чтобы повторно не наступать.
6) Финальная позиция
Мы сознательно выбрали алгоритмический путь и сделали LLM ассистентом, а не «дирижёром» производства. Это:
- снимает ключевые риски прод-оркестрации,
- снижает стоимость владения,
- ускоряет работу команды,
- повышает качество и доверие архитектуры/поддержки.
Живое знание как процессный движок — это не лозунг. Это практика: Онто хранит факты и правила, MCP исполняет маршрут, MinIO/Airflow/Postgres делают своё дело. Так мы получаем предсказуемый, бережливый и воспроизводимый импорт — ровно тот, который проходит согласование и реально работает в большой организации.