Retrieval-Augmented Generation — подход, при котором перед ответом модель опирается не только на «память» из обучения, но и на найденные во внешнем хранилище фрагменты текста.

Проблема одной только LLM: знания после обучения по сути статичны — модель не узнаёт о событиях после среза данных, не обновляется сама по себе и отражает мир каким он был на момент обучения. Для свежих фактов, внутренних регламентов компании или вашей библиотеки статей этого недостаточно.

• RAG — это технология подключения внешних источников к шагу генерации.
• Она смягчает проблему устаревших знаний: релевантные куски подтягиваются из актуального корпуса.
• Модель дополняется контекстом из документов, а не только весами, заложенными при pre-training.

RAG не отменяет галлюцинации полностью, но даёт опору на цитируемые фрагменты — их проще проверить человеку или правилами.

Типичный пайплайн можно представить как цепочку из офлайн-подготовки данных и онлайн-запроса пользователя.

• Загрузка корпуса и чанкование. Документы попадают в систему и режутся на фрагменты удобного размера для индекса и контекстного окна.
• Построение векторного индекса. Для каждого фрагмента считается эмбеддинг; по ним организуется поиск «похожих» кусков по смыслу запроса.
• Retrieval. По пользовательскому вопросу выбираются наиболее релевантные фрагменты из индекса.
• Generation. Выбранные фрагменты подставляются в промпт (вместе с инструкцией и вопросом), и LLM формулирует ответ, опираясь на этот контекст.

Детали реализации (какой энкодер, какой векторный стор, сколько чанков подмешивать) сильно влияют на качество — но логика «найти → подставить → сгенерировать» остаётся общей.

Чанкование — разбиение документов на небольшие части. Эти куски — базовые единицы индексации и поиска: именно их векторизуют и именно их доставляют в промпт.

• В контекст модели попадают фрагменты, а не целые документы целиком — иначе не уложиться в окно и не потерять точность поиска.
• Качество нарезки напрямую влияет на доступность фактов: если смысловой блок разрезан посередине, ретривер может не найти нужный кусок; если чанк огромный — в нём много шума, падает точность попадания в запрос.

На практике подбирают размер чанка, перекрытие между соседними кусками и иногда более умное деление по структуре (заголовки, абзацы), а не только «каждые N символов».

Условно выделяют «наивный» и «продвинутый» уровень зрелости пайплайна — граница размыта, но названия помогают ориентироваться.

• Naive RAG: запрос → поиск ближайших чанков → они сразу передаются в модель без дополнительной обработки. Просто собрать, но качество сильно зависит от качества корпуса, чанков и эмбеддингов.
• Advanced RAG: добавляют шаги вокруг retrieval и генерации: переформулирование или расширение запроса, переранжирование кандидатов отдельной моделью или кросс-энкодером, очистка от дубликатов и пересекающихся кусков, иногда фильтрация по метаданным. Цель — выше точность и полнота подмешиваемого контекста.

Для учебного и исследовательского прототипа часто начинают с naive и усложняют пайплайн там, где видны типичные ошибки: «не тот абзац», «дубли», «запрос сформулирован не так, как в документе».

RAG внедряют там, где ответ нужно строить по заданному набору документов — внутренним, клиентским или личным — а не только по «памяти» модели из обучения.

• Компании. Базы знаний, регламенты, скрипты поддержки: сотрудник или клиент задаёт вопрос, система находит релевантные фрагменты и формулирует ответ с опорой на актуальные тексты организации.
• Разработчики и продуктовые команды. Чат-боты и ассистенты поверх документации, вики, тикетов: снижается нагрузка на «угадать» API по обрывкам из интернета — контролируемый корпус задаёт границы.
• Учёба и наука. Работа с подборкой статей, конспектами и PDF: удобно задавать вопросы по материалам курса или обзора литературы, не подменяя проверку источников.
• Отраслевые сценарии. Юридические, медицинские, финансовые и другие домены, где важна привязка к текстам компании или регуляторики — всегда с человеческой верификацией и политиками доступа к данным.