Почему ваша RAG-система «работает на демо» и ломается в продакшене: 7 точек отказа, о которых не расскажут на питче
Что на самом деле происходит внутри RAG-системы: 7 точек отказа между вопросом и ответом
Пользователь вводит вопрос, через три секунды получает уверенный ответ со ссылкой на документ. Выглядит как магия. На практике за эти три секунды запрос проходит конвейер из 6–8 этапов, каждый из которых принимает вероятностное решение — и каждый может ошибиться так, что снаружи этого не видно. 80% enterprise RAG-проектов сталкиваются с критическими сбоями в продакшне. Разберём, где именно ломается то, что выглядит работающим.
RAG — это не «умный поиск», а конвейер с узкими местами
Типичное представление о RAG: модель ищет нужный документ и отвечает по нему. Красивая схема из трёх блоков — query, retrieval, generation. На практике между вопросом пользователя и ответом стоит цепочка из семи критических шагов, и сбой на любом из них каскадно влияет на результат.
42% AI-проектов провалились в 2025 году — в 2,5 раза больше, чем годом ранее (Analytics Vidhya, 2025). Значительная часть этих провалов — RAG-системы, которые «работали на демо» и сломались в продакшне. Причина не в моделях. Причина — в том, что происходит между моделью и данными.
Проследим путь одного конкретного запроса — от нажатия Enter до появления ответа. С остановками в каждой точке, где что-то может пойти не так.
Шаг 0: Что происходит до вопроса — индексация документов
Прежде чем система ответит на первый вопрос, все документы проходят подготовку. Этот этап невидим для пользователя, но ошибки здесь определяют потолок качества всей системы.
Документы нарезаются на чанки — фрагменты текста фиксированного или адаптивного размера. Каждый чанк прогоняется через эмбеддинговую модель — нейросеть, которая превращает текст в числовой вектор. Векторы записываются в специализированную базу данных (Pinecone, Qdrant, Weaviate, pgvector).
Как размер чанка влияет на качество ответа
Размер чанка — первый компромисс, который определяет всё дальнейшее. Слишком маленький чанк (100–200 токенов) — система находит точное совпадение, но теряет контекст. Ответ получается фрагментарным: модель видит предложение, но не видит абзац, к которому оно относится.
Слишком большой чанк (1500–2000 токенов) — контекст сохраняется, но релевантность размывается. Вектор усредняет смысл всего фрагмента, и при поиске чанк «конкурирует сам с собой»: половина текста релевантна, половина — шум.
На практике оптимум обычно лежит в диапазоне 400–800 токенов с перекрытием (overlap) 10–15%. Но «оптимум» зависит от домена: юридические документы с длинными определениями требуют других параметров, чем FAQ-база из коротких вопросов-ответов. Универсального рецепта нет — нужно тестировать на своих данных.
Шаг 1: Вопрос превращается в вектор
Пользователь вводит вопрос. Система прогоняет его через ту же эмбеддинговую модель, которой были закодированы документы. Получается вектор запроса — точка в многомерном пространстве.
Здесь кроется неочевидная ловушка. Если с момента индексации модель обновилась — а провайдеры обновляют модели без предупреждения — векторы документов и вектор запроса оказываются в разных пространствах. Это дрейф эмбеддингов: формально система работает, поиск возвращает результаты, но релевантность падает. Снаружи это выглядит как «система стала отвечать хуже», а в логах — никаких ошибок.
Ещё один подводный камень: эмбеддинговые модели обучены на определённых данных. Модель, обученная на англоязычных текстах, по-разному «понимает» технические термины на русском. Вопрос «каковы условия расторжения договора» и чанк с этими условиями могут оказаться далеко друг от друга в векторном пространстве — просто потому, что модель плохо работает с русскоязычной юридической лексикой.
Шаг 2: Векторный поиск — top-k против здравого смысла
Вектор запроса готов. Система ищет ближайшие к нему векторы в базе — по косинусному сходству. Находит top-k кандидатов (обычно 20–50 чанков) и ранжирует их по «близости».
Проблема: «близость в векторном пространстве» и «релевантность для пользователя» — разные вещи. Семантический поиск находит тексты, похожие по смыслу. Но если пользователь спрашивает про конкретный артикул товара, номер договора или юридическую аббревиатуру — семантическое сходство бесполезно. Система найдёт чанки про «договоры в целом» вместо конкретного документа №157/2024.
Поэтому зрелые RAG-системы используют гибридный поиск: векторный (семантика) + BM25 (точное совпадение ключевых слов). Результаты объединяются через алгоритмы слияния рангов. По данным бенчмарка EncouRAGe (2025), гибридный поиск стабильно превосходит каждый из подходов по отдельности на всех четырёх тестовых датасетах.
Но большинство быстрых реализаций — «подключили Pinecone и поехали» — используют только векторный поиск. Результат предсказуем.
Reranking: второй фильтр, который обычно забывают
Из top-50 кандидатов нужно выбрать 5–10 лучших. Первичный поиск груб — он оптимизирован на скорость, не на точность. Реранкер (кросс-энкодер) берёт каждую пару «запрос + чанк
Подписывайся на Телеграм Вайблаб, чтобы наблюдать за тем, как мы строим AI-first компанию.
Напишите нам напрямую