Разборы · Статья: · Видео: · 20 мин

RAG простыми словами: как заставить языковую модель отвечать по вашей документации

Разбор выпуска Listen IT про RAG (Retrieval-Augmented Generation): что это, зачем нужно, как устроены два контура — подготовка данных и ответ на запрос, из чего собирается реальная архитектура, где RAG ломается, чем он отличается от fine-tuning и что такое agentic RAG.

ИИ Программирование
Смотреть на YouTube

Что такое RAG: Объясняем на примерах

Listen IT · 20 мин
Главы видео — нажми, чтобы перейти к моменту 9
  1. 0:00 Вступление и источники Выпуск собран из двух статей с Хабра плюс дополнения автора.
  2. 0:48 Что такое RAG Retrieval-Augmented Generation — модель сначала находит материалы во внешнем источнике, а уже потом отвечает.
  3. 3:25 Плюсы RAG Меньше галлюцинаций и часто дешевле, чем дообучать модель под каждое изменение данных.
  4. 4:28 Где применяют RAG Боты поддержки, внутренние корпоративные ассистенты, помощники разработчиков, юридические и compliance-консультации.
  5. 5:23 Как RAG устроен внутри Два контура: подготовка данных (парсинг → чанкинг → эмбеддинги → гибридный индекс → метаданные) и ответ на запрос (rewrite → ретривер → реранкер → сборка контекста → LLM).
  6. 9:14 Пример реальной архитектуры Ассистент для разработчиков, аналитиков и QA: ingestion-сервис, S3, chunking, embeddings, векторное хранилище, оркестратор, LLM-gateway и фронт.
  7. 15:28 Слабые места RAG Ломается не идея, а звенья: парсинг, чанкинг, ретривер, реранк, метаданные, промт.
  8. 16:09 RAG против fine-tuning RAG — для часто меняющихся знаний, fine-tuning — для изменения поведения модели.
  9. 17:38 Agentic RAG Многошаговый поиск: подзапросы, несколько индексов, сравнение версий — мощнее, но дороже и опаснее.

Коротко

RAG — это не модель, а инженерная система: перед ответом она находит нужные фрагменты в ваших источниках и просит модель ответить строго по ним, чтобы говорить про вашу компанию, а не про интернет вообще. Качество зависит не от «магии ИИ», а от слабейшего звена конвейера — парсинга, чанкинга, поиска, реранка, метаданных и промта.

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:17
Показать текст выжимки
Если коротко, это разбор про RAG — способ заставить обычную языковую модель отвечать по вашим документам, которых она никогда не видела при обучении. Главная мысль, которую стоит перевернуть в голове: RAG — это не модель. Это инженерная система вокруг модели. Сама модель только генерирует финальный ответ, а всё интересное происходит до неё: документы парсят, режут на смысловые куски, превращают в числовые векторы, складывают в гибридный индекс и по запросу находят нужный фрагмент. Значит, и качество ответа определяет не ум нейросети, а слабейшее звено конвейера: парсинг, чанкинг, поиск, реранк, метаданные и промт. Второе. RAG снижает галлюцинации, но не обнуляет их. Вы дали модели конкретный источник — и она реже выдумывает. Но если поиск вытащит мусор или устаревший документ, модель красиво и уверенно перескажет именно этот мусор. Поиск добавляет свой режим отказа: нашли не то — ответили не то. Третье. RAG и fine-tuning постоянно путают, но это не конкуренты. RAG нужен, когда знания часто меняются и лежат снаружи: документация, цены, политики. Fine-tuning — когда надо поменять поведение модели: формат, стиль, доменный язык. Свежую базу знаний дообучением грузить бессмысленно — придётся переучивать при каждом изменении. Что стоит поставить под сомнение: в разборе длинный контекст и RAG показаны почти как «или-или». На деле для небольших и статичных наборов документов иногда проще подать всё прямо в контекст, а в реальных продуктах fine-tuning и RAG чаще комбинируют, а не выбирают одно. И практический вывод. Начинайте с простого линейного RAG — найти, добавить в промт, ответить — и жёстко запретите модели выдумывать. К модному agentic RAG с многошаговым поиском переходите позже: он мощнее, но дороже и опаснее, и требует прав доступа, лимитов и логов на каждом шаге.

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

RAG — это способ заставить обычную языковую модель (как ChatGPT) отвечать по вашим личным или корпоративным документам, которых она никогда не видела при обучении. Перед ответом система сама находит нужные фрагменты в вашей базе знаний, вставляет их в запрос и просит модель ответить строго по ним. Так вы получаете ответ про вашу компанию, а не общие рассуждения из интернета.

