Retrieval-augmented generation в 2026 году мало похож на то, что делали два года назад. У Sonnet 4.6 окно контекста 200K токенов, а prompt caching удешевляет стабильный контекст на порядок. Вопрос теперь не «как втиснуть нужный чанк в 8K токенов», а «нужен ли retrieval вообще или проще положить всю базу знаний в закэшированный системный промпт».
Ниже рабочее руководство для архитектора. Когда классический retrieval всё ещё выигрывает. Как пользоваться длинным контекстом и не разориться. Какие embedding-модели и реранкеры ставить рядом с Claude. Как получать цитаты, которым можно верить. И какие грабли попадаются в продакшене снова и снова.
Классический RAG и длинный контекст: когда вообще нужен поиск
Начните с вопроса, нужен ли retrieval. Окно в 200K у Sonnet 4.6 вмещает примерно 100-150 документов среднего размера (по 5-10 страниц), и для многих реальных баз знаний этого хватает целиком. Три практических правила:
- Кладите всё в контекст, если корпус небольшой (до ~150K токенов), не меняется от сессии к сессии, а вопросы охватывают сразу несколько документов. Закэшированный системный промпт с полным корпусом обгоняет retriever и по качеству, и по задержке уже после первого вызова.
- Делайте retrieval, если корпус большой (миллионы токенов), часто меняется или на каждый запрос достаточно 1-5 документов. Поиск по эмбеддингам остаётся самым дешёвым способом сузить выборку.
- Берите гибрид: ищите с запасом (top-50 или top-100), а остальное доберёт длинный контекст Claude. В 2026 году это преобладающий паттерн: он снижает требования к точности поиска и переносит больше качества на саму модель.
Почему prompt caching меняет экономику
Prompt caching это главная причина, по которой длинный контекст стал экономически осмысленным. Вы помечаете префикс промпта как кэшируемый, Anthropic хранит его у себя, и следующие вызовы с тем же префиксом платят за эту часть примерно 10% обычной цены input. Запись в кэш чуть дороже обычного input-токена, зато чтение радикально дешевле.
Для стабильной базы знаний выходит так:
- Первый вызов: полная цена за запись кэша (~25% надбавки на кэшируемой части).
- Каждый следующий вызов в пределах TTL: ~10% за закэшированный префикс и полная цена только за уникальный хвост запроса.
На практике RAG-ассистент, который отвечает на десятки запросов в час к одному корпусу, окупает кэш за два-три вызова и дальше обходится примерно в 10 раз дешевле, чем без кэша. Поэтому «загрузить 80 документов в Sonnet» стало настоящим продакшн-паттерном, а не фокусом для демо.
Выбор embedding-модели
Если retrieval всё же нужен, от embedding-модели зависит больше, чем принято думать. Короткий список на 2026 год:
- Voyage AI (
voyage-3-large, а для кодаvoyage-code-3): решение, которое Anthropic официально рекомендует. Хороша на английском, на коде и в мультиязычных задачах, сделана специально под RAG. - OpenAI
text-embedding-3-large: надёжный запасной вариант, если ключи OpenAI у вас уже есть и нужна проверенная база с размерностью 3072. - BAAI
bge-m3: open-source, мультиязычная, с сильным recall. Запускается локально на одном A100, когда эмбеддинги нужно держать on-prem.
Что бы вы ни выбрали, зафиксируйте версию модели. Переэмбеддинг корпуса из-за того, что вендор тихо обновил модель, это самая частая авария RAG в продакшене, которую команды устраивают себе сами.
Reranking: дешёвый выигрыш, который теперь делают все
Векторный поиск возвращает правдоподобных кандидатов, а не готовый порядок ответов. Стандартная схема 2026 года: взять с запасом (top-50 или top-100), а затем сократить до top-10 или top-20 кросс-энкодером:
- Cohere Rerank 3: хостед, мультиязычный, очень хорошее качество, оплата за вызов.
- BAAI
bge-reranker-v2-m3: open-source, работает на обычных GPU, платы за вызов нет.
Реранкер обычно поднимает качество ответов сильнее, чем замена Sonnet на Opus, а стоит в разы меньше. Если вы до сих пор обходитесь без него, чинить нужно в первую очередь это.
Гибридный поиск: BM25 всё ещё нужен
Чистый векторный поиск промахивается на запросах с точным совпадением:
артикулы, коды ошибок, имена функций, номера статей закона. Лечится
гибридным поиском. BM25 (через OpenSearch, Elastic или tantivy) и
векторный retrieval идут параллельно, а оценки сливаются через
reciprocal rank fusion (RRF). На разнородных корпусах гибрид стабильно
обходит чисто векторный поиск, а если документы уже проиндексированы,
почти ничего не стоит.
Стратегии чанкинга, которые работают
Чанкинг остаётся вопросом настройки, а не решённой задачей. Значения по умолчанию, которые выдерживают проверку в 2026 году:
- 800-1200 токенов на чанк с перекрытием 100-200 токенов для обычного текста.
- Целая функция для кода, а путь к файлу и имя класса идут в заголовке.
- Семантический чанкинг (сперва по границам заголовков, потом по размеру) для технической документации.
- Всегда сохраняйте ID родительского документа и стабильный ID чанка, чтобы цитаты можно было привести к источнику.
Не режьте слишком мелко. Чанки короче 500 токенов теряют контекст и заставляют reranker делать работу, которую должен был сделать embedder.
Надёжные цитаты
Выдуманные цитаты быстрее всего съедают доверие пользователя. Схема, которая работает на Claude:
- Помечайте каждый найденный чанк в промпте явным ID:
[1] (источник: docs/auth.md): ...текст... - В системном промпте требуйте от Claude подписывать каждое фактическое утверждение скобочным ID и отказываться отвечать, если ни один найденный чанк утверждение не подтверждает.
- Постобработкой проверяйте, что каждый
[N]соответствует чанку, который вы действительно отправили. Несовпадающие удаляйте или помечайте.
Третий шаг не обсуждается. Даже Sonnet 4.6 иногда выдумывает ID цитаты, когда на него давят, и именно верификатор делает систему заслуживающей доверия.
Минимальный пайплайн на codexkey
Вот рабочий набросок полного цикла (embed, retrieve, rerank, cite) через эндпоинт codexkey:
import anthropic
import voyageai
import cohere
client = anthropic.Anthropic(
base_url="https://api.codexkey.ru/v1",
api_key="<ваш-codexkey-ключ>",
)
voyage = voyageai.Client()
co = cohere.Client()
def answer(question: str, corpus_chunks: list[dict]) -> str:
# 1. Эмбеддим запрос
q_emb = voyage.embed([question], model="voyage-3-large").embeddings[0]
# 2. Векторный retrieval top-50 (вызов вашего vector store)
candidates = vector_store.search(q_emb, k=50)
# 3. Reranking в top-10 через Cohere
reranked = co.rerank(
model="rerank-3",
query=question,
documents=[c["text"] for c in candidates],
top_n=10,
)
top = [candidates[r.index] for r in reranked.results]
# 4. Собираем контекст с цитатами
context = "\n\n".join(
f"[{i+1}] (источник: {c['source']}): {c['text']}"
for i, c in enumerate(top)
)
# 5. Вызов Claude с закэшированным системным промптом
msg = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": "Ты — точный ассистент. Цитируй каждое "
"фактическое утверждение скобочным ID вида [1]. "
"Если ни один источник не подтверждает ответ — "
"так и скажи.",
"cache_control": {"type": "ephemeral"},
}
],
messages=[
{
"role": "user",
"content": f"{context}\n\nВопрос: {question}",
}
],
)
return msg.content[0].text
Маркер cache_control включает 10-кратную скидку на системный промпт
между вызовами. Если база знаний забита целиком, переносите сам корпус в
закэшированный системный блок, а не в пользовательское сообщение. Схема
та же, экономия заметно больше.
Оценивайте retrieval и генерацию отдельно
Самая полезная привычка в продакшн-RAG: мерить две стадии независимо.
- Качество retrieval: recall@k на размеченном наборе пар (вопрос, правильный документ). Если recall@10 ниже ~0.85, никакая prompt-инженерия ответ не спасёт.
- Качество генерации: faithfulness (согласуется ли ответ с найденным контекстом) и корректность ответа. Оценивают люди или LLM-судья на отдельном eval-наборе.
Когда метрики смешаны, команды «лечат» проблемы генерации настройкой retriever и наоборот. Держите их раздельно.
Типовые грабли
- Lost-in-the-middle. Даже при 200K токенов Claude надёжнее всего смотрит на начало и конец контекста. Самые релевантные чанки ставьте в начало, вопрос в конец, а критичные факты не хороните посреди стены в 100K токенов.
- Галлюцинации цитат. Всегда проверяйте, что процитированные ID указывают на реальные чанки. Непроверенная цитата это сбой, а не предупреждение.
- Инвалидация кэша. Любая правка кэшируемого префикса, даже пробел, сбрасывает кэш. Версионируйте системные промпты и шаблоны.
- Устаревшие эмбеддинги. При смене модели эмбеддингов переэмбеддите весь корпус. Векторное хранилище со смесью моделей деградирует тихо.
- Over-retrieval без reranking. Взять top-100 чанков и сразу отправить в промпт дорого и хуже по качеству. Всегда делайте rerank.
Итог
Выигрышный RAG-стек 2026 года скучный в самом хорошем смысле: закэшированный системный промпт, Sonnet 4.6 как генератор, эмбеддинги Voyage, реранкер от Cohere или BGE, гибридный поиск BM25 плюс вектор и верификатор цитат на выходе. Каждая деталь дешёвая, понятная и улучшает качество сама по себе. Вместе они дают систему, которая быстра, поддаётся аудиту и держит цену стабильной, пока корпус растёт. О ценах на Sonnet 4.6 и остальное семейство читайте в соседнем материале про цены Claude API в 2026.