Глава 11 — Непрерывные обновления и оптимизация пайплайна

Одиннадцатый и заключительный пост поглавного разбора LLM Primer III: Enhancing Enterprise AI with RAG. О том, как пайплайн никогда не закончен — документы меняются, запросы дрейфуют, модели подменяют — и как команда, владеющая им, учится думать в трёх временных шкалах сразу.

Почему существует эта глава

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

11.1 Change Data Capture и инкрементальная индексация

Первый инстинкт каждой команды, выкатившей RAG-систему, — поставить ночную пересборку индекса. Работает. И в долгую неверно. Ночная пересборка жжёт вызовы эмбеддингов на документах, которые не менялись, оставляет индекс устаревшим до суток и перестаёт укладываться в ночное окно по мере роста корпуса. Зрелый паттерн — инкрементальная индексация, ведомая Change Data Capture: пайплайн реагирует на события из источников, а не опрашивает.

Важны три вида событий. Insert: новый документ — распарсить, разрезать, заэмбедить, индексировать. Update: существующий документ изменился — переэмбедить затронутые чанки. Delete: документ удалён — выселить соответствующие векторы прежде, чем они смогут вернуться в результатах — жёсткое требование под GDPR, CCPA и прочие. Механизм, делающий это управляемым, — хэш контента. На первом ингесте сохраните SHA-256 от нормализованного текста чанка рядом с эмбеддингом. На апдейте: пере-разрежьте, посчитайте хэш, сравните: неизменённые чанки остаются, новые эмбеддятся, старые уходят. Правка абзаца становится одним вызовом эмбеддинга, а не тысячей. Счёт за эмбеддинги масштабируется с редакторской активностью, а не с размером корпуса.

Тяжелее — порядок и согласованность. События приходят не по порядку; delete способен обогнать update, который должен был ему предшествовать. Стандартное лекарство — монотонные версии на документ с условными записями: применять событие, только если его версия превышает версию в файле. Это делает пайплайн идемпотентным — дубликат события не способен испортить индекс — что не оптимизация, а требование корректности на масштабе. Контексты с комплаенсом добавляют tombstones: логическое удаление, вступающее в силу во время запроса до того, как физическое удаление завершится асинхронно, чтобы удаление учитывалось немедленно.

11.2 Управление латентностью: семантическое кеширование и тиринг моделей

Retrieval-augmented вызов накапливает латентность на каждом прыжке. Защита — делать меньше работы, когда работа доказуемо излишня, и два приёма несут большую часть этого веса. Обычный кеш хранит ответы по точному тексту запроса и попадает в ничтожную долю реального трафика. Семантическое кеширование ключует по смыслу: эмбеддить каждый входящий запрос, искать в малом кеше недавних, вернуть кешированный ответ, если косинусное сходство ближайшей записи превышает порог. «Какая у нас политика возврата?» и «как работают возвраты?» не делят ни одного строкового совпадения, но делят весь ответ.

Три важных выбора: порог сходства (0,93–0,97 косинус для общих эмбеддингов, настраивается против отложенного трафика), TTL (идеально привязан к чанкам-донорам — инвалидировать, когда любой из них переэмбежен) и область (партиционировать по тенанту, по роли доступа, по чему угодно, что могло бы утечь от одного пользователя к другому). Продакшен-развёртывания сообщают о попаданиях 30–60%, с десятками миллисекунд на попаданиях против многосекундных нескешированных ответов, с пропорциональной экономией стоимости, поскольку попадание пропускает и эмбеддинг, и генерацию.

Тиринг моделей обрабатывает запросы, которые должны использовать модель и не должны брать самую большую из доступных. Два-три тира: маленькая быстрая дешёвая модель для основной массы, более крупная для запросов, в которых маленькая не уверена, опционально третья для длинного хвоста. Роутер — то место, где продакшен-развёртывания ошибаются на первом проходе. Простейшая версия использует сигналы со стороны запроса (короткий факт против аналитического). Лучшая использует сигналы со стороны поиска (высокое стабильное сходство значит, что маленькой модели достаточно). Самая изощрённая гоняет маленькую первой и эскалирует на калиброванной уверенности — точна на пограничных кейсах, платит дополнительной инференцией на эскалациях. Числа, за которыми следить, — escalation rate и regret rate вместе; любое одно само по себе сбивает.

11.3 Непрерывная петля обратной связи

RAG-пайплайн излучает постоянную телеметрию. Большинство команд её собирает; очень мало кто замыкает петлю. Петля имеет четыре стадии. Собрать: каждый запрос, поиск, генерация, цитата и взаимодействие пользователя залогированы со стабильной схемой и стабильным идентификатором запроса, нитью проходящим через каждую стадию — без него диагностика регрессии скатывается к угадыванию. Оценить: Триада из Глав 9 и 10 гонится в двух режимах — сэмплированно офлайн против эталонного набора ради точности, и онлайн-поведенческие прокси (regenerate, copy, follow-up, abandonment) ради покрытия. Ни один из них не достаточен сам по себе. Вместе они триангулируют.

Решить — самая сложная стадия, потому что один и тот же сигнал подразумевает несколько разных лекарств. Падение Context Relevance может значить, что в корпусе не хватает тем, или что reranker деградировал, или что модель эмбеддингов больше не подходит к новой лексике. Различение требует резать метрики — по теме, по возрасту документа, по версии эмбеддингов, по тенанту, — и команда, смотрящая только на агрегат, обнаружит на квартал позже, что один срез всё это время тянул среднее вниз.

Применить бывает трёх весов. Изменения конфигурации — top-k, веса reranker, hybrid alpha, порог кеша, правило эскалации — A/B-тестируются за часы, откатываются за минуты, несколько идут параллельно. Действия реиндексации — переэмбедить устаревшую тему, ингестить новый источник, выселить устаревшие документы — еженедельно или по требованию, на непродакшен-реплике до промоушна. Изменения моделей — поменять модель эмбеддингов, поменять базовую модель, переобучить кастомный reranker — поквартально, с shadow-развёртыванием, параллельной оценкой, постепенным сдвигом трафика и опцией отката. Дисциплина в каденции, а не в одном изменении. Маленький человеческий канал разметки — может быть, сотня примеров в неделю из очереди двусмысленных проксей — держит LLM-судей откалиброванными и не даёт петле оптимизироваться против собственных проксей.

Что подготавливает Том III

Мы начали, рассматривая retrieval-augmented generation как инженерный ответ на две проблемы, которые чистые языковые модели решить не могут: свежее знание и проверяемый провенанс. Мы прошли по архитектуре от раннего паттерна embed-retrieve-stuff к модульным и агентным системам в продакшене и сделали аккуратную работу по каждому компоненту по пути — парсерам, восстанавливающим структуру из PDF, чанкерам, решающим, что такое единица смысла, векторным базам, хранящим результат, гибридным ретриверам и rerank'ерам, находящим важное, контролю доступа и анонимизации, удерживающим систему честной, фреймворкам оценки, говорящим, работает ли всё это, и теперь — механизмам непрерывных обновлений, держащим её живой.

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

Серия продолжается в LLM Primer IV — Designing AI Cognition with MCP. Если Том III был о том, чтобы принести модели правильное знание, то Том IV — о том, чтобы принести правильные руки: Model Context Protocol, агенты, которые им владеют, инструменты, которые они вызывают, и память, которую они накапливают. Та же архитектурная чувствительность, другая сторона той же задачи. Работа продолжается.