RAG

RAG (Retrieval-Augemnted Generation) или дополненная поиском генерация это архитектурный подход который позволяет агенту (да и в целом LLM) использовать не только зашитые при обучении “знания” но и обращаться к специализированным (обычно векторным) базам данных для запроса релевантной информации, встраиванию ее в prompt и уже в таком, обагащеном виде формировать ответ.

Ключевое свойство эмбеддингов – семантически близкие тексты получают похожие векторные представления, что делает возможным поиск по смыслу, а не только по точным совпадениям слов. (Душкин, 2025, p. 27) (pdf)

Косинусное сходство

Косинусное сходство - главная мера близости в этом пространстве. Оно показывает, насколько векторы направлены в одну сторону, игнорируя их длину. Два слова с косинусным сходством, близким к 1, – практически синонимы, близким к 0 – никак не связаны. Косинус принимает значение 1 нимы, близким к 0 – никак не связаны. Косинус принимает значение 1 для угла в 0 градусов и 0 для прямого угла (90 градусов), поэтому косинусное сходство так сходство так удобно.» (Душкин, 2025, p. 50) (pdf)

Ссылка на оригинал

При поступлении запроса агенту при таком подходе он должен:

• Преобразовать сам запрос в векторное представление используя специализированные эмбединг модели.
• Запросить в векторной БД релевантные полученному вектору документы.
• Встроить их в prompt и уже в таком дополненном виде отправить на генерацию ответа.

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

Основные шаги процесса

Подготовка хранилища векторов важный процесс и должен быть спроектирован с самого начал.

Выбор модели эмбединга критически важен! Также важны размеры чанка (части что отправляется на векторизацию и последующее хранение в БД) так как маленькие чанки не будут содержать необходимого контекста, а большие могут запутать модель и зря занимать место в контексте. Хорошей практикой является разбивка с перекрытием чанков т.е. каждый следующий может и должен захватывать хвост предыдущего.

• retriever - модуль получающий информацию из внешнего хранилища.
• reranker

Современные RAG-системы часто включают дополнительный этап переранжирования (reranking) – повторного ранжирования найденных фрагментов. Специализированные модели-реранкеры анализируют найденные чанки в контексте конкретного запроса и могут изменить их порядок, более точно оценив релевантность. Это особенно важно, когда векторный поиск находит семантически близкие, но не совсем подходящие фрагменты. Page 26

«Реранкер (reranker) – опциональный, но важный компонент продвинутых RAG-систем. Специализированные модели анализируют найденные фрагменты в контексте конкретного запроса и переранжируют их, более точно оценивая релевантность. Это особенно эффективно при работе со сложными или многоаспектными запросами.» (Душкин, 2025, p. 34) (pdf)

• generator - модуль отвечающий за общение с LLM. Температура запроса лучше выставлять поменьше, чтобы ответы были более детерминированы и меньше галлюцинаций подмешивалось в контекст.

В простейшем случае можно обойтись одним проходом этой цепочки, но можно и вызывать retriever многократно после рассуждений модели.

Архитектура промпта при использовании RAG

Контекст: [найденные фрагменты]

Вопрос: [запрос пользователя]

Ответь на вопрос, основываясь на предоставленном контексте.

Пример на python формирование промпта с вшитым контекстом:

def create_prompt(self, query: str, chunks: List[Dict]) -> str: 
	"""Формируем промпт с контекстом"""
	context = ""
	for i, chunk in enumerate(chunks, 1):
		similarity_percent = int(chunk['similarity'] * 100)
		context += f"\n--- Фрагмент {i} (релевантность {similarity_percent}%) ---\n"
		context += chunk['text']
		context += "\n"
	prompt = f"""Контекст:
{context}
 
Вопрос: {query}
 
Ответ:"""
	return prompt

Виды RAG

