Урок 09. Retrieval-Augmented Generation (RAG)

📁 Блок: Мультимодальность/RAG/Fine-tuning ⏱️ Время изучения: ~80 мин 🎯 Сложность: Средняя
#rag #embeddings #langchain #llm

⚡ Кратко: зачем нужен RAG

Retrieval-Augmented Generation — это способ дать LLM внешний контекст: найти релевантные фрагменты в документах и передать их модели вместе с вопросом пользователя.

  • Обычная LLM отвечает по своим обученным знаниям и может устаревать.
  • RAG добавляет шаг поиска: вопрос → эмбеддинг → vector store → релевантные чанки.
  • Ответ строится не «из памяти модели», а по найденному контексту.
  • Хороший RAG хранит источники, метаданные и умеет сказать «в контексте нет ответа».
  • Основные риски: плохие чанки, слабый retrieval, устаревшие эмбеддинги и prompt injection из документов.
# mini_rag.py — главная идея
docs = vector_store.similarity_search(question, k=3)
context = "\n\n".join(doc.page_content for doc in docs)
answer = chain.invoke({"context": context, "question": question})

📖 О чём этот урок

В уроках 04–05 мы уже видели эмбеддинги, FAISS, LangChain и вопрос-ответ по документам. Урок 09 собирает это в целостную архитектуру RAG: как подготовить знания, найти нужные фрагменты и заставить LLM отвечать по этим фрагментам, а не выдумывать.

Идея урока. LLM похожа на сильного автора, но ей нужен «библиотекарь»: компонент retrieval находит актуальные и доменные материалы, а модель формулирует ответ на их основе.

Что изучим

  • Что такое Retrieval-Augmented Generation и какие ограничения LLM он закрывает
  • Архитектуру RAG: источники → чанки → эмбеддинги → vector store → retrieval → prompt → LLM
  • Зачем нужны векторные базы данных и чем семантический поиск отличается от keyword search
  • Как собрать учебный RAG на LangChain, FAISS и Google Gemini
  • Что изменилось в современном стеке: LCEL вместо LLMChain, новые модели Gemini и эмбеддингов
  • Типичные ошибки: плохое разбиение, нет источников, галлюцинации, prompt injection из найденного текста

📚 Что повторить перед изучением

🎯 Что изучать дальше