Будни и праздники Data-инженера для прототипирования корпоративных AI-ассистентов

Есть профессия, которую на конференциях почти не упоминают, в вакансиях описывают тремя строчками, а на проекте без неё не запускается ничего. Это Data-инженер, который собирает прототипы корпоративных AI-ассистентов. Он живёт на стыке: готовит данные для LLM, собирает контекст для RAG, тестирует поиск, ловит галлюцинации и превращает сырой корпоративный хаос в работающего ассистента. Разберём, из чего состоят его будни и что в них считается праздником.

Кто это и почему роль появилась именно сейчас

Классический Data-инженер строит пайплайны: забирает данные из источников, чистит, складывает в хранилище, обеспечивает доступ аналитикам и ML-командам. Работа понятная, инструменты устоявшиеся, метрики ясные. AI-ассистенты сломали эту картину, потому что потребовали другого отношения к данным.

Для LLM важна не столько структура хранения, сколько качество контекста. Для RAG критично, как нарезаны документы, как построен поиск, как сопоставляются сущности. Для оценки качества нужно посчитать точность и понять, где именно система ошибается: не нашла нужный документ, нашла, но не использовала, использовала, но исказила. Всё это — новая работа, которая плохо вписывается в классические DE-обязанности.

Так и появилась роль на стыке. Она требует инженерных навыков и понимания, как работает LLM, как она ошибается, как её проверять. Сочетание редкое, поэтому специалистов мало, а спрос растёт быстрее, чем рынок успевает готовить людей.

Что реально входит в работу

Начнём с данных. Ассистенту нужны источники — API внутренних систем, базы данных, файлы, вики, тикеты поддержки, переписка. Каждый источник — это отдельная история со своими форматами, правами доступа, частотой обновления. Data-инженер собирает всё это в единый слой, пригодный для использования моделью.

Классический ETL здесь работает лишь отчасти. Данные нужно доставить и подготовить к семантическому поиску: разбить документы на фрагменты, сохранить связи между ними, обогатить метаданными, обеспечить актуальность. Ошибка на этом этапе не проявляется сразу — она всплывёт через недели, когда ассистент начнёт уверенно отвечать устаревшей информацией.

Дальше — контекст для RAG. Это отдельная дисциплина. Нужно понять, как нарезать документы, чтобы фрагменты были осмысленными и самодостаточными. Как строить индекс, чтобы поиск находил релевантное. Как сопоставлять сущности — чтобы «Иван Петров», «И. Петров» и «ivan.petrov@company.ru» были одним человеком. Ошибки здесь стоят дорого: ассистент либо не находит нужное, либо находит не то.

Потом — оценка качества. Галлюцинации — это конкретные случаи, которые надо ловить и классифицировать. Где именно модель ошибается: в поиске, в рассуждении, в форматировании ответа? Чтобы это понять, нужны данные и инструменты. Golden dataset — набор эталонных вопросов и правильных ответов. Автоматизированные прогоны — массовые тесты, которые показывают, стало лучше или хуже. Метрики retrieval и hallucinations — цифры, по которым видно динамику.

И наконец — прототип. Собранный, работающий, протестированный. Готовый к передаче в продакшен-команду, которая возьмёт его и доведёт до клиента.

Будни: как это выглядит на практике

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

Дальше — правки. Пересборка индекса, повторный прогон, сравнение метрик. Иногда помогает, иногда нет. Тогда проверяем гипотезу с поиском: может, эмбеддинги не различают нужные сущности, потому что в корпусе есть похожие документы. Или проблема в промпте: модель получила правильный контекст, но не использовала его.

К обеду приходит заказчик с новым требованием: ассистент должен отвечать не только по документам, но и по данным из CRM. Значит, надо добавить источник, продумать, как связать его с остальными, обновить golden dataset. Работа на несколько дней.

После обеда — встреча с продуктовой командой. Обсуждаем метрики: что считаем успехом, какие пороги приемлемы, как измеряем. Спорят все, потому что метрики в AI — тема скользкая. Точность 85% звучит хорошо, но если оставшиеся 15% — это критические ошибки в финансовых вопросах, цифра перестаёт радовать.

