Embedding pipelines: почему пайплайны эмбеддингов — это новый ETL

Взгляд data engineering на ingestion, chunking и indexing

Я видел, как множество многообещающих AI-прототипов разваливались после запуска. И редко причина была в том, что модель была плохой. Чаще проблема начиналась гораздо раньше: команды относились к слою данных как к тому, что можно будет доделать позже.

Они неделями донастраивают промпты, тестируют модели и спорят о метриках оценки, а потом за выходные собирают retrieval pipeline и двигаются дальше. Сначала в демо всё выглядит отлично. Но через несколько месяцев система начинает выдавать устаревшие ответы; embeddings больше не совпадают с исходными документами, и никто толком не понимает, что изменилось.

То, что начиналось как впечатляющий прототип, постепенно становится трудно доверять в production. Команды, которым удается этого избежать, обычно рано понимают одну вещь: embedding pipelines по сути являются задачей data engineering, а не совершенно новой AI-дисциплиной. В основе по-прежнему лежит ETL (Extract, Load, Transform), только вместо data warehouse конечной точкой становятся embeddings и vector store.

Если смотреть на проблему именно так, многое становится яснее. Такие вещи, как versioning, data freshness, lineage и retries, перестают казаться «AI-специфичными». Это проблемы data infrastructure, которые мы уже много лет учимся решать.

Зачем нужны embedding pipelines?

Large language models — это выдающиеся рассуждающие системы, запертые в капсуле времени. Когда обучение заканчивается, знания модели оказываются зафиксированы. Она не знает, что ваша команда решила на прошлогоднем стратегическом ревью. Она не читала support ticket, пришедший этим утром. Она не может найти пункт, спрятанный на 47-й странице вашего master service agreement. Она умна, но слепа к тому, что относится именно к вашей организации.

Добавьте к этому жесткое ограничение context window — потолок на объем текста, который модель может обработать за один запрос, — и проблема становится очевидной: нельзя просто скормить ей всё, что у вас есть.

Ответом индустрии стало retrieval-augmented generation, или RAG. Вместо того чтобы запихивать всё в context window, вы строите retrieval layer, который в момент вопроса извлекает только самые релевантные фрагменты информации и передает их модели. Этот retrieval layer работает на vector database, а процесс, который наполняет его — берет сырые документы и превращает их в поисковые семантические представления, — это и есть embedding pipeline.

Embedding pipeline нужен каждой команде, которая строит внутреннего AI assistant, более умный enterprise search, автоматизированного customer support agent или document Q&A system. Вопрос не в том, строить ли его. Вопрос в том, строить ли его как прототип или как инфраструктуру.

Как работает embedding pipeline

У embedding pipeline три этапа: ingestion, chunking и indexing. Ниже я объясняю каждый из них и связываю с типичным процессом ETL.

Ingestion — это extraction

Это получение сырого контента — PDF, wiki-страниц, документов Word, записей базы данных, транскриптов — оттуда, где он хранится, и загрузка его в pipeline. Это почти дословно соответствует extract-стадии ETL.

Именно здесь команды чаще всего экономят на качестве, и именно здесь production-системы часто начинают ломаться. Документ обновляется, а pipeline этого не замечает. Файл удаляется, но его chunks остаются в index и спустя месяцы продолжают возвращать устаревшие ответы. И поскольку явной ошибки нет, никто не сигнализирует о проблеме.

Решение — Change Data Capture (CDC). Оно ведет manifest всех ingested documents, content hash и timestamp. На каждом запуске мы сравниваем источники с этим manifest, повторно загружаем то, что изменилось, удаляем то, чего больше нет, и относимся к документу так же, как к любой source table, которую синхронизируют инкрементально.

Chunking — это transformation

Когда документы уже попали в pipeline, embed их целиком нельзя. 30-страничный технический отчет слишком длинный, чтобы осмысленно представить его одним vector, а даже если бы это было возможно, возврат всего отчета в ответ на узкий вопрос завалил бы модель нерелевантным контекстом.

Chunking — это разбиение каждого документа на более мелкие части, достаточно сфокусированные, чтобы их можно было точно embed и точно retrieve. Это transform-стадия ETL, и она заслуживает такой же дисциплины проектирования.

Самая частая ошибка, которую я вижу, — считать размер chunk стандартной настройкой, а не продуктовым решением. Это не так. Правильный chunk size полностью зависит от характера вашего контента и характера запросов. Плотная техническая документация требует более мелкой гранулярности, чем набор FAQ. Юридический контракт с логикой на уровне clauses нужно обрабатывать иначе, чем серию onboarding emails. То, что работает для одного документа, будет прямо ухудшать качество retrieval на другом.