Как ребёнку

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

Аналогия — «это как…»

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

Зачем это мне

RAG — самый частый способ прикрутить ИИ к реальному бизнесу: боты поддержки, внутренние ассистенты, помощники разработчиков. Понимая его устройство, вы отличите рабочий проект от красивой демки и заранее увидите, где он сломается — на парсинге, чанкинге, метаданных или промте.

Для тех, кто в теме

Разбор проходит весь конвейер: ingestion (парсинг PDF/Markdown/OpenAPI, дедуп, метаданные) → structure-aware chunking → эмбеддинги → гибридный индекс (вектор + keyword/полнотекст + метаданные + access-rules) → rewrite запроса → retriever (top-k) → reranker → сборка контекста с ограничивающим промтом → LLM за gateway. Опорные тезисы: источники как single source of truth, RAG ≠ модель, длинный контекст не заменяет retrieval, и переход к agentic RAG с многошаговым планированием — ценой контроля, трассировки и прав доступа.

Оценка видео

Чем выше — тем больше пользы на минуту

4.2

средняя из 5

Актуальность информации 4.7

RAG — базовая технология корпоративного ИИ 2026 года, а раздел про agentic RAG прямо отражает текущий сдвиг индустрии.

Доступность изложения 4.6

Сильная сторона выпуска: сложная инженерия объяснена на бытовых примерах (отпуск, отмена заявки) без жаргонного тумана.

Содержательность 4.3

Плотно: полный конвейер и реальная архитектура по слоям. Минус — заметные повторы, автор и сам шутит «100 раз про это говорили».

Практичность 4.2

Даёт рабочий чертёж системы и честный чек-лист слабых мест, но без критериев выбора конкретных технологий из длинного списка.

Инновационность идей 3.3

Это грамотная компиляция двух статей с Хабра, а не оригинальное исследование; свежим ощущается только блок про agentic RAG.

Кому будет полезно

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

Для бэкенд-разработчиков 4.7 /5

Вторая половина выпуска — это по сути пошаговый чертёж сервиса: ingestion, чанкинг, эмбеддинги, гибридный индекс, оркестратор и gateway. Можно брать как скелет реального проекта.

Для ML- и AI-инженеров 4.5 /5

Чётко разведены эмбеддинги, векторный и гибридный поиск, реранк и различие RAG vs fine-tuning — база, на которой строится любое прикладное решение с LLM.

Для системных аналитиков 4.4 /5

Показано, откуда берутся данные (Confluence, Jira, Swagger, ADR) и почему их структура и метаданные напрямую определяют качество ответов ассистента.

Для продакт-менеджеров и product owner-ов 4 /5

Помогает принять ключевое решение — RAG или fine-tuning, длинный контекст или поиск — и не заказать красивую демку, которая развалится в проде.

Для QA-инженеров и тестировщиков 3.9 /5

Сквозной пример в выпуске построен именно про тестировщика; видно, какие звенья ломаются и что проверять в RAG-ассистенте.

Для технических писателей 3.6 /5

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

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 RAG — это не модель, а инженерная система 9:05

Главный сдвиг в голове: RAG часто называют «моделью с доступом к данным», но это неверно. Модель здесь только генерирует финальный ответ, а всё остальное — парсинг, индекс, поиск, реранк, сборка контекста — это обычная инженерия вокруг неё. Значит и качество определяется инженерией, а не «умом» модели.

02 RAG снижает галлюцинации, но не обнуляет их 3:45

Дав модели конкретный источник, вы уменьшаете выдумки. Но если поиск вытащит мусор или устаревший документ, модель красиво и уверенно перескажет именно этот мусор. Retrieval добавляет собственный режим отказа: «нашли не то — ответили не то».

03 Длинный контекст не заменяет RAG 17:20

Соблазн «просто напихать сотни страниц в промт» не работает: это дорого, медленно и не всегда точно. RAG нужен не только из-за ограничений контекста, а чтобы отбирать, цитировать и фильтровать данные, учитывать права доступа и держать информацию актуальной.

04 RAG и fine-tuning решают разные задачи 16:09

Их постоянно путают, но это не конкуренты. RAG — когда знания часто меняются или лежат снаружи (документация, цены, политики). Fine-tuning — когда надо менять поведение модели: формат ответа, стиль компании, доменный язык. Свежую базу знаний дообучением грузить бессмысленно — придётся переобучать при каждом изменении.