Вечер уходит на прогон тестов. Массовый прогон ста вопросов, автоматическая оценка, разбор провалов. К концу дня — отчёт: где стало лучше, где хуже, какие гипотезы подтвердились. И список задач на завтра.

Праздники: что считается удачей

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

Ещё один праздник — когда удаётся локализовать сложный баг. Не «ассистент иногда врёт», а «ассистент ошибается, когда вопрос содержит отрицание и два сущностных имени». Такая локализация — половина решения.

И третий — когда прототип уходит в продакшен и продакшен-команда не возвращает его через неделю с вопросами «а как это работает». Значит, handoff состоялся, документация полная, тесты воспроизводимые. Редкое и приятное чувство.

Почему это сложнее, чем кажется

Классический DE-проект можно разбить на этапы и распараллелить. AI-прототип так не разбивается, потому что всё связано. Изменил чанкинг — поменялись результаты поиска. Поменял поиск — поменялись ответы. Поменял промпт — поменялась оценка. Это система с плотными связями, и любое изменение требует повторной проверки.

Добавляется и неопределённость. В классическом DE понятно, что такое «правильный результат»: цифра сошлась, отчёт построился. В AI «правильный ответ» — понятие размытое. Два специалиста могут по-разному оценить один и тот же ответ. Поэтому так важны golden dataset и чёткие критерии: без них оценка превращается в вежливые мнения.

И третье — постоянное обучение. Инструменты меняются каждые несколько месяцев. То, что работало полгода назад, сегодня устарело. Приходится читать, пробовать, перепроверять. Это режим работы, а не разовая инвестиция.

Колонка автора

Кульминация: почему роль будет расти

В сухом остатке Data-инженер для AI-прототипов — это роль, которая появилась потому, что без неё AI-проекты не работают. Модель — только часть системы. Всё остальное — данные, контекст, оценка, тесты, метрики — вот где делается качество.

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

Всё в наших силах. Но только если мы честно признаём: в AI-ассистентах победа достаётся тому, у кого лучше подготовлены данные и выстроен контекст.

Глоссарий терминов

• Data-инженер (DE) — специалист, который собирает, обрабатывает и хранит данные для аналитики и ML-систем.
• AI-ассистент — система на основе LLM, отвечающая на вопросы пользователей и выполняющая задачи в рамках заданной предметной области.
• Прототип — ранняя версия системы для проверки идеи. Не предназначена для реальных пользователей без доработки.
• Production (прод) — рабочая среда, где система используется реальными пользователями.
• RAG (Retrieval-Augmented Generation) — подход, при котором модель отвечает, опираясь на найденные внешние документы.
• Контекст для LLM — набор данных и инструкций, который подаётся модели вместе с вопросом.
• LLM (Large Language Model) — большая языковая модель, основа генеративных AI-систем.
• Галлюцинация — уверенный, но неверный ответ модели, не опирающийся на данные.
• Чанкинг — разбиение документов на фрагменты для индексации и поиска.
• Эмбеддинг — числовое представление текста, позволяющее сравнивать смысловую близость.
• Семантический поиск — поиск по смыслу, а не по точному совпадению слов.
• Индекс — структура, ускоряющая поиск по документам.
• Сопоставление сущностей (entity resolution) — приведение разных вариантов одного объекта к единому виду.
• Golden dataset — набор эталонных вопросов и правильных ответов для оценки качества ассистента.
• Автоматизированный прогон — массовый запуск сценариев с автоматической оценкой результатов.
• Retrieval — этап поиска релевантных документов для ответа.
• Hallucinations — метрика, отражающая долю ответов с выдуманными данными.
• Метрика качества — измеримый показатель работы системы: точность, полнота, задержка, стоимость.
• Пайплайн — автоматизированная цепочка обработки данных.
• API — программный интерфейс для взаимодействия между системами.
• ETL — извлечение, преобразование и загрузка данных из источников в хранилище.
• Промпт — инструкция для модели, определяющая, как она должна отвечать.
• Локализация ошибки — поиск конкретной причины сбоя, а не общего «система работает плохо».
• Handoff — передача прототипа и документации в продакшен-команду.