Бюджеты на обновление RAG для документации, политик и тикетов

Почему одна схема обновления не работает

Один таймер обновления выглядит аккуратно, но в реальной RAG-системе он быстро ломается. Разные источники устаревают с разной скоростью.

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

Если обновлять всё каждый час, вы просто тратите деньги на контент, который почти не изменился. Система продолжает разбирать, делить на фрагменты, создавать embeddings и индексировать одни и те же страницы с политиками, инструкции по настройке и архивные заметки. Работа повторяется, хотя полезного нового ничего не появилось.

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

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

Такой разрыв доверие разрушает быстрее, чем ожидает большинство команд. Люди могут простить пропущенную деталь в длинной справочной статье. Но они не простят ответ, который игнорирует свежую заметку об инциденте, правило возврата или статус бага.

Представьте, что клиент спрашивает, почему не проходит оплата. В документации описан обычный сценарий. Страница с политиками тоже выглядит нормально. А свежие тикеты уже показывают проблему у платёжного провайдера и временное решение. Если все три источника обновляются раз в день, ассистент упускает единственный свежий факт, который действительно важен.

Один общий таймер создаёт сразу две проблемы: лишние расходы на медленно меняющийся контент и устаревшие ответы на быстро меняющемся. Команды платят больше, а база знаний всё равно уходит в отрыв от реальности.

Разделите источники по скорости изменений

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

Начните с того, что люди действительно правят. Продуктовая документация часто меняется, когда команда выпускает новый функционал или переписывает существующий. Политики обычно двигаются медленнее, потому что их перед публикацией проверяют legal, security или HR. Тикеты поддержки меняются быстро, но большая часть этого движения — шум. Новый тикет может быть важен для поиска уже сегодня. Закрытый тикет полугодовой давности, возможно, больше никогда не понадобится.

Для первого практичного распределения подойдёт такой вариант:

• Медленные: политики, архивная документация, старые заметки о релизах
• Средние: продуктовая документация, статьи справочного центра, changelog
• Быстрые: открытые тикеты поддержки, баг-репорты, заметки об инцидентах

Не гадайте, если можно измерить. Проверьте историю правок по каждой группе за последние 3–6 месяцев. Посчитайте, как часто менялись файлы, страницы или записи. Если продуктовая документация менялась 40 раз за прошлый месяц, а политики — дважды за квартал, разница очевидна.

Полезно также понять, кто именно обновляет каждый источник. Владелец часто говорит о скорости изменений не меньше, чем сам тип контента. Команда документации может вносить правки раз в неделю пакетами. Руководитель по compliance может публиковать изменения только после цикла согласования. Служба поддержки может создавать или закрывать тикеты весь день.

Когда вы знаете эти привычки, проще предсказать нужный ритм обновления.

Некоторые команды добавляют ещё одну проверку: насколько дорого обойдётся устаревший ответ. Слегка устаревшее резюме changelog раздражает. А устаревшая политика возврата может создать реальные проблемы. Это не делает политику быстро меняющейся, но может оправдать более жёсткий контроль в момент изменений.

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

Решите, что заслуживает бюджета

Бюджет на обновление — это не про равенство. Тратьте его там, где устаревшие факты быстрее всего доходят до клиентов.

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

Продуктовая документация часто оказывается в верхней части списка, потому что люди читают её до обращения в поддержку. Если шаг настройки изменился вчера, старый фрагмент может за несколько минут увести человека не туда. Политикам нужно не меньше внимания, если они влияют на возвраты, доступ, приватность, биллинг или юридические обещания. Одно устаревшее правило может навредить сильнее, чем десять старых страниц помощи.

Тикеты поддержки требуют другого фильтра. Закрытый тикет прошлого года может почти ничего не добавить. А группа похожих тикетов за эту неделю может оказаться очень важной, особенно после релиза, сбоя или изменения цены. Смотрите на паттерны, а не только на объём. Десять повторяющихся вопросов об одном баге говорят больше, чем сотня старых несвязанных тикетов.

Для большинства команд хорошо работает простая приоритизация:

• Первый уровень: продуктовая документация, правила цен, активные политики
• Переводите в этот уровень актуальные темы поддержки, когда новая проблема начинает распространяться
• Держите внутренние справочные материалы со средним риском на ежедневном или еженедельном плане
• Переносите архивные документы, старые проекты и давно закрытые тикеты на ежемесячный или ручной план

Риск важен не меньше, чем скорость изменений. Политика конфиденциальности, которая меняется два раза в год, всё равно может требовать немедленного обновления в момент изменения. А редко используемое руководство по функции можно обновлять реже, даже если кто-то правит его часто.

Если сомневаетесь, задайте один прямой вопрос: какой контент вам было бы страшно услышать процитированным клиенту после того, как он уже стал неверным? Сначала финансируйте его.

Постройте план обновления по шагам

