Моя позиция проста: ИТ должно делать процессы дешевле, надёжнее и понятнее — к этому я пришёл за почти 30 лет практики в разных ролях разработки ПО. Не наоборот. Когда в Онто мы начали системно собирать прикладные кейсы и практиковать «живое знание» — не статичный документ, а модель, которая помогает действовать здесь и сейчас — стало ясно, что следующий логичный шаг — показать это на реальной задаче импорта данных. Не очередной одноразовый MVP, а управляемый процесс, который выдержит разговор с архитекторами и поддержкой.
Письмо с приглашением на ЛЦТ я увидел 4 августа, заявку подал 5 сентября, а 8 сентября нас включили в буткемп. 22 сентября получил техническую задачу, 29 сентября сел за работу, 2 октября сдал решение. 15 октября организаторы опубликовали списки финалистов, 20 октября состоялась защита и питч. Этот ритм задал важный тон: вместо долгих «обмозгований» — короткий цикл гипотеза → проверка → результат.
Зачем вообще понадобился «ассистент цифрового дата-инженера»? Потому что ручные скрипты и разнородные пайплайны быстро превращаются в дорогой и хрупкий зоопарк. Каждая новая загрузка — это чуть-чуть другая «маленькая уникальная снежинка», а в сумме — рост TCO и операционных рисков. Нам нужна единая управляемая процедура импорта: понятные шаги, повторяемые решения, воспроизводимые артефакты. И главное — предсказуемость: маршрут файла выбирают не догадки модели, а прозрачные алгоритмы и правила.
Это важная позиция. «Чистая» нейросеть — соблазнительный ярлык, но в проде цена ошибки высока: неверная классификация датасета тянет за собой неправильную схему БД, поломанные загрузки, прямые потери. Поэтому в нашем подходе LLM — помощник и объяснитель, а не арбитр. Решение принимает детерминированная логика: хэши заголовка, устойчивые к перестановкам хэши, простые эвристики по заголовкам и PII-признакам, пороги уверенности. Это то, что можно ревьюить, версионировать и защищать на продкомитете.
Где здесь Онто? Онто становится «мозгом» процесса: мы сохраняем сигнатуры датасетов (нормализованный хедер, хэши, число колонок, базовые типы) и сопоставляем их с объектами класса датасета. Как только класс найден (или создан как черновик), у нас появляется устойчивый маршрут: какой шаблон пайплайна применить, куда сложить сырьё, какие правила использовать при загрузке. Это и есть «живое знание»: модель не описывает мир — она помогает действовать.
Остальная архитектура — исполнительный контур, минимальный и понятный. MCP выступает оркестратором шагов и «переводчиком» между моделью в Онто и инфраструктурой. MinIO — сырьевой слой (presigned-загрузка без проксирования через сервер). Airflow — один универсальный DAG для профилирования, генерации DDL и безопасной загрузки. Postgres — целевая база, где появляется таблица, пригодная для работы. Вместо множества разношёрстных скриптов — один проход, одна точка правды, один набор артефактов.
Ключевая гипотеза, которую мы подтвердили на практике: если сохранить сигнатуру в Онто, нужный пайплайн всегда находится и воспроизводится. Это и дешевле, и честнее, чем конструировать «мелкие MVP под каждый случай»: модель живёт дольше, чем конкретная реализация, и со временем только усиливается.
Команда была компактной, но собранной. Я взял на себя архитектуру, ТЗ, контроль разработки и DevOps и демо. Алёна собрала презентацию, Кристина вычитывала и следила за качеством. В роли «ускорителей» — ассистенты: ChatGPT-5 как бизнес- и системный аналитик, Codex-5 как бэкенд- и DevOps-разработчик и автор DAG, Qorder как тестировщик. Итог — «человек + инструменты» движутся быстрее и аккуратнее, если правило простое: алгоритмы принимают решения, LLM объясняет.
В следующей части — практический how-to: один проход от пробы до Postgres, набор инструментов, параметры запуска и минимальный DAG, с которым легко жить в проде. А в финале — выводы: почему такой процесс проходит у архитекторов и поддержки, и чем «разработка на данных в Онто» выигрывает у привычной гонки за одноразовыми MVP.