РУКОВОДСТВО · ОБНОВЛЕНО 2026-11-02
Обновление RAG по HTTP: как использовать ETag и не удалить документ после 304
Контракт загрузчика, который отличает неизменившийся источник от пустого документа.
Ответ 304 на условный запрос не содержит новую копию тела и не означает, что документ стал пустым. Загрузчик должен сохранить связь с ранее полученным представлением и его валидатором. При ответе 200 обрабатывайте новую версию, а ошибки загрузки отделяйте от удаления источника. ETag помогает избежать повторной передачи представления, но сам по себе не подтверждает правильность вашего индекса. Если изменился парсер, chunking или правила доступа, даже прежнее содержимое может потребовать повторной обработки. План обновления должен учитывать и источник, и версию вашего конвейера.
1. Сохраните результат первой загрузки
После успешного 200 сохраняйте содержимое, URL, время, необходимые заголовки и связь с версией документа. Если источник возвращает ETag, храните его как непрозрачное значение, а не пытайтесь вычислить смысл строки. Учитывайте, что разные представления одного URL могут зависеть от заголовков и авторизации. Нельзя повторно использовать закрытый документ для другого пользователя только потому, что адрес совпал. Валидатор должен относиться именно к разрешённому представлению, которое действительно есть в вашем хранилище.
2. Обработайте условный ответ явно
Отправляйте документированный условный заголовок, например If-None-Match с ранее полученным ETag. При 304 используйте сохранённое представление и обновляйте необходимые метаданные согласно HTTP-контракту. Не передавайте пустое тело дальше как новую редакцию и не удаляйте все чанки. Если локальная копия отсутствует, предусмотрите корректное повторное получение тела. MDN описывает 304 как ответ на условную проверку неизменившегося ресурса, а не как подтверждение успешного извлечения текста вашим приложением.
3. Разделите изменение источника и обработки
Новая версия HTML или PDF может потребовать повторного извлечения, но такое же требование возникает после изменения самого парсера. Сохраняйте версии преобразований, модели эмбеддингов и схемы метаданных. Не считайте одинаковый ETag доказательством, что обновлённый алгоритм уже применён. Для замены индекса подготовьте новый результат и проверяйте его перед переключением. Ошибку получения 401,403 или сетевой сбой обрабатывайте по отдельной политике доступа и свежести, без автоматического превращения в удаление документа.
4. Проверьте сценарии восстановления
Поднимите собственный тестовый источник с ответами 200 и 304, изменённым телом, пропущенным валидатором и временным отказом. Проверьте, что после перезапуска загрузчик понимает, какая копия сохранена, и не теряет происхождение чанков. Не выполняйте нагрузочные опросы чужого сайта ради теста. Для приёмки сравните содержимое индекса и права до и после обновления. Отдельно проверьте изменение конвейера при неизменном источнике и объяснение пользователю, если актуальность временно не подтверждена.
Частые вопросы
Нужно ли заново индексировать пустое тело 304?
Нет.304 относится к сохранённому представлению. Пустое тело такого ответа нельзя считать новой пустой редакцией документа.
ETag — это всегда хеш файла?
Нет. Для клиента это непрозрачный валидатор сервера. Не стройте бизнес-логику на догадках о его внутреннем формате.
Документ не изменился — можно пропустить новый парсер?
Не обязательно. Источник и версия конвейера различаются. Изменение извлечения или метаданных может требовать обработки прежнего содержимого.
Сетевая ошибка означает, что источник удалён?
Нет. Временный отказ, изменение прав и подтверждённое удаление имеют разные значения. Решение о доступности принимается по явной политике.