Начните с простого списка. Перечислите все источники, которые читает система: продуктовую документацию, release notes, внутренние политики, страницы FAQ, тикеты поддержки, заметки об инцидентах и любые общие папки, на которые люди тихо полагаются. Если у источника нет владельца, отметьте это тоже. Бесхозный контент быстро устаревает.

Начните с групп источников

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

Потом задайте максимально допустимый возраст для каждой группы. Именно здесь графики обновления перестают быть гаданием. Если ответы по поддержке начинают выглядеть неверно через два часа, так и запишите. Если текст политики может оставаться точным неделю, тоже запишите.

Для планирования обычно хватает пяти полей:

• Группа источников
• Владелец
• Максимально допустимый возраст
• Обычная частота обновления
• Триггер экстренного обновления

Подберите частоту под риск

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

Оставьте одно правило вне обычного графика. Некоторые изменения должны запускать обновление немедленно. Релиз продукта, изменение цены, правка закона или новое правило безопасности не должны ждать следующую пакетную задачу.

Именно здесь многие команды тратят вычисления впустую. Они обновляют всё каждую ночь, потому что это кажется безопасным. Обычно это не так. Лучший план тратит больше на быстро меняющиеся факты и меньше на медленный текст.

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

Простой пример для документации, политик и тикетов

Небольшая support-команда часто работает с тремя очень разными источниками. Продуктовая документация меняется, когда команда выпускает что-то новое. Политики компании меняются реже, но одно пропущенное обновление может привести к неверному ответу. Тикеты поддержки движутся весь день, и старые сводки быстро устаревают.

Именно поэтому фиксированное время почти никогда не работает. Если у всех источников один график, вы либо тратите вычисления на медленный контент, либо позволяете быстрому контенту устареть.

Простой план может выглядеть так:

• Проверять продуктовую документацию раз в день, а после релизов делать дополнительное обновление
• Проверять политики раз в неделю и также обновлять их, когда кто-то редактирует или утверждает политику
• Пересобирать сводки по тикетам каждые несколько часов, чтобы ассистент видел свежие проблемы, обходные решения и изменения статуса

Представьте SaaS-компанию в обычную неделю. В понедельник команда выпускает небольшое обновление для биллинга и настроек аккаунта. Ежедневная проверка находит новые статьи помощи и обновляет индекс до того, как слишком много пользователей зададут один и тот же вопрос.

Позже на той же неделе legal меняет правило возврата. Этот документ не требует постоянной повторной обработки, но ему нужен еженедельный пересмотр и обновление по сигналу, когда кто-то меняет политику. Если ассистент удерживает старое правило даже два дня, поддержка может дать неверный ответ.

Тикетам нужен самый быстрый цикл. Баг может открыться в 9:00, получить обходное решение к полудню и закрыться к 16:00. Если сводки по тикетам обновляются только раз в день, ассистент может предложить уже неработающий способ или не заметить обходное решение, которое агенты используют прямо сейчас.

Запустите такой план на две недели, а потом сравните качество ответов и стоимость вычислений. Если частое обновление политик почти не меняет результат, замедлите этот источник. Если ответы на основе тикетов всё ещё пропускают свежие события, ускорьте этот источник.

Используйте сигналы изменений, а не только таймеры

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

Начните с сигналов, которые уже дают сами источники. В продуктовой документации часто есть даты публикации, номера версий и изменённые поля. Эти сигналы говорят больше, чем жёсткий график, потому что указывают на реальное изменение, а не просто на проход времени.

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

Release notes требуют собственного триггера. Когда появляется новая заметка о релизе, обновите связанные документы, сводки changelog и все фрагменты ответов, привязанные к затронутой функции. Так результаты поиска остаются синхронизированными с текущим поведением продукта, а не ждут следующего пакетного запуска.

Для политик нужны более строгие сигналы. Не обновляйте их из-за того, что кто-то открыл черновик или сохранил комментарий. Обновляйте, когда исходная система помечает политику как утверждённую, опубликованную или заменённую. Так retrieval остаётся согласованным с правилами, которым люди обязаны следовать, а не с полуготовым текстом, который никто не должен видеть.

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

• Краткое описание проблемы
• Область продукта
• Итоговое решение
• Подтверждённое обходное решение
• Дата последнего подтверждённого исправления

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

Если у вас небольшая команда, это особенно важно. Oleg Sotnikov часто работает с компаниями над снижением потерь на уровне архитектуры, и логика обновлений отлично вписывается в тот же подход. Тратьте вычисления там, где факты меняются быстро. Оставляйте медленные источники в покое, пока реальный сигнал не говорит об обратном.

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

Ошибки, которые тратят вычисления

Большинство команд расходует бюджет на задачи, которые запускаются слишком часто, затрагивают слишком много данных или индексируют контент, не добавляющий новых фактов. Если кажется, что обновление дорого обходится, причина обычно проста: pipeline реагирует на активность, а не на реальное изменение.

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

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

