Capstone: production RAG with an SLO, budget, and rollback

Финальная архитектура начинается не со списка продуктов, а с workload sheet. Зафиксируйте число векторов сегодня и через год, размерность и тип вектора, средний размер metadata, частоту обновлений, долю удалений, требования к фильтрам, top-k, p95 latency, доступность и региональность. Добавьте операционную модель: managed-сервис, собственный кластер или локальный индекс в одном процессе. Без этих чисел сравнение Qdrant, Weaviate, Pinecone, pgvector или FAISS превращается в спор по скриншотам.

Память индекса оценивайте до загрузки данных. Грубая нижняя граница для dense-векторов float32 — N × dimensions × 4 bytes; к ней добавляются граф HNSW, payload-индексы, реплики и запас на compaction. Миллион 1536-мерных векторов — уже около 6.1 GB только сырого массива. Квантизация уменьшает footprint, но её влияние на recall измеряют на вашем golden-наборе, а не принимают на веру.

Решение оформите ADR с критериями и rejected alternatives. Например: pgvector разумен, если корпус умеренный, транзакционные данные уже в Postgres и важны сложные relational-фильтры; специализированная vector DB выигрывает при большом индексе, высокой параллельности, распределённой репликации и сложном hybrid retrieval. FAISS — библиотека, а не готовая распределённая база: persistence, репликация, фильтры и контроль доступа останутся вашей ответственностью.

Стоимость RAG-запроса раскладывается по стадиям: embedding запроса, vector/lexical search, reranker, входные токены генерации, выходные токены, сетевые переходы и инфраструктура индекса. Считайте не только среднее, но и стоимость p95-сценария: multi-hop может сделать три retrieval-цикла, а длинный контекст — умножить самую дорогую часть. В трассу записывайте retrieval_candidates, reranked_count, context_tokens, output_tokens, стоимость каждой модели и версию конфигурации — тогда бюджет объясним, а не вычислен постфактум по общему счёту провайдера.

Кеши ставятся на разных уровнях и имеют разные ключи. Embedding-cache безопасно ключевать хешем нормализованного запроса плюс версия модели. Retrieval-cache обязан включать tenant, ACL-срез, версию индекса и параметры поиска; иначе быстрый кеш становится каналом межклиентской утечки. Response-cache допустим только для публичных или строго детерминированных ответов и также должен учитывать права и версию корпуса. Semantic cache по близости запросов экономит больше, но может вернуть правдоподобный ответ на другой вопрос — его порог и классы исключений проверяются отдельным eval-набором.

Freshness — часть контракта. Каждое изменение документа увеличивает версию корпуса или инвалидирует связанные ключи; TTL — дополнительная страховка, а не основной механизм корректности. Отдельно измеряйте hit rate, долю stale-hit, экономию токенов и ошибки изоляции. Кеш, для которого команда не умеет доказать инвалидацию и tenant boundary, в production не включается.

Определите пользовательский SLO, а не только uptime отдельных сервисов. Для внутреннего ассистента это может быть: 99% ответов быстрее 4 секунд, 99.9% запросов без межтенантной утечки, recall@10 не ниже базовой линии минус 2 пункта и не менее 95% ответов с проверенными цитатами. Latency, correctness и safety — разные SLI; объединять их в один «quality score» нельзя, потому что при инциденте он не показывает, что именно нарушено.

Для каждой зависимости задайте явную деградацию. Vector DB недоступна — не просить LLM ответить из памяти, а вернуть честный отказ или переключиться на разрешённый lexical fallback. Reranker превысил deadline — использовать top-k первой ступени и пометить трассу. Генератор недоступен — отдать найденные документы, если продуктовый контракт это допускает. Judge упал — в высокорисковом домене блокировать ответ, в низкорисковом показать предупреждение. Deadline распределяется по стадиям заранее; бесконечные retry только превращают частичный отказ в каскадный.

Наблюдаемость связывает запрос с версиями embedding-модели, индекса, chunker, retrieval-конфига и промпта. Алерт строится по burn rate error budget, а не по одиночному всплеску p95. Runbook рядом с алертом отвечает на три вопроса: как подтвердить симптом, как безопасно деградировать и какую версию откатить.

Изменение chunking, embedding-модели или metadata-схемы нельзя выкатывать поверх живого индекса. Создайте новый versioned index, полностью заполните его, прогоните integrity-проверки и offline eval, затем запустите shadow traffic: новый retrieval получает копию запросов, но пользователь ещё видит старый результат. Сравните recall, overlap top-k, latency, zero-result rate и стоимость по одинаковым запросам.

После shadow идёт canary на малой доле пользователей или tenants с автоматическим стопом по SLO. Переключатель маршрутизации должен позволять вернуть старый индекс без повторной индексации. Старую версию не удаляют до завершения окна наблюдения и проверки обратимости новых документов. Dual-write во время перехода требует метрики рассинхронизации и очереди повторов — «пишем в оба и надеемся» не является стратегией.

Итоговый production blueprint состоит из диаграммы потока, ADR выбора хранилища, схемы данных и ACL, таблицы стоимости, eval-baseline, SLO/error budget, dashboard, runbook и пошагового rollback. Перед приёмкой проведите game day: искусственно отключите reranker или новый индекс и докажите, что система переходит в запланированный режим, алерт срабатывает, а оператор возвращает предыдущую версию по инструкции.