Created by AIImproved by people
Riqli · living documents · updated continuously
Where AI knowledge meets human practice.
Share with friends
Введение
Аннотация. Современные языковые модели хранят знания в своих весах, но эти знания статичны и ограничены датой обучения. RAG (Retrieval-Augmented Generation) решает эту проблему, подключая к LLM внешнюю базу знаний. Вместо того чтобы полагаться на память модели, RAG в момент запроса находит в корпоративных документах, базах знаний или API самую свежую и релевантную информацию и подставляет её в промпт. Такой подход устраняет галлюцинации, делает ответы проверяемыми и позволяет модели работать с данными, которых не было в её обучении. Данный курс посвящен инженерным аспектам построения RAG-пайплайнов: от извлечения данных до финальной генерации. Вы научитесь проектировать пайплайны обработки данных, выбирать архитектуру векторных хранилищ и настраивать семантический поиск, чтобы создавать надежные и быстрые системы на основе генеративного ИИ.
Цель курса. После прохождения курса вы сможете самостоятельно спроектировать и реализовать production-ready RAG-пайплайн, который эффективно обрабатывает миллионы документов, дает точные ответы на сложные вопросы и устойчив к изменениям в данных, используя современный стек инструментов, включая Azure AI Search, векторные базы данных и фреймворки оркестрации.
Результаты обучения.
- Знать: архитектуру RAG, виды эмбеддингов и метрик близости, стратегии чанкинга, методы пост-обработки (переранжирование, фильтрация).
- Уметь: проектировать пайплайн извлечения и предобработки данных, настраивать индексы (IVFFlat, HNSW), писать гибридные запросы (вектор + полнотекстовый поиск), использовать фреймворки (LangChain, Semantic Kernel).
- Владеть: методами оценки качества RAG, техниками оптимизации задержек и стоимости, подходами к обеспечению безопасности (PII, фильтрация).
Для кого этот курс.
Курс предназначен для инженеров данных, ML-инженеров и разработчиков приложений, которые хотят внедрить ИИ-функции в свои продукты. Он будет полезен тем, кто уже знаком с основами Python и базами данных, но хочет систематизировать знания о RAG и освоить лучшие практики.
Курс НЕ предназначен для бизнес-аналитиков или менеджеров без технического бэкграунда, так как требует выполнения кода и настройки инфраструктуры. Также он не подойдет тем, кто ищет готовое «коробочное» решение без необходимости кастомизации.
Модуль 1. Основы RAG: архитектура и компоненты
Что такое Retrieval-Augmented Generation (RAG). RAG — это архитектурный паттерн, который улучшает ответы больших языковых моделей (LLM) путем добавления внешнего контекста. В классическом пайплайне системный промпт дополняется релевантными документами, найденными в базе знаний. Это решает проблему «закрытости» знаний LLM, позволяя отвечать на вопросы о внутренних документах компании, новостях или специфичных данных. RAG превращает общую модель в эксперта в узкой области. Основные преимущества: актуальность ответов, снижение галлюцинаций, возможность цитирования источников и контроля доступа к данным. Архитектура включает индексацию (подготовка данных, векторизация, создание индекса) и поиск (запрос, ранжирование, синтез ответа). В основе лежит принцип «найди, добавь, сгенерируй».
Эволюция поисковых систем: от TF-IDF к семантическому поиску. Традиционные системы поиска, такие как TF-IDF и BM25, основаны на совпадении лексем (ключевых слов). Они не понимают смысла: запрос «автомобиль» не найдет документ про «машину». Семантический поиск решает эту проблему с помощью эмбеддингов — числовых векторов, которые представляют смысл текста. Сравнивая векторы запроса и документа, мы находим семантически близкие результаты. Сначала появились модели типа Word2Vec, затем — трансформерные модели (BERT, Sentence-BERT), которые генерируют контекстные эмбеддинги. Это позволило искать по смыслу, поддерживать многоязычность (текст на одном языке находит смысл на другом) и обрабатывать разные модальности (текст, изображения). RAG использует этот семантический поиск как основу для извлечения контекста.
Компоненты RAG-пайплайна. Полный RAG-пайплайн состоит из двух основных фаз: индексация и поиск/генерация. Фаза индексации включает: сбор корпуса документов, парсинг (извлечение текста из PDF, HTML, Word), очистку и предобработку, нарезку на чанки (фрагменты), генерацию эмбеддингов с помощью модели-энкодера (например, text-embedding-3-large или sentence-transformers/all-MiniLM-L6-v2), и сохранение в векторную базу данных (Azure AI Search, PostgreSQL pgvector, LanceDB) вместе с метаданными. Фаза поиска: пользовательский запрос эмбеддится той же моделью, выполняется поиск ближайших соседей (kNN/ANN) в векторном индексе, и найденные чанки передаются в промпт LLM. Промпт обычно содержит системную инструкцию и контекст. LLM генерирует ответ, используя предоставленные документы, что обеспечивает его фактическую точность и релевантность.
Роль данных в RAG: качество и контекст. Качество ответа RAG напрямую зависит от качества данных. Плохо структурированные, шумные или устаревшие данные ведут к неверным ответам. Критически важны: релевантность корпуса (документы должны содержать ответы на возможные вопросы), свежесть данных (особенно для новостных и финансовых приложений) и полнота покрытия тематик. Размер данных влияет на задержки и стоимость. Для больших корпусов (миллионы документов) требуется эффективная индексация и гибридные подходы. Также важен контекст: информация может быть избыточной или противоречивой, поэтому требуются стратегии дедупликации и фильтрации. Управление данными составляет 80% успеха RAG-проекта.
Модуль 2. Инженерия данных: от сырых файлов к чистым чанкам
Парсинг документов: извлечение текста из сложных форматов. Первый шаг индексации — извлечение неструктурированного текста из сырых файлов. Для PDF часто требуется OCR (например, Tesseract) для распознавания сканированных страниц. Для HTML используются парсеры вроде BeautifulSoup и lxml, которые удаляют теги и навигационные элементы. Библиотеки для Word (docx) и PowerPoint (pptx) также доступны. Ключевая задача — сохранить логическую структуру: заголовки, таблицы, списки. Если этого не сделать, смысл текста может быть искажен. На этапе парсинга также извлекаются метаданные (автор, дата, путь к файлу), которые позже помогут в фильтрации и поиске. В сложных пайплайнах используются специализированные решения, такие как Unstructured.io или Azure AI Document Intelligence, которые поддерживают десятки форматов.
Очистка и нормализация текста. После парсинга текст часто содержит шум: лишние пробелы, спецсимволы, табуляции. Очистка включает: приведение к нижнему регистру (lowercasing) для снятия чувствительности эмбеддингов к регистру (например, чтобы «Cheetah» и «cheetah» обрабатывались одинаково); удаление стоп-слов (предлогов, союзов), хотя нужно быть осторожным: слово «not» несет смысловую нагрузку; исправление опечаток; удаление Unicode-символов для снижения размерности; нормализацию аббревиатур (расшифровка «т.е.» до «то есть»). Эти шаги повышают качество векторов, уменьшая шум, который может искажать семантическую близость. Стоит сохранять сырую версию чанка отдельно для отображения пользователю и использовать очищенную версию для индексации.
Стратегии чанкинга (нарезки) документов. Чанкинг — ключевой этап, от которого зависит точность поиска. Документ разбивается на фрагменты, которые поместятся в контекст LLM (обычно 512-2048 токенов). Основные стратегии: Фиксированный размер — простой, но часто разрывает предложения на полуслове, теряя контекст. Семантический чанкинг — разбивает по границам абзацев или предложений, используя эвристики (точка, воплощенный символ). Рекурсивный чанкинг — пытается найти оптимальную границу на основе заданного размера и переполнения. С использованием моделей — определения границ семантических абзацев через эмбеддинги (дорого). Рекомендуется начинать с рекурсивного чанкинга с перекрытием (overlap) в 10-20% от размера чанка, чтобы ключевой контекст не терялся на границах. Пример: Chunk size: 512 токенов, Overlap: 100 токенов.
Обогащение данных и извлечение метаданных. Простого текста в чанке часто недостаточно. Обогащение добавляет контекстную информацию. Это может быть: извлечение ключевых слов и сущностей (имена, даты, продукты) с помощью моделей NER (например, spaCy, Azure AI Language), присвоение тегов на основе семантики (медицина, финансы), определение тональности. Метаданные — это структурированные поля, которые хранятся вместе с чанком: имя файла, URL, дата создания, автор, номер страницы, раздел документа. Они позволяют выполнять фильтрацию до или после векторного поиска (например, искать только в документах за последний год). Также можно использовать LLM для автоматического создания краткого резюме чанка (summary) для улучшения поиска по ключевым словам. Это повышает точность RAG, сужая область поиска до релевантных сегментов.
Дедупликация документов. В корпусе часто встречаются дубликаты: одна и та же статья в разных папках, черновики блогов, одинаковые спецификации. Это приводит к повторению информации в чанках, что может зашумлять результаты и увеличивать стоимость. Простая стратегия — фильтрация по метаданным (одинаковый заголовок и дата создания). Более сложная техника — MinHash (локально-чувствительное хеширование) для выявления семантических дубликатов. Алгоритм строит сигнатуры документов на основе n-грамм и находит пары с похожими сигнатурами. Затем можно оставить самую «лучшую» версию дубликата (самую свежую или с максимальным авторитетом). Реализация MinHash доступна в библиотеке Spark MLlib, что делает её пригодной для обработки больших данных.
Фильтрация вредоносного или нерелевантного контента. Не все документы в корпусе полезны. Некоторые содержат PII (персональные данные), токсичный язык или просто устаревшую информацию. Перед индексацией стоит внедрить механизмы фильтрации. Например, классификатор токсичности (через Azure Content Safety или Hugging Face) может пометить чанки с высоким риском. Алгоритмы обнаружения PII (например, Presidio или Azure AI Language) помогут удалить или замаскировать чувствительные данные, чтобы случайно не «утечь» их через LLM. Также следует фильтровать документы, которые не отвечают на бизнес-вопросы (например, технические артефакты, черновики). Этап фильтрации повышает безопасность RAG-приложения и снижает шум в ответах.
Модуль 3. Векторные хранилища, индексы и эмбеддинги
Что такое векторная база данных и зачем она нужна. Векторная база данных — это специализированное хранилище для векторов (массивов чисел), которое позволяет эффективно искать ближайших соседей с помощью алгоритмов приближенного поиска (ANN). В отличие от стандартных SQL БД, она оптимизирована не для точных сравнений, а для поиска по сходству (cosine similarity, L2 distance, dot product). В RAG векторы хранят семантический смысл документов. Когда приходит вопрос, мы генерируем его вектор и ищем в БД самые похожие векторы документов. Это позволяет находить информацию, не содержащую ни одного ключевого слова из запроса. Популярные векторные БД: Azure AI Search (облачный сервис), pgvector (расширение для PostgreSQL), LanceDB, FAISS (библиотека), Qdrant и Pinecone. Выбор зависит от масштаба, бюджета и экосистемы.
Типы индексов для векторного поиска. Чтобы искать среди миллионов векторов за миллисекунды, используются приближенные алгоритмы. Самые популярные: IVFFlat (Inverted File Flat) — делит данные на кластеры (списки) и ищет только в ближайших кластерах. Хорош для сбалансированной точности/скорости. HNSW (Hierarchical Navigable Small World) — строит граф многоуровневой структуры для быстрого перехода по близким соседям. Обеспечивает высокую точность, но медленнее строит индекс. DiskANN — разработан для SSD-накопителей и позволяет обрабатывать миллиардные масштабы на стандартном оборудовании, используя сжатие и пирамидальную структуру. Выбор типа индекса влияет на время индексации, задержку поиска и точность. Например, в PostgreSQL с pgvector можно использовать IVFFlat и HNSW, а в Azure AI Search — HNSW.
Гибридный поиск: вектор + полнотекстовый. Векторный поиск хорошо ищет по смыслу, но может пропустить специфический термин (например, «X-100»). Полнотекстовый поиск (BM25) идеален для точных совпадений. Гибридный поиск объединяет оба подхода. Запрос выполняется одновременно к векторному индексу и к текстовому индексу (например, на основе Lucene). Результаты объединяются с помощью реранжирования (например, перекрестный энкодер, такой как cross-encoder/ms-marco-MiniLM-L-6-v2) для получения единого ранжированного списка. Это дает лучшую релевантность, особенно в больших корпусах. Azure AI Search поддерживает гибридный поиск «из коробки», позволяя отправить один запрос с вектором и ключевыми словами. Это базовый паттерн для продакшн-приложений.
Хранение и индексация векторов в SQL (PostgreSQL pgvector). Расширение pgvector превращает PostgreSQL в полноценную векторную базу данных. Оно добавляет тип данных vector и операторы (, <#>) для вычисления расстояний. Преимущество: данные могут быть в одной системе с транзакционными данными, что упрощает поддержку. Пример создания таблицы:
CREATE TABLE items (id bigserial PRIMARY KEY, content text, embedding vector(1536));CREATE INDEX ON items USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);SELECT * FROM items ORDER BY embedding <-> query_embedding LIMIT 5;Векторный поиск в Azure AI Search. Azure AI Search — это облачный поисковый сервис, поддерживающий векторы, гибридный поиск и семантическое ранжирование. Индексы создаются в Azure Portal или через SDK (Python, .NET). Работа идет с полями типа Collection(Edm.Single), где хранятся векторы. Сервис интегрируется с Azure OpenAI для автоматической векторизации при индексации через навыки (skills). Поддерживает HNSW для ближайших соседей и фильтрацию по метаданным. Пример кода на Python для создания клиента и запроса:
from azure.search.documents import SearchClient
client = SearchClient(endpoint, index_name, credential=DefaultAzureCredential())
results = client.search(search_text=None, vector_queries=[VectorQuery(vector=query_vector, fields='embedding', k=3)])Модели эмбеддингов: выбор, сравнение, стоимость. Качество эмбеддингов определяет качество поиска. Модели делятся на: Open-source (sentence-transformers: all-MiniLM-L6-v2, multi-qa-mpnet-base-dot-v1) — хороши для локальной разработки. Проприетарные: text-embedding-3-small и text-embedding-3-large от OpenAI, ada-002 (устаревшая) — высокое качество, но платные и передают данные в облако. На русском языке лучше работают модели, обученные на русском корпусе, например, ruBERT от DeepPavlov или LaBSE (многоязычная). Выбор зависит от бюджета, языка данных и допустимой задержки. Размерность вектора влияет на стоимость хранения и скорость: у text-embedding-3-large 3072 измерения, у all-MiniLM-L6-v2 — 384. Тестируйте качество на ваших данных через MIRACL или собственные сеты вопросов.
Модуль 4. Продвинутые техники поиска и ретривера
Ретрайвер и его роль в RAG. Ретрайвер (retriever) — это компонент, который выбирает релевантные чанки из векторной БД по запросу. Простой ретрайвер использует поиск ближайших соседей (kNN) с фиксированным числом k (часто 3-5). Однако он может пропустить полезную информацию, если она лежит далеко в пространстве эмбеддингов. Более сложные ретрайверы используют: Multi-Query Retriever — генерирует несколько версий запроса для улучшения поиска; Parent Document Retriever — возвращает родительский документ целиком, а не маленькие чанки. Также ретрайвер может применяться в комбинации с реранкером (cross-encoder), который заново ранжирует найденные чанки по релевантности, используя более ресурсоемкую модель. Это повышает точность финального поиска.
Переписывание запросов (Query Rewriting). Пользователи часто задают расплывчатые или короткие вопросы. Переписывание запроса улучшает формулировку перед тем, как передавать её в эмбеддинг-модель. Стратегии: Расширение аббревиатур (превратить «ИИ» в «искусственный интеллект»), удаление жаргона или сленга, парафраз (переформулировка вопроса более формально). Специальная техника: HyDE (Hypothetical Document Embeddings) — модель генерирует гипотетический документ-ответ на вопрос, затем эмбеддится именно этот документ, а не сам вопрос, и по нему ищутся похожие чанки. Это часто улучшает поиск, так как гипотетический ответ по стилистике ближе к документам в базе, чем вопрос пользователя.
Субзапросы и маршрутизация запросов. Сложные вопросы с несколькими концепциями лучше разбивать на простые субзапросы. Например, вопрос «Сравните подходы к постановке целей в ИТ-проектах и классическую методологию» разбивается на: «Что такое постановка целей в ИТ-проектах?» и «Что такое классическая методология постановки целей?». Каждый субзапрос обрабатывается отдельно, результаты объединяются. Маршрутизатор запросов (Query Router) выбирает, какой индекс или базу знаний использовать для данного вопроса. Например, вопросы по продукту отправляются в продуктовую БД, общие вопросы — в корпоративную wiki. Это позволяет специализировать индексы и повышает точность, так как каждый индекс оптимизирован под свой тип данных. Реализации через логику на LLM.
Пост-обработка результатов (Re-ranking). После получения списка релевантных чанков от ретрайвера (обычно 10-20 чанков) применяется реранкер для финального отбора (топ-3-5). Векторный поиск находит кандидатов, но точность оценки сходства у него ограничена. Реранкеры — это кросс-энкодеры (например, cross-encoder/ms-marco-MiniLM-L-6-v2), которые принимают на вход пару (запрос, чанк) и выдают скор релевантности от 0 до 1. Это дорогая операция, но очень точная. Также на этом этапе применяются: фильтрация по метаданным (показывать только документы с высоким авторитетом), дедупликация чанков (удаление повторов), адаптация к контексту LLM (объединение смежных чанков в один блок). Этот шаг критичен для качества финального ответа.
Графовый RAG (GraphRAG). GraphRAG — это развитие идеи RAG, использующее графовые структуры знаний для улучшения понимания связей между сущностями. Вместо простого поиска по чанкам, создается граф знаний (извлекаются сущности и отношения между ними). Поиск идет по графу, позволяя системе ответить на вопросы, требующие логических выводов и связей, например «Как влияет политика А на продукт Б?». Это решает проблему «пропущенного контекста» в классическом RAG. Реализация возможна через библиотеки вроде Neo4j в связке с LangChain. GraphRAG показывает лучшие результаты для аналитики и сложных сценариев, но сложнее в построении.
Модуль 5. Оркестрация и фреймворки (LangChain, Semantic Kernel)
LangChain: построение цепочек для RAG. LangChain — популярный фреймворк для создания LLM-приложений. Он абстрагирует шаги RAG-пайплайна: загрузка документов (DocumentLoader), нарезка (TextSplitter), векторизация (Embeddings), хранение (VectorStore), ретривер (Retriever) и LLM (ChatOpenAI). Простейшая цепочка RAG:
from langchain.chains import RetrievalQA
from langchain_openai import OpenAI
qa_chain = RetrievalQA.from_chain_type(
llm=OpenAI(),
chain_type='stuff',
retriever=vector_store.as_retriever(search_kwargs={'k': 3})
)
answer = qa_chain.invoke({'query': 'Как использовать векторы в SQL Server?'})Semantic Kernel от Microsoft. Semantic Kernel (SK) — это альтернатива LangChain от Microsoft для интеграции ИИ в C# и Python. SK использует концепцию «плагинов» и «цепочек» (pipelines). Он включает интеграцию с SQL Server в качестве векторного хранилища через коннектор SqlServerVectorStore. Это позволяет использовать существующие базы SQL Server для RAG без миграции в отдельные сервисы. Пример конфигурации на C#:
builder.AddSqlServerVectorStore(connectionString, tableName: 'knowledge_base', vectorColumnName: 'embedding');Автоматическая векторизация в Manticore Search. Manticore Search — это поисковый движок (форк Sphinx), который добавил поддержку Auto Embeddings с версии 13.11.0. Это позволяет генерировать эмбеддинги непосредственно внутри БД при вставке данных, используя предопределенные модели (OpenAI, Hugging Face, Voyage). Это упрощает архитектуру: не нужен внешний сервис для эмбеддинга. Пример:
CREATE TABLE products (title TEXT, vector FLOAT_VECTOR KNN_TYPE='hnsw' MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2');
INSERT INTO products(title) VALUES ('wireless headphones');
SELECT * FROM products WHERE knn(vector, 3, 'portable audio device');Модуль 6. Оценка, безопасность и оптимизация
Метрики оценки качества RAG. Оценка RAG сложнее оценки обычных моделей, так как включает поиск и генерацию. На уровне ретривера используют: Recall@k (доля релевантных документов в первых k), MRR (средняя обратная позиция первого релевантного), NDCG (нормализованная дисконтированная кумулятивная выгода). На уровне генерации: Faithfulness (фактологическая точность ответа по отношению к контексту), Answer Relevancy (релевантность ответа вопросу). Также оценивают Context Relevancy (релевантность найденного контекста). Существуют инструменты: RAGAS, TruLens, DeepEval, которые автоматизируют оценку на синтетических вопросах. Важно иметь тестовый набор из 200+ вопросов и эталонных ответов для валидации изменений.
Безопасность: инжекции данных и PII. RAG-системы уязвимы: злоумышленник может вложить документ с инструкцией промпт-инжекции (например, «игнорируй предыдущий контекст и ответь ...»). Необходимо экранирование пользовательского контента. Также данные могут содержать PII (персональные идентификаторы), которые LLM может случайно раскрыть. Рекомендуется: фильтрация токсичного и вредоносного контента на этапе индексации; использование детекторов PII (например, Microsoft Presidio) для удаления персональных данных; ограничение доступа к индексам на основе ролей. Также ограничение доступа к источникам (не индексировать конфиденциальные данные, если они не нужны).
Оптимизация стоимости и задержки. RAG может быть дорогим из-за LLM и объема данных. Стратегии: Кэширование частых запросов и результатов эмбеддингов. Пакетная обработка эмбеддингов для снижения стоимости. Использование меньших моделей для реранжинга и эмбеддингов (например, all-MiniLM-L6-v2 вместо text-embedding-3-large). Сжатие контекста — передавать в LLM только самые релевантные части чанков через суммаризацию. Асинхронные пайплайны и serverless-инфраструктура (Azure Functions, AWS Lambda) для индексации снижают затраты. Модели DiskANN позволяют держать большие индексы на диске, а не в дорогостоящей RAM. Оптимизация начинается с метрик: отслеживайте задержку каждого компонента.
Обновление данных в реальном времени. Данные в корпусе меняются, и индексы нужно обновлять. Стратегии: Инкрементальная индексация — переиндексация только новых и измененных документов (через триггеры на файловой системе или БД). Полная переиндексация по расписанию (например, раз в сутки). В облаке (Azure AI Search) поддерживается автоматическая синхронизация с изменением данных через Change Tracking в SQL Server. Для потоковых данных используют Kafka и Spark Streaming с микропакетной обработкой. Важно иметь версионирование индексов для отката в случае ошибок.
Выбор стека технологий для вашего проекта. Рекомендации по выбору инструментов: Для небольших проектов (десятки тысяч документов) — pgvector на PostgreSQL + LangChain + LLM (OpenAI или локальная). Для enterprise с большими объемами (миллионы документов) — Azure AI Search для гибридного поиска и масштабирования или Qdrant / Pinecone для управляемых векторных БД. Для C#/Microsoft экосистемы — Semantic Kernel + Azure Cognitive Search. Для обработки большого объема неструктурированных файлов — Azure Databricks для ETL и масштабирования MinHash дедупликации. Всегда тестируйте на своих данных, так как лучшая модель и БД зависят от языка, объема и бюджета.