• Наивный RAG - описан выше. Просто векторизация запроса, поиск документов, вставка в prompt.
• Продвинутый RAG - добавляет этапы предварительной и последующей обработки. Перед поиском запрос может быть расширен синонимами, декомпозирован на подвопросы или переформулирован для лучшего сопоставления с документами.
• Модульный RAG - Весь pipeline разбит на модули (хотя он всегда разбит на модули?):
  • Маршрутизации (routing) - принимает решение о том, к каким источникам данных следует обратиться (вектора, API и так далее).
  • Памяти (memmory) - подсистема хранения данных о предыдущих взаимодействиях.
  • Слияния (Fusion) - реализует множественные запросы через их переформулированния исходного, затем сливает результаты в один.

Векторные представления и эмбеддинги

Определение

Векторное представление, или эмбеддинг (embedding, встраивание), – это способ превращения текста в числа, но не простое кодирование букв, а перевод смысла в математический язык. Каждое слово становится точкой в многомерном пространстве, в котором координаты отражают различные аспекты значения (то есть встраивается в пространство, отсюда и название). (Душкин, 2025, p. 49) (pdf)

Классический пример:

$$\text{Вектор <Король>}-\text{Вектор<Мужчина>}+\text{Вектор<Женщина>}=\text{Вектор<Королева>}$$

Иными словами, и это самое интересное, получается, что математика начинает оперировать абстрактными понятиями!

Фундаментальные принципы работы с векторами

Фундаментальные принципы работы с векторами

1. Принцип единообразия. Любой объект будь то короткое слово или длинный абзац текста кодируются в вектор одинаковой длины, что позволяет сравнивать между собой и искать сходство любых двух текстовых фрагментов.
2. Принцип плотности. Векторные представления - это “плотные” векторы, в которых каждая координата может быть любым вещественным числом. В отличие от разреженных представлений, когда большинство координат равны нулю, здесь каждое измерение несёт информацию о смысле.
   • Прямая цитата. Пока сам не очень понимаю.
3. Принцип контекстуальности. Модели эмбеддеры умеют понимать контекст вокруг фрагмента. Таким образом “ключ” когда он от замка и “ключ” когда он родник получат совсем разные векторы.
4. Принцип композиционности. Векторы можно комбинировать для создания представлений более сложных конструкций. Вектор предложения может быть получен усреднением векторов слов или более сложными способами, учитывающими синтаксис и семантику.
5. Принцип стабильности. Векторные представления должны быть устойчивыми - небольшие изменения в тексте не должны кардинально менять вектор. Опечатки, синонимы, перефразирование должны давать похожие векторы для сохранения смысловой целостности.

Ссылка на оригинал

Вектор обычно сохраняются в специализированную БД. Но по большому счёту (за исключением наличия или отсутствия специализированных индексов для вектором) подходят любые СУБД реализующие функции типа array_cosine_similarity(array1, array2). Важно обратить внимание, что в такую СУБД сохраняются не только сами вектора но и другая метаинформация о векторе вплоть до исходного документа если это применимо например по размеру.

Некоторые векторные БД

• Chroma - питон + js. Рекомендуется как простейшие решение.
• Qdrant - Написан на Rust. Быстрый, Open Source.
• Weaviate - вектора + графовое представление.
• Milvus - большой, серьезный распределнный.
• pgvector - экстеншен для PostgreSQL, что заносит в него ряд функций и индексов для работы с векторами.
• DuckDB - чисто моя идея. Из коробки есть нужные функции, эмбеддед. Через расширение можно даже индексы строить но пока не персистенто.

Подходы к сегментированию документов

• Фиксированное окно. Просто нарезаем документы на куски фиксированного размера. Из плюсов - очень просто. Минус в том, что мы забиваем на семантические границы.
• Скользящее окно. Примерно то же самое, что и фиксированное но каждое последующее захватывает часть предыдущего, что сохраняет контекстную связь за счет чуть увеличенного объёма.
• Семантическое сегментирование. Следуем логике текста и разбиваем на логические блоки и отдельные мысли. Требует достаточно сложного анализа.
• Структурное разделение. По границам блоков а-ля markdown.
• Адаптивное сегментирование. LLM сама решит как сегментируем документ.