Я твердо считаю, что chunking configuration нужно рассматривать как versioned pipeline parameter, а не как hardcoded logic. Когда вы его меняете, а вы будете его менять, — нужно проводить re-chunking контролируемо и наблюдаемо, сравнивать качество retrieval до и после и откатываться, если оно ухудшается. Это обычная гигиена transform-слоя. Ничем не отличается от versioning правила очистки данных или field mapping.

Indexing — это load

На финальном этапе chunked text преобразуется в vectors и сохраняется в vector database, где его можно искать по semantic similarity, а не по совпадению ключевых слов.

В шаге преобразования embedding выполняется моделью, специально обученной переводить текст в плотные числовые представления, кодирующие смысл. Два фрагмента, выражающие одну и ту же идею разными словами, дадут vectors, которые будут располагаться близко в этом математическом пространстве. Два фрагмента о совершенно разных темах окажутся далеко друг от друга. Когда пользователь задает вопрос, система таким же способом embed-ит сам вопрос, находит ближайшие chunks и возвращает их как context для рассуждений модели.

Это действительно новая возможность. Но дисциплина вокруг indexing — не новая. Один принцип data engineering, к которому я постоянно возвращаюсь, — versioning.

В embedding pipelines каждый chunk в index должен быть помечен названием и версией embedding model, которая его сгенерировала, и это не обсуждается. Embedding models развиваются, а vectors, полученные разными версиями, нельзя надежно сравнивать. Нельзя безопасно искать по ним так, как будто они взаимозаменяемы.

Эта же проблема возникает, когда команды обновляют embedding model посреди pipeline без правильного плана migration. В одном index оказываются vectors разных поколений, и качество retrieval начинает деградировать так, что это трудно заметить. Система просто тихо начинает выдавать слегка неправильные ответы.

Я отношусь к обновлению embedding model так же, как к schema migration: планирую его явно, выполняю полностью и проверяю качество retrieval на репрезентативном наборе запросов. Ставки здесь такие же, как при любом breaking change в data model.

Pipeline observability не опциональна

Когда embedding pipeline работает в production, вопрос меняется с «запустился ли он» на «запустился ли он правильно». Это различие здесь важнее, чем во многих других pipeline, потому что сбои редко бывают громкими: index выглядит нормально, запросы возвращаются без ошибок, а система тихо подсовывает неверные ответы, пока кто-то не замечает, что AI перестал быть полезным.

Та же дисциплина observability, которая делает любой data pipeline надежным, здесь применяется напрямую. Когда вы начинаете воспринимать embedding pipelines как production systems, вы перестаете думать отдельными шагами и начинаете думать сигналами. Например, количество chunks на документ становится простым, но очень полезным health check: резкое падение обычно не связано с моделью, а указывает на сломанную ingestion-стадию или ошибки upstream parsing.

Вам также нужен «golden set» запросов с заранее известными правильными ответами. Он прогоняется после каждого изменения pipeline — примерно так же, как проверки качества данных после transformation. Так ловят regressions, которые не проявляются как явные сбои.

Кроме того, можно отслеживать lineage: какая версия embedding model породила какие chunks и когда каждый документ был в последний раз ingested. Это позволяет отследить проблемы retrieval до конкретных изменений, а не гадать.

И наконец, freshness становится сигналом первого класса. Если документы начинают устаревать сильнее допустимого порога, это должно всплывать в мониторинге задолго до того, как пользователи увидят ухудшение результатов.

Метрика, которая связывает всё это воедино, — качество retrieval во времени. Относитесь к ней как к любому другому pipeline SLA: измеряйте, отслеживайте и закрепляйте владельца.

Итог

Embedding pipelines действительно приносят много нового языка, новые инструменты и по-настоящему новую возможность на semantic layer. Но любопытно, что принципы, которые делают их надежными в production, совсем не новы.

У нас уже есть versioning, freshness, quality checks и monitoring. Это задачи, которые data engineering решает уже много лет.

Настоящая работа — взять эту же дисциплину и применить ее к pipeline, который просто выводит vectors вместо строк в таблице. Когда начинаешь смотреть на это так, хаос вокруг AI-систем становится гораздо проще понимать.

В этом и есть разница между красивым AI-демо и системой, на которую люди действительно могут положиться. Одно — прототип, а другое — инфраструктура.

Эта статья опубликована в рамках Foundry Expert Contributor Network.Хотите присоединиться?

Материал — перевод статьи с английского.

Оригинал: Embedding pipelines are the new ETL