05 Источники должны оставаться единой точкой правды 10:21

RAG не должен превращаться в новую базу знаний, куда всё скопировали и забыли обновить. Если документация живёт в GitHub, то GitHub и остаётся местом правды, а RAG лишь индексирует её. Иначе вы получите второй, тихо устаревающий источник.

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«RAG — это не модель. Это именно инженерная система, которая помогает модели отвечать по внешним источникам.»
Ключевая мысль всего выпуска — не путать RAG с самой языковой моделью. 9:05
«Если RAG будет находить какой-нибудь мусор или устаревший документ, неполный документ, то модель может красиво пересказать именно этот мусор.»
Про то, почему RAG снижает, но не убирает галлюцинации. 3:45
«Источники остаются единой точкой правды. То есть RAG не должен становиться новой базой знаний, куда всё скопировали и забыли обновлять.»
Принцип single source of truth в архитектуре RAG. 10:21
«Эмбеддинги — это такие числовые векторы, которые описывают смысл текста. Похожие по смыслу тексты оказываются ближе друг другу в векторном пространстве.»
Объяснение, как работает семантический поиск внутри RAG. 6:28
«RAG нам нужен не только из-за ограниченного контекста. Он нам нужен, чтобы отбирать, цитировать и фильтровать данные, принимать во внимание права доступа, обновлять всё время информацию и контролировать источники.»
Почему длинный контекст не отменяет RAG. 17:20
«Агентский RAG, конечно же, сложнее, он дороже и, на самом деле, даже опаснее, если дать агенту слишком много свободы.»
Честное предупреждение про моду 2026 года на agentic RAG. 18:16

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

1

Выбери RAG или fine-tuning осознанно

15 минут не потратишь бюджет на дообучение там, где хватило бы индексации документов

RAG — когда знания меняются и лежат во внешних источниках. Fine-tuning — когда надо изменить поведение модели: формат, стиль, доменный язык. Это разные инструменты, а не конкуренты.

Что делать

  1. 1 Выпиши, что именно ты хочешь: «модель знает свежие факты» или «модель ведёт себя иначе».
  2. 2 Если факты часто меняются — бери RAG и переиндексацию.
  3. 3 Если нужен стабильный формат/стиль/классификация — это кандидат на fine-tuning.
  4. 4 Часто честный ответ — комбинация: fine-tune под поведение + RAG под знания.
2

Режь документы по структуре, а не по символам

вечер ответы перестанут быть вырванными из контекста кусками

Чанкинг «по 1000 символов» рвёт смысл. Режь по структуре документа: раздел, endpoint, таблица, бизнес-правило, кодовый блок. Слишком крупно — много лишних тем в одном чанке, слишком мелко — теряется контекст.

Что делать

  1. 1 Определи естественные границы в документах: заголовки, разделы, методы API.
  2. 2 Храни связанное вместе: описание метода — вместе с параметрами и ошибками.
  3. 3 Добавь к чанку ссылку на исходный файл, чтобы можно было дать источник в ответе.
3

Ставь гибридный поиск, а не только векторный

полдня система начнёт находить и по смыслу, и по точным терминам — кодам ошибок, именам полей

Векторный поиск ловит смысл, но промахивается по точным совпадениям. Гибридный (вектор + поиск по ключевым словам + полнотекст) добирает названия полей, коды ошибок, номера статей — то, где важна буква, а не смысл.

Что делать

  1. 1 Подними индекс, который умеет и вектор, и keyword-поиск (Elasticsearch, Postgres+pgvector и т.п.).
  2. 2 Индексируй и эмбеддинг, и сырой текст фрагмента.
  3. 3 Проверь на запросах с точными терминами: находит ли конкретный endpoint или код ошибки.
4

Проставляй метаданные и права доступа к каждому чанку

день RAG перестанет показывать чужие документы и путать версии и страны

Без метаданных система не понимает, кому можно показать фрагмент, актуален ли он и к какой версии продукта относится. Права доступа — это отдельный слой, а не деталь: сервис, система, язык, версия, тип документа, access-rules.

Что делать

  1. 1 К каждому чанку добавь: источник, систему, версию, тип документа, права доступа.
  2. 2 Фильтруй кандидатов по метаданным до подачи в модель.
  3. 3 Проверь на пользователе без прав: не утекает ли закрытый документ.
5

Заложи жёсткий ограничивающий промт

30 минут модель перестанет отвечать «из головы», когда в источниках ответа нет

Финальный контекст — это не только найденные фрагменты, но и инструкция поведения. Явно запрети выдумывать и обяжи давать ссылки на источники.

Что делать

  1. 1 Добавь в промт: «Отвечай только по переданным источникам».
  2. 2 Добавь: «Если ответа нет в источниках — скажи, что информации недостаточно. Не выдумывай».
  3. 3 Обяжи модель в конце дать ссылки на использованные документы.
6

Начни с классического RAG, а не с agentic

10 минут на решение не утонешь в стоимости, отладке и рисках многошагового агента на старте

Agentic RAG умеет планировать поиск, разбивать вопрос на подзапросы и сравнивать версии — но он сложнее, дороже и опаснее. Чем больше шагов и инструментов, тем важнее контроль, права доступа, трассировка, лимиты и логи.

Что делать

  1. 1 Собери и стабилизируй линейный RAG: найти → добавить в промт → ответить.
  2. 2 Дойди до agentic только когда упрёшься в задачи вида «сравни две политики за год».
  3. 3 Перед агентом заложи логирование каждого шага, лимиты и жёсткие права доступа.

Сценарии применения

Как разные люди применяют это на практике

Я как Бэкенд-разработчик

Проблема: команда просит внутреннего ассистента по документации, а с чего начать — непонятно

Хочу: увидеть архитектуру RAG по слоям, а не абстрактную «магию ИИ»

Поможет: выпуск даёт готовый скелет: ingestion, чанкинг, эмбеддинги, индекс, оркестратор, gateway, фронт

Я как Продакт-менеджер

Проблема: подрядчик предлагает дорого «дообучить модель», и неясно, нужно ли это вообще

Хочу: понять разницу между RAG, fine-tuning и длинным контекстом

Поможет: разбор объясняет, что для меняющихся знаний дешевле и практичнее RAG, а fine-tuning — про поведение

Я как Системный аналитик

Проблема: знания размазаны по Confluence, Jira, Swagger и головам коллег

Хочу: оценить, можно ли собрать по ним единого ассистента

Поможет: видно, какие источники индексируются и почему их структура и метаданные решают всё

Я как QA-инженер

Проблема: ассистент по документации иногда уверенно врёт про поведение системы

Хочу: понять, где именно RAG ломается

Поможет: выпуск даёт чек-лист слабых мест: парсинг, чанкинг, ретривер, реранк, метаданные, промт

Я как CTO/тимлид

Проблема: все хотят «своего ChatGPT по внутренним данным», но с оценкой рисков туго

Хочу: разложить проект на понятные слои и точки контроля

Поможет: статья показывает, где закладывать права доступа, gateway, логи и лимиты — особенно под agentic

Я как Основатель небольшого стартапа

Проблема: клиенты задают одни и те же вопросы по продукту и политикам

Хочу: сделать бота поддержки, который отвечает по реальной базе знаний

Поможет: понятно, что нужен RAG над своей документацией, а не общая модель, и как не превратить его во второй устаревающий источник

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод
  1. Предпосылка Обычная модель не знает вашу внутреннюю информацию 1:40

    ChatGPT и подобные обучены на общедоступных данных; про вашу компанию, системы и политики они ничего не знают.

  2. Аргумент RAG добавляет шаг поиска перед ответом 1:01

    Перед генерацией система находит нужные материалы во внешнем источнике и подаёт их модели.

  3. Аргумент Это снижает галлюцинации и дешевле дообучения 3:25

    Модель опирается на конкретный источник, а при смене знаний проще переиндексировать документы, чем каждый раз дообучать модель.

  4. Пример Внутри — два контура: подготовка данных и ответ 5:23

    Подготовка: парсинг → чанкинг → эмбеддинги → гибридный индекс → метаданные. Ответ: rewrite запроса → ретривер → реранкер → сборка контекста → LLM.

  5. Пример Реальная архитектура собирается по слоям 9:14

    Ingestion-сервис → S3-слепки → chunking → embeddings → векторное/гибридное хранилище → оркестратор → реранкер → LLM-gateway → фронт.

  6. Аргумент RAG ломается на слабых звеньях, а не из-за идеи 15:28

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

  7. Вывод Длинный контекст не заменяет RAG; следующий шаг — agentic 17:20

    RAG нужен для фильтрации, цитирования, прав доступа и актуальности. Развитие — agentic RAG с многошаговым поиском, но ценой сложности и контроля.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Стоит ли смотреть целиком

Да, если вам нужна честная база по RAG без хайпа и без глубокой математики. Сильная сторона Listen IT — умение объяснять инженерию на бытовых примерах: отпуск сотрудника, отмена заявки на компенсацию, ассистент для тестировщика. За 20 минут вы получаете и понятийную рамку («RAG — это не модель, а система»), и почти готовый чертёж реальной архитектуры по слоям.

Минусы — заметные повторы (автор и сам иронизирует «100 раз уже про это говорили») и отсутствие критериев выбора среди длинного списка технологий. Это компиляция двух статей с Хабра, а не оригинальное исследование, поэтому за глубиной по каждому слою всё равно придётся идти в первоисточники.

Главное, что стоит унести

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

Ключевые развилки, которые стоит держать в голове: RAG против fine-tuning (знания против поведения), retrieval против «длинного контекста» (фильтрация и права доступа против «свалить всё в промт») и классический RAG против agentic (простота против мощности ценой контроля). Качество итога определяет не модель, а слабейшее звено конвейера — и именно туда стоит вкладывать усилия.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 6

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 8 Верно: 0

  1. 1. Как расшифровывается и что означает RAG?

  2. 2. Зачем нужен RAG, если уже есть ChatGPT?

  3. 3. Что такое чанкинг и зачем он нужен?

  4. 4. Что такое эмбеддинги в контексте RAG?

  5. 5. Полностью ли RAG избавляет модель от галлюцинаций?

  6. 6. Когда стоит выбирать fine-tuning, а не RAG?

  7. 7. Зачем в контуре ответа нужен реранкер?

  8. 8. Почему нельзя просто «напихать сотни страниц» в длинный контекст вместо RAG?

Словарь терминов

Понять незнакомое простым языком

Показать 13 терминов
RAG (Retrieval-Augmented Generation)
Генерация, дополненная поиском: подход, при котором модель перед ответом сначала находит нужные материалы во внешнем источнике и отвечает по ним. Это не модель, а инженерная система вокруг модели.
Эмбеддинги (embeddings)
Числовые векторы, описывающие смысл текста. Похожие по смыслу тексты оказываются ближе друг к другу в векторном пространстве — на этом строится поиск по смыслу.
Векторная база данных / векторное хранилище
Хранилище, где лежат эмбеддинги и по ним быстро ищутся ближайшие по смыслу фрагменты. Примеры: Qdrant, Milvus, Pinecone, Postgres с pgvector, Elasticsearch.
Чанкинг (chunking)
Нарезка документов на небольшие смысловые фрагменты (чанки). Хорошо — резать по структуре (раздел, метод, таблица), плохо — по фиксированному числу символов.
Ретривер (retriever)
Компонент, который по запросу достаёт из индекса кандидатов — обычно больше, чем попадёт в финальный промт (например, топ-20 или топ-50).
Реранкер (reranker)
Слой, который перечитывает вопрос и найденные фрагменты и пересортировывает их по реальной релевантности, отсекая мусор перед подачей в модель.
Гибридный поиск (hybrid search)
Сочетание векторного поиска (по смыслу) с поиском по ключевым словам и полнотекстовым (по точным совпадениям — коды ошибок, имена полей, номера статей).
Метаданные
Дополнительная информация о чанке: система, версия, язык, тип документа, права доступа. Без них RAG путает роли, версии и продукты и может показать закрытый документ.
Галлюцинации
Ситуация, когда модель уверенно выдаёт правдоподобный, но неверный ответ. RAG снижает риск, давая источник, но не обнуляет его.
Контекст / контекстное окно
Объём текста, который модель может учесть за один запрос. Он ограничен, но даже большой контекст не заменяет RAG: «напихать всё» дорого, медленно и без фильтрации по правам и актуальности.
Fine-tuning (дообучение)
Дообучение готовой модели на своих примерах, чтобы изменить её поведение — формат, стиль, классификацию, доменный язык. Для часто меняющихся знаний не подходит.
Ingestion-сервис
Сервис, который регулярно забирает изменённые документы из источников, парсит их, чистит мусор, вытаскивает метаданные и отправляет на чанкинг (например, по вебхуку после merge в main).
Agentic RAG (агентский RAG)
Развитие классического RAG: система сама планирует поиск — разбивает вопрос на подзапросы, обращается к нескольким индексам, сравнивает версии, делает несколько шагов. Мощнее, но дороже и опаснее.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Упрощение

«Длинный контекст так работать не будет» подано слишком категорично

Для небольших и относительно статичных корпусов подача документов прямо в длинный контекст (особенно с кэшированием контекста) бывает проще и иногда точнее целого RAG-конвейера. Это не всегда «дорого и плохо» — зависит от объёма и частоты изменений.

Упрощение

RAG и fine-tuning показаны как строгое «или-или»

На практике их часто комбинируют: fine-tuning задаёт поведение и формат, а RAG подаёт свежие знания. Выпуск разводит их как альтернативы, хотя в реальных продуктах они дополняют друг друга.

Спорно

«Потенциально RAG будет меньше галлюцинировать» звучит как гарантия

Автор честно оговаривает риск, но по факту RAG вводит новые режимы ошибок: неверный retrieval, потеря контекста при чанкинге, устаревший индекс. Плохо собранный RAG может галлюцинировать не меньше, а увереннее — со ссылкой на «источник».

Однобоко

Длинный список технологий дан без критериев выбора

Elasticsearch, pgvector, Qdrant, Milvus, Pinecone, Vertex AI, OpenSearch перечислены подряд, но новичку не объясняют, когда что брать. Перечень впечатляет, но не помогает принять решение.

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

Другой угол

RAG — это на 80% классический поиск, а не «магия ИИ»

Уберите слово «нейросеть» — и останется знакомая информационная система: парсинг, индекс, ранжирование, права доступа. Большая часть качества RAG приходит из зрелых практик search/IR, которым десятки лет, а не из самой модели.

Другой угол

RAG обнажает бардак в документации, а не чинит его

Если ассистент врёт, чаще виноват не ИИ, а противоречивые, устаревшие и плохо структурированные документы. RAG — это зеркало качества вашей базы знаний: сначала наведите порядок в источниках, потом ждите хороших ответов.

На стыке областей

Права доступа становятся частью ML-пайплайна

На стыке RAG и информационной безопасности рождается новый класс уязвимостей: забытые метаданные — и закрытый документ утёк через ответ бота. Кто имеет право видеть чанк — теперь вопрос не только СУБД, но и слоя поиска и промта.

Смежная область

Те же приёмы собирают личный «второй мозг»

Чанкинг, эмбеддинги, гибридный поиск и метаданные работают не только для корпораций. На тех же принципах строятся личные ассистенты по вашим заметкам, почте и файлам — RAG над жизнью одного человека, а не компании.

Похожие разборы

Разбор

Лупы вместо промптов в вайб-кодинге: цель со стоп-условием, которая крутится сама

Луп — это рекурсивная цель со стоп-условием: ставишь задачу один раз, и агент сам крутится «сделал → проверил → не готово → снова», пока условие не выполнится. Лупы не заменяют промптинг, а снимают ежедневную рутину — и, как признаёт сам автор, доступны уже в Claude Code и Codex через goals, а не только в его платформе.

Читать → Разбор

Многоагентный вайб-кодинг: пошаговый workflow от идеи до продакшена

Автор показывает свой процесс вайб-кодинга: главный навык — не писать код, а оркестрировать рой агентов, масштабируя их число и планы под сложность задачи. За одно видео он вживую собирает полный стек (база, API, AWS, Discord-авторизация), но половина «обязательных инструментов» — его же платные продукты.

Читать → Разбор

Sonnet 5 и новый токенайзер: почему «дешёвая» модель перестала экономить — и что значит временный возврат Fable 5

Автор BridgeMind считает Sonnet 5 провалом: новый токенайзер тратит на треть больше токенов, и «дешёвая» модель линейки местами обходится дороже старшей Opus 4.8, теряя весь смысл. Параллельно Anthropic вернула топовую Fable 5 в подписку — но лишь до 7 июля, в пределах 50% недельного лимита и с усиленными предохранителями.

Читать → Разбор

Claude Code с движком GLM 5.2: как подключить чужую модель, обойти бан и платить меньше

Бан в Claude Code перекрывает доступ к модели Anthropic, а не к самому инструменту, поэтому вместо неё можно подключить открытую китайскую GLM 5.2 через подписку Z.ai и работать в привычном харнесе. Способ дешевле подписки Claude, но заголовок «обойти всё навсегда» — маркетинг: остаются вопросы стабильности, правил Anthropic и непроверенных бенчмарков.

Читать →
← Все разборы Смотреть видео-источник