В корпоративных и продуктовых AI-проектах Retrieval Augmented Generation (RAG) всё чаще используется как базовый архитектурный паттерн для работы с собственными данными. При этом вокруг RAG по-прежнему много путаницы: его путают с fine-tuning, воспринимают как способ «дообучить модель» или считают встроенной функцией самой LLM.
На практике RAG — это не свойство языковой модели, а отдельный слой системы, который связывает модель с данными компании. Особенно наглядно это проявляется в экосистеме Яндекса, где RAG реализован как сервисная архитектура вокруг YandexGPT, а не как часть самой модели.
Навигация
- Введение и базовые принципы
- Архитектура RAG
- Реализация и логика работы
- Примеры кода и API
- Эксплуатация и ограничения
- Итоги
Практическое определение RAG
В инженерном смысле RAG — это архитектурный подход, при котором языковая модель генерирует ответ не только на основе собственных параметров, но и с учётом релевантных фрагментов данных, найденных во внешней базе знаний.
Ключевой момент заключается в том, что поиск и отбор данных выполняются до вызова модели. Языковая модель получает уже подготовленный контекст и не знает, какие именно документы или индексы были использованы.
В материалах Yandex Cloud RAG описывается как связка поискового индекса и языковой модели. Поисковый механизм отвечает за retrieval, а модель — исключительно за генерацию текста.
В описании AI Assistant API подчёркивается, что сервис объединяет модель YandexGPT и технологию Retrieval Augmented Generation для работы с корпоративными документами. Это означает, что RAG реализован как сервис вокруг модели, а не как её внутренняя функция.
Почему RAG — не часть языковой модели
Одна из самых распространённых архитектурных ошибок — предположение, что RAG «встроен» в модель. На практике ни YandexGPT, ни другие промышленные LLM не имеют прямого доступа к пользовательским данным.
Языковая модель:
- не знает о структуре корпоративных документов;
- не хранит файлы и базы знаний;
- не управляет поиском, фильтрацией и ранжированием данных.
Вся логика работы с данными вынесена за пределы модели. В экосистеме Яндекса эту роль выполняют ассистентные сервисы и инфраструктурные компоненты, которые определяют, когда и какие фрагменты будут переданы в модель.
Ассистент автоматически дополняет пользовательский вопрос контекстом из базы знаний. Для самой модели этот контекст не отличается от любого другого входного текста — она не знает его происхождения.
Типовой RAG-пайплайн
Независимо от платформы и масштаба проекта, RAG почти всегда реализуется по одной и той же схеме. Различия касаются деталей, но базовые этапы остаются неизменными.
1. Индексация
На этапе индексации документы проходят предварительную обработку:
- разбиение на чанки;
- векторизация каждого фрагмента;
- сохранение в поисковом индексе.
Размер чанков и стратегия разбиения напрямую влияют на качество retrieval и стоимость эксплуатации системы.
2. Retrieval
При запросе пользователя система выполняет поиск по индексу и выбирает набор наиболее релевантных фрагментов. На этом этапе могут применяться дополнительные механизмы ранжирования и фильтрации.
3. Подготовка промпта
Найденные фрагменты объединяются с вопросом пользователя в единый промпт и передаются языковой модели. Модель не знает, что часть текста получена из базы знаний — для неё это просто входной контекст.
Компоненты RAG-системы
На практике RAG-стек почти всегда состоит из одних и тех же компонентов, независимо от вендора.
- Хранилище документов — файлы, базы знаний, объектные хранилища;
- Поисковый индекс — векторный или гибридный;
- Retrieval-логика — поиск и отбор фрагментов;
- Ассистент-оркестратор — управляет вызовами;
- LLM — генерация ответа;
- Интеграционный слой — API и приложения.
Ключевой вывод здесь прост: языковая модель — лишь один из элементов RAG-системы и не может рассматриваться как самостоятельное решение для работы с корпоративными данными.
RAG в экосистеме Яндекса
В экосистеме Яндекса RAG реализован как часть ассистентных сервисов. Через AI Assistant API разработчик загружает документы, создаёт поисковый индекс и связывает его с ассистентом, использующим модель YandexGPT.
Разработчик явно задаёт:
- какая модель используется;
- какие индексы подключены;
- когда ассистент обращается к базе знаний.
Таким образом, ассистент выступает центральным оркестратором, а RAG — сервисным слоем, контролирующим доступ модели к данным.
RAG и fine-tuning: принципиальная разница
RAG часто ошибочно сравнивают с дообучением модели. Однако эти подходы решают принципиально разные задачи.
Fine-tuning изменяет параметры модели и требует повторного обучения. RAG же не меняет модель вовсе — он лишь подставляет актуальные данные в контекст запроса.
Именно поэтому в корпоративных сценариях RAG считается более управляемым подходом: данные можно обновлять, удалять и переиндексировать без вмешательства в саму модель.
VectorStore и retrieval-логика
В экосистеме Яндекса ключевым компонентом RAG является VectorStore. Именно он отвечает за хранение векторизованных фрагментов документов и выполнение retrieval — поиска релевантных чанков по запросу пользователя.
Важно понимать, что VectorStore — это не просто «база векторов». Это сервисный компонент, который:
- индексирует загруженные документы;
- хранит embeddings фрагментов;
- выполняет поиск по запросу;
- возвращает фрагменты с метаданными;
- передаёт результаты ассистенту.
Retrieval-логика при этом управляется не языковой моделью, а ассистентом-оркестратором, который определяет, когда и как обращаться к индексу.
Стратегии вызова поиска
Один из наиболее недооценённых аспектов RAG — стратегия вызова retrieval. В экосистеме Яндекса именно ассистент решает, в какой момент обращаться к VectorStore.
На практике используются три базовых подхода:
- поиск выполняется всегда;
- поиск выполняется только при определённых типах запросов;
- поиск выполняется по результатам первичной интерпретации запроса.
Неправильно выбранная стратегия приводит либо к переполнению контекста, либо к ситуациям, когда модель отвечает из собственных знаний, игнорируя базу данных.
Примеры кода: SDK
Ниже приведён упрощённый пример RAG-пайплайна с использованием SDK. Он демонстрирует принципиальную логику, а не полный production-код.
from yandex_cloud_ai_studio import AIStudioClient
client = AIStudioClient(
api_key="<API_KEY>"
)
# Загрузка документа в базу знаний
file = client.files.create(
file_path="docs/policy.pdf",
purpose="knowledge"
)
# Создание поискового индекса
index = client.search_indexes.create(
name="policy-index"
)
client.search_indexes.add_files(
index_id=index.id,
file_ids=[file.id]
)
# Создание ассистента с RAG
assistant = client.assistants.create(
name="policy-assistant",
model="yandexgpt-pro",
system_prompt=(
"Отвечай только на основе документов базы знаний. "
"Если информации нет — скажи об этом."
),
search_index_ids=[index.id]
)
# Запрос пользователя
response = client.assistants.chat(
assistant_id=assistant.id,
messages=[
{"role": "user", "content": "Какие ограничения указаны в политике?"}
]
)
print(response.answer)
В данном примере используется модель YandexGPT 5 Pro, однако архитектура не зависит от конкретной версии модели.
Примеры REST-запросов
AI Assistant API также доступен через REST-интерфейс, что позволяет интегрировать RAG в любые backend-системы.
POST https://ai.api.cloud.yandex.net/assistant/v1/sessions/<SESSION_ID>:invoke
Authorization: Bearer <IAM_TOKEN>
Content-Type: application/json
{
"messages": [
{
"role": "user",
"content": "Найди условия возврата товара"
}
]
}
Ответ ассистента может включать не только сгенерированный текст, но и ссылки на источники, если включён режим citations и исходные файлы сохранены.
Для корпоративных сценариев наличие источников является критически важным требованием к объяснимости ответов.
Лимиты и квоты
При проектировании RAG-системы необходимо учитывать ограничения AI Studio, которые напрямую влияют на архитектуру решения.
- максимальное количество файлов: 10 000;
- максимальный размер файла: 128 MB;
- максимум файлов в одном индексе: 10 000;
- лимит входных токенов для векторизации: 2 000;
- максимум токенов в ответе (в консоли): 1 000.
Эти лимиты означают, что документы почти всегда требуют предварительной обработки: очистки, нормализации и продуманного чанкования.
Типовые ошибки при внедрении RAG
На практике команды чаще всего сталкиваются со следующими проблемами:
- слишком крупные или слишком мелкие чанки;
- единый индекс для разнородных данных;
- агрессивный retrieval без ограничений;
- отсутствие инструкций «не отвечай, если данных нет»;
- удаление файлов при включённых citations.
RAG снижает вероятность галлюцинаций, но не устраняет её полностью. Критически важные данные всё равно требуют проверки.
Что не раскрыто публично
Несмотря на подробную документацию, ряд аспектов реализации RAG в экосистеме Яндекса не раскрывается публично.
- точный размер контекстного окна моделей;
- алгоритмы ранжирования фрагментов;
- метрики похожести embeddings;
- детали реализации VectorStore.
Публичные материалы описывают API и лимиты, но не внутреннюю оптимизацию сервисов.
Практические выводы
RAG — это не «фича модели», а отдельный архитектурный слой, который требует проектирования и эксплуатации.
В экосистеме Яндекса RAG реализован как сервисная надстройка вокруг моделей YandexGPT, где ключевую роль играет ассистент-оркестратор.
Успех внедрения определяется не выбором модели, а качеством индексации, retrieval-логики и архитектурных решений.
