Что такое RAG

Короткая версия

RAG обычно решает три задачи:

1. Дать модели доступ к вашим данным, которых не было в обучении.
2. Обновлять знания без fine-tuning, когда документы меняются.
3. Снизить галлюцинации, заставляя модель опираться на найденный контекст.

Минимальная формула такая:

question
-> retrieve relevant context
-> assemble prompt or tool context
-> generate grounded answer

Из чего состоит RAG

Вопрос: «Какой срок возврата электроники?»

Retrieved context:
- «Возврат электроники возможен в течение 7 дней с момента покупки»
- «Для оформления возврата нужен чек или номер заказа»

Где RAG нужен чаще всего

• support и help center;
• корпоративный поиск по внутренним документам;
• copilot по документации и коду;
• legal/compliance knowledge bases;
• research workflows по приватным коллекциям файлов.

1. Что именно делает RAG

Базовая идея из original Lewis et al. остаётся той же: retrieval добавляет внешние знания в момент ответа. Но в 2026 практическая рамка шире:

• retrieval может быть custom, где вы сами контролируете chunking, embeddings, reranking и storage;
• retrieval может быть hosted, где платформа уже даёт vector stores, file_search и семантический поиск;
• generation может быть single-shot, citation-first или частью agent workflow.

То есть RAG сегодня лучше понимать как knowledge access layer для LLM-приложения, а не как одну конкретную библиотеку или архитектуру.

2. Почему одного большого context window недостаточно

У современных моделей большие окна, но это не отменяет retrieval.

Проблемы long-context-only подхода:

• дорого слать весь корпус на каждый запрос;
• растёт latency;
• модель получает много шума;
• теряется управляемость по источникам;
• сложнее делать citations и фильтрацию по доступам.

RAG выигрывает тем, что в каждый ответ попадает только маленький и релевантный поднабор знаний.

3. Как RAG обычно устроен в 2026

Ingestion и indexing

Сначала данные нужно подготовить:

• загрузить файлы;
• разбить документы на чанки;
• сохранить metadata;
• создать searchable index.

Если вы строите custom stack, для этого используют embeddings и vector database. Если идёте в hosted path, платформа может сама chunk-ить, embed-ить и индексировать файлы в vector_store.

Retrieval

На запрос пользователя система ищет релевантный контекст. Это может быть:

• semantic search;
• keyword + semantic hybrid;
• metadata filtering;
• reranking;
• multi-query retrieval;
• agentic retrieval с несколькими шагами.

Augmentation

Найденные куски не просто “приклеиваются” к prompt. Нормальный augmentation-слой ещё решает:

• сколько chunks включать;
• в каком порядке;
• как показывать источники;
• как не переполнить budget;
• как разделить retrieved context и instructions.

Generation

Только после этого модель пишет финальный ответ:

• краткий answer;
• answer + citations;
• structured JSON;
• refusal, если ответа нет в контексте.

4. Custom RAG vs hosted retrieval

В 2026 это уже важное различие.

OpenAI current docs прямо разводят Retrieval API и file_search:

• vector stores можно использовать как самостоятельный retrieval layer;
• file_search даёт models access к knowledge base внутри Responses API;
• при hosted path часть best practices уже встроена в платформу.

Это значит, что статья про RAG в 2026 уже не должна звучать как “всегда поднимайте свою vector DB”. Это только один из вариантов.

5. 2-step RAG и Agentic RAG

LangChain current docs удобно разводят два режима:

2-step RAG

Классический путь:

1. всегда делаем retrieval;
2. всегда подставляем найденное;
3. делаем одну generation step.

Это хороший default, когда:

• запросы одношаговые;
• важно предсказуемое поведение;
• нужна низкая latency;
• retrieval почти всегда нужен.

Agentic RAG

Агент сам решает:

• искать ли вообще;
• переформулировать ли query;
• пойти ли во второй источник;
• достаточно ли текущих документов;
• нужен ли tool call вместо retrieval.

Это сильнее, но дороже и сложнее в eval/debug. Поэтому не стоит подавать agentic RAG как обязательный upgrade для каждого FAQ-бота.

6. RAG vs fine-tuning

Эти подходы решают разные проблемы.

Практическое правило:

• RAG нужен для facts and knowledge access;
• fine-tuning нужен для behavior, style, policy or task specialization;
• в production они иногда комбинируются.

7. Где RAG чаще всего ломается

Самые типичные сбои:

• плохой chunking;
• retrieval находит “почти релевантное”, но не нужное;
• слишком много chunks в контексте;
• нет reranking;
• metadata/access filters сломаны;
• модель не умеет честно отвечать “в контексте этого нет”.

Именно поэтому RAG нельзя считать только retrieval-задачей. Это всегда связка:

data quality + chunking + retrieval + prompt/context assembly + answer policy

8. Как понимать хороший RAG в 2026

Хороший RAG — это не тот, который “иногда красиво отвечает”, а тот, который:

• находит правильные куски;
• не тащит лишний шум;
• умеет ссылаться на источник;
• не придумывает, когда контекста не хватает;
• измеряется через retrieval и answer evals.

Минимальный hosted retrieval flow

from openai import OpenAI

client = OpenAI()

vector_store = client.vector_stores.create(name="Support FAQ")

client.vector_stores.files.upload_and_poll(
    vector_store_id=vector_store.id,
    file=open("faq.txt", "rb"),
)

results = client.vector_stores.search(
    vector_store_id=vector_store.id,
    query="Какой срок возврата электроники?",
)

formatted = "\n\n".join(
    part.text
    for item in results.data
    for part in item.content
)

response = client.responses.create(
    model="gpt-5-mini",
    input=[
        {
            "role": "developer",
            "content": "Отвечай только по найденным источникам. Если ответа нет, так и скажи.",
        },
        {
            "role": "user",
            "content": f"Источники:\n{formatted}\n\nВопрос: Какой срок возврата электроники?",
        },
    ],
)

print(response.output_text)

Если нужен ещё более managed path, можно дать модели file_search tool и подключить vector_store_ids прямо в Responses API.