Ещё одна тихая утечка — дублирующийся контент. Один и тот же ответ часто встречается в продуктовой документации, статьях помощи, внутренних runbook и копиях тикетов. Если индексировать всё это, вы несколько раз платите за один и тот же смысл и делаете retrieval более шумным. Выберите один источник как каноническую версию, а копии понизьте в приоритете или вообще пропустите.

Небольшие сбои тоже накапливаются. Парсер может сломаться, вернуть пустой текст или превратить таблицу в бессмыслицу. Если pipeline всё равно индексирует такой вывод, вы одновременно тратите вычисления на мусор и ухудшаете качество ответов.

Несколько проверок ловят большую часть таких проблем:

• Сравнивайте хэши или маркеры изменений перед повторным созданием embeddings
• Пропускайте документы с пустым выводом или слишком коротким текстом
• Помечайте ошибки парсера для ручной проверки вместо того, чтобы молча индексировать их
• Объединяйте или удаляйте почти одинаковые страницы до того, как они попадут в индекс

Самое дешёвое обновление — то, которое вы вообще не запускаете. Если документ почти не изменился или изменился так, что пользователи никогда не спросят об этом, оставьте его в покое.

Быстрая проверка перед автоматизацией

Автоматизация обычно ломается по обычным причинам. У источника нет владельца. Никто не знает, насколько старым может быть контент. Никто не замечает плохие ответы, пока не начнут жаловаться пользователи.

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

Начните с ответственности. У каждой группы контента должен быть один человек или одна команда, которые могут ответить на простой вопрос: «Это всё ещё верно?» Продуктовая документация может принадлежать продукту или поддержке. Политики обычно относятся к legal, HR или operations. Тикеты чаще всего принадлежат поддержке. Если владельца неясно, устаревший контент остаётся в индексе, потому что все думают, что этим займётся кто-то другой.

Потом задайте максимальный возраст для каждой группы. Не используйте одно число для всего.

• Для продуктовой документации может хватить задержки в 7 дней, если релизы выходят еженедельно
• Для внутренних политик может понадобиться обновление в течение 24 часов после утверждения
• Для открытых тикетов может понадобиться обновление каждые 10–15 минут
• Закрытые тикеты могут ждать намного дольше или вообще не попадать в retrieval

Такой лимит даёт вам реальный бюджет. Без него команды обычно слишком часто обновляют дешёвый контент и слишком редко — то, что меняется каждый день.

Вам также нужен аварийный путь. Если меняется правило ценообразования, появляется проблема безопасности или исправляется политика, кто-то должен иметь возможность быстро форсировать обновление. Для этого не нужна огромная система. Достаточно одной ручной задачи, одного действия администратора или одного скрипта. Важно другое: кто запускает обновление, что именно обновляется и сколько времени это занимает.

Отслеживайте сразу три показателя: расходы, свежесть и качество ответов. Один только расход может толкнуть вас к слишком медленному обновлению. Одна свежесть может завести в растрату. Качество ответов показывает, помогает ли лишняя трата пользователям вообще.

Простой тест работает хорошо. Выберите один набор документов, один набор политик и один набор тикетов. Запустите план на две недели. Посмотрите, сколько вы потратили, насколько старым был найденный контент и стали ли ответы лучше или хуже. Если один показатель улучшается, а два других ухудшаются, скорректируйте план до того, как автоматизировать что-то ещё.

Следующие шаги для лёгкого RAG-процесса

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

Небольшого стартового плана часто достаточно:

• Продуктовая документация: обновлять раз в день или сразу после релиза
• Политики: обновлять после утверждения изменения, с еженедельной проверкой на всякий случай
• Тикеты: обновлять каждые несколько часов или только для открытых и массовых проблем

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

Прежде чем добавлять webhooks, diff-пайплайны или автоматическое ранжирование приоритетов, вручную разберите устаревшие ответы. Возьмите небольшой набор плохих ответов и задайте три простых вопроса: какой источник был неверным, насколько он был старым и помогло бы обновление исправить ответ. Часто оказывается, что почти все проблемы создаёт один шумный источник.

Держите план достаточно простым, чтобы один человек мог его понять и поддерживать. Если один человек не может объяснить графики, триггеры и проверки ошибок без открытия пяти инструментов, система уже слишком сложная. Простые планы живут дольше, а когда ломаются, их обычно удаётся починить.

Для многих команд достаточно еженедельного обзора. Проверяйте объём обновлений, стоимость вычислений и то, сколько неверных ответов появилось из-за устаревшего контента, а не из-за слабого retrieval или плохих промптов. Если число устаревших ответов остаётся низким, оставьте систему как есть. Больше автоматизации — не приз.

Если вашей команде нужен практичный взгляд со стороны, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как fractional CTO и советник. Короткий разбор может помочь, если система слишком быстро разрослась, расходы продолжают расти или никто не уверен, какие обновления всё ещё важны.

Лучший результат довольно скучный: меньше устаревших ответов, ниже расходы и план обновлений, который один человек может спокойно поддерживать даже в загруженный день.