Что это
Подход, где модель сначала получает найденные фрагменты из документов, а потом отвечает по ним.
Retrieval-Augmented Generation — дополнение LLM внешними знаниями из базы данных/документов
RAG нужен там, где модель должна отвечать не по памяти, а по документам. Система сначала ищет подходящие фрагменты во внешней базе знаний. Потом кладёт их в контекст и только после этого строит ответ. Так ответ становится ближе к реальным данным. И его легче проверить.
Поэтому главный вопрос в RAG не сводится к выбору модели. Важнее понять, какие тексты индексируются, как они режутся на фрагменты и почему поиск принёс именно эти куски. Нужно ещё видеть, что попало в ответ и что осталось за кадром. Именно там часто и сидит ошибка. Если здесь бардак, хороший LLM всё равно ответит плохо.
Подход, где модель сначала получает найденные фрагменты из документов, а потом отвечает по ним.
Базы знаний, поддержка, документация, поиск по договорам, каталоги и внутренние ассистенты.
Помогает работать с живыми и внутренними данными без постоянного переобучения модели.
Если поиск нашёл лишние куски или пропустил нужный, модель уверенно склеит неверный ответ. Источник провала часто лежит в retrieval, а не в генерации.
По смыслу можно найти похожий абзац, но промахнуться мимо точного артикула, номера договора или версии регламента. Поэтому на практике часто добавляют фильтры, BM25 или reranking.
Они помогают проверить ответ и быстро понять, где возникла ошибка. Иногда виноват документ. Иногда поиск. Иногда сама модель.
У RAG есть понятная цепочка. Сначала документы готовят и кладут в индекс. Потом система ищет нужные куски. И только после этого модель получает контекст для ответа.
Тексты очищают, режут на фрагменты и сохраняют метаданные, которые потом пригодятся для фильтров.
Их делают доступными для поиска по словам, по embedding или гибридным способом.
Retriever достаёт несколько подходящих кусков, а система может дополнительно их пересортировать.
Вопрос и найденные фрагменты передают модели в одном окне контекста.
Хорошая система умеет показать, откуда взялась информация и где искать причину ошибки.
RAG полезен там, где люди задают вопрос обычным языком, а ответ должен опираться на реальный набор документов. Особенно это заметно в быстро меняющейся базе знаний.
Сотрудник спрашивает про регламент, а система вытаскивает нужный фрагмент из инструкций и политик.
Оператор или бот опирается на FAQ, документацию и историю похожих случаев.
RAG помогает найти нужный пункт и пересказать его без долгого ручного чтения.
Ответы строятся по каталогу, базе знаний или описанию внутренних процессов.
RAG заметен в 4 направлениях рынка с долей выше 5%.
Рабочий уровень здесь видно не по набору модных слов. Он виден по тому, как человек разбирает плохой ответ и объясняет, на каком шаге цепочка дала сбой.
Понимать, какие документы годятся для поиска и как их лучше дробить.
Разбирать, какие фрагменты попали в контекст и почему именно они.
Ограничивать шум, задавать формат ответа и просить модель ссылаться на источник.
Сравнивать ответы на одном наборе вопросов, а не по случайным демонстрациям.
Отделять проблему данных, поиска, reranking и генерации друг от друга.
Большая часть путаницы появляется на базовых словах. Если их не развести, дальше трудно понять, что именно вы настраиваете и почему ответ меняется.
Chunk — это фрагмент документа, который система ищет и кладёт в контекст. Он должен содержать цельную мысль.
Embedding — числовое представление текста, по которому ищут похожие по смыслу фрагменты.
Retriever — слой поиска, который выбирает кандидатов для ответа до генерации.
Reranker — дополнительный шаг, который пересортировывает найденные куски и поднимает более точные выше.
Плохой ответ редко появляется в одной точке. Обычно он собирается по цепочке: документ, нарезка, индекс, поиск, фильтр, контекст и инструкция к ответу.
Устаревшие или противоречивые тексты дают слабый ответ даже сильной модели.
Слишком короткие или случайные куски рвут мысль и ломают контекст.
Без них система может вытянуть старую версию документа или не тот раздел.
Если в промпт положили лишнее, нужный фрагмент может просто потеряться.
Эти подходы часто смешивают, хотя они решают разные задачи. Сравнивать их проще по тому, что именно вы хотите улучшить в системе.
Связывает поиск по документам и ответ модели в одной цепочке.
Нужен, когда знания живут во внешних текстах и быстро меняются.
Не спасает, если документы грязные, а retrieval плохо настроен.
Ищет по словам, фразам и точным совпадениям без генерации ответа.
Подходит, когда важны термин, код, артикул или короткий документ.
Сам по себе не перескажет найденное и не склеит ответ пользователю.
Меняет поведение модели на типовом наборе обучающих примеров.
Нужен, когда важно скорректировать стиль, формат или устойчивую реакцию.
Не решает задачу живых документов, которые обновляются каждый день.
Сочетает поиск по словам, embeddings, фильтры и reranking.
Подходит, когда в запросах есть и смысл, и точные поля или версии.
Становится сложнее в поддержке, если команда не меряет вклад каждого слоя.
RAG переносится между ролями: Data Scientist, AI-инженер, ML-инженер. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Data Scientist держит 76.1% вакансий по навыку.
Ещё 7 ролей используют RAG
RAG ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами: быстро получить ответ, проверить расхождение, подготовить рабочий слой для команды и довести решение до результата.
Очистить шум, сохранить метаданные и нарезать материалы на полезные куски.
Проверить, какие фрагменты система реально кладёт в контекст по рабочим вопросам.
Замерить точность поиска, полноту ответа и устойчивость на наборе тестовых вопросов.
Понять, ошибся документ, поиск, reranking, промпт или сама модель.
RAG ценят за очень практичную вещь: он даёт модели доступ к текущим документам без нового обучения на каждом изменении. Поэтому навык нужен командам, где ответ должен опираться на инструкции, карточки, статьи, договоры или внутренние правила. Рабочая ценность специалиста здесь не в красивой схеме. Она в умении собрать весь путь от документа до ответа и объяснить, где система теряет точность. Именно это отличает демо от системы, которую можно поддерживать в работе. И которую не страшно показать бизнесу. И не стыдно разбирать на реальных ошибках. Команда быстрее понимает, что чинить дальше. Это видно уже на первых пилотах.
RAG нужен там, где важно быстро проверить гипотезу, сверить метрику или подготовить данные для следующего шага.
Такой навык редко живёт в одной профессии: он остаётся полезным в аналитике, продукте, разработке и соседних data-сценариях.
Инструменты вокруг меняются, но сама задача не исчезает, поэтому RAG продолжает удерживать прикладной спрос.
RAG формирует устойчивый спрос внутри своего рабочего сегмента.
RAG сохраняет устойчивый прикладной спрос на рынке: 297 активных вакансий, #59 по рынку, 3.8% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
#59 по рынку • 3.8% IT-вакансий
+9 вакансий и +2% к предыдущему месяцу.
Рынку нужен специалист, который умеет разбирать качество ответа по этапам. Сначала он смотрит на данные. Потом проверяет retrieval и reranking. После этого смотрит на метрики и плохие кейсы на повторяемом наборе вопросов. Такой специалист...
38 активных вакансий с зарплатой • покрытие 12.2% зарплатной выборки
Коридор появится с publishable-грейдами.
Senior - основной уровень рынка (51%)
Сейчас на рынке 10 активных junior-вакансий с RAG. Это 3.8% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
3.8% всех вакансий по навыку • Senior / Junior 13.4x
Окно входа узкое: рынок чаще нанимает с опытом.
Медианная вакансия с RAG ожидает около 14 навыков в стеке. Это собранный стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
RAG редко живёт изолированно: чаще всего рынок видит его рядом с LLM, Python, Docker. Самая плотная связка сейчас - LLM: оба навыка встречаются вместе в 93% вакансий.
Главная связка: LLM • 93% вакансий. Показываем общерыночные связки RAG: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
навыки, которые рынок чаще всего видит рядом в одной вакансии
не базовый минимум, а более сильные комбинации стека
Учить RAG лучше на маленьком корпусе, где заранее известны правильные ответы. Сначала полезно настроить обычный поиск по текстам и посмотреть, какие фрагменты вообще находятся. Потом добавить embeddings, reranking и только после этого подключить модель. Такой порядок быстро показывает, что проблема часто сидит не в LLM, а в документе, нарезке и ранжировании. Ещё он учит не прятать плохой retrieval за красивым текстом модели. А значит, быстрее приводит к рабочей диагностике. Полезно ещё вести заметки по каждому провалу. И сохранять примеры хорошей выдачи рядом. Без этого сложнее честно сравнивать изменения в системе. И сложнее ловить регресс.
Взять понятный набор документов и выписать вопросы, на которые в них точно есть ответ.
Сначала важно увидеть, какие куски система вообще поднимает по запросу.
Сравнить хороший и плохой контекст на одном и том же вопросе.
Сравнивать результаты на фиксированном наборе вопросов, а не по красивой демо-сцене.
Соберите небольшой корпус документов и десять вопросов с известным ответом. Сначала добейтесь внятного поиска без генерации. Потом добавьте модель, ссылки на источники и простой набор метрик. Полезно сохранять и удачные, и плохие кейсы отдельно. Потом сравнивать их рядом. И не менять сразу все настройки. Полезно идти по одному шагу за раз. И записывать, что именно поменялось. И почему вы сделали этот шаг. Полезно ещё отмечать, что не сработало. И что дало эффект. Такой маршрут быстрее всего показывает настоящие слабые места системы.
Не смешивать сразу договоры, статьи и логи в одном эксперименте.
Они пригодятся для сравнения retrieval и итогового ответа на одинаковых кейсах.
Проверить, какие фрагменты вообще находятся без участия модели.
Добавить формат ответа, ссылки на источник и разбор типовых провалов.
Для навыка RAG важнее не установка, а понятные источники и материалы, которые помогают быстрее разобраться в теме.
RAG важно отделять от соседних инструментов и ролей, чтобы не путать сам навык с окружением вокруг него.
Первый практический шаг по RAG должен быть коротким и проверяемым: один сценарий, один результат, один понятный вывод.
После короткого объяснения переходите к официальной документации, одному туториалу и одному живому примеру по RAG.
Перспективы RAG завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Команды всё чаще смотрят не на демо, а на повторяемые метрики и тестовые вопросы.
Чистого vector search часто мало, поэтому фильтры, BM25 и reranking никуда не уйдут.
Побеждает не тот, кто первым подключил LLM, а тот, кто держит документы и индекс в порядке.
Нет. Чат-бот — это форма интерфейса. RAG — это способ дать модели внешний контекст из документов перед ответом. Один и тот же бот может работать с RAG, а может отвечать и без него. Это разные уровни системы.
Нет. Если документы часто меняются, RAG обычно удобнее. Если нужно изменить стиль, формат или устойчивое поведение модели на типовых примерах, может понадобиться fine-tuning. Часто команды сочетают оба подхода, а не выбирают только один. Это нормальный рабочий сценарий.
Не всегда. Иногда хватает полнотекстового или гибридного поиска. Всё зависит от данных, типа вопросов и того, насколько важны точные термины, версии и фильтры. Векторная база — это частый, но не обязательный слой. Иногда она вообще не нужна.
Обычно в контекст попал не тот фрагмент, источник устарел или модель склеила вывод из частично подходящих кусков. Поэтому нужно смотреть и на документ, и на retrieval, и на итоговый промпт. Ошибка редко живёт только в одном месте.
С маленькой базы документов и набора вопросов с известным ответом. Сначала настройте поиск без LLM. Потом добавьте генерацию, ссылки на источники и простую проверку качества. Такой маршрут быстрее даёт понимание, где система действительно слаба. И не даёт спрятаться за красивую демо-выдачу.
Чаще всего провал начинается с документов и нарезки. Потом добавляются слабые фильтры, плохой retrieval и лишний шум в контексте. Поэтому разбирать систему полезно не с модели, а с более ранних слоёв. Там и лежит главная причина. Это видно почти в каждом разборе.