Умная документация 2026: как RAG ломает шаблоны и плодит проблемы

6 августа 2026 года

Вы просидели над толстенным руководством 100500 часов: всё вылизано и проверено. Но вот поддержка скидывает скриншот: пользователь написал в чат "А как сменить язык интерфейса?". И это при том, что в разделе 3.2.4 все расписано на восьми скриншотах. А он не нашёл. Не потому, что плохо искал, а потому, что человеческий вопрос и статичный индекс поиска — это две большие разницы.

И тут на сцене появляется RAG (Retrieval-Augmented Generation) — мост, который соединяет LLM с вашей "базой знаний". Большинство статей пишут о RAG, как о панацее, а мы постараемся осветить не только те моменты, где эта технология незаменима, но и ситуациях, когда она создаёт проблемы. Забегая вперед: в 2026 году без RAG никуда, но ее внедрение не ограничивается подключением API. Это пересмотр всей философии пользовательской документации.

Что RAG меняет и не меняет в пользовательской документации?

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

1. находит релевантные фрагменты (retrieval),
2. передает их вместе с вопросом в языковую модель,
3. модель формулирует связный ответ, часто с переформулировкой под контекст диалога.

Вот как это может выглядеть на практике:

1. Запрос (Query): пользователь задаёт вопрос (например, "Как настроить экспорт в CRM?").
2. Поиск (Retrieval): ИИ превращает вопрос в числовой вектор и ищет в специальной базе данных (векторной) самые релевантные отрывки текста из ваших документов (например, из руководства пользователя вашей CRM).
3. Дополнение (Augmentation): к запросу пользователя "приклеиваются" найденные отрывки из документации.
4. Генерация (Generation): LLM получает запрос + найденные факты и генерирует ответ, строго опираясь на эти факты. Если фактов в базе нет — модель сообщит: "Я не знаю точного ответа, вот что я нашёл в документах...".

Для пользовательских документов (инструкции, how-to, гайды) это звучит идеально. Но ключевое слово — пользовательская. В отличие от API-спецификаций, где важна машиночитаемая точность, здесь человек ждёт объяснений на своём языке. "Как экспортировать проект в PDF" — модель может пересказать инструкцию более человечно, уточнить по ходу дела и даже спросить, какая версия софта у пользователя.

Сравнение: традиционный поиск против RAG

Классический поиск (на основе индексации и ранжирования по точному совпадению терминов) долгое время был стандартом для корпоративных баз знаний. Современные реализации (Elasticsearch, Solr) поддерживают стемминг, лемматизацию, настраиваемые синонимы и даже обучаемые ранжеры — они уже далеко не "просто совпадение слов". RAG (Retrieval-Augmented Generation) комбинирует поиск по смыслу (вектора) и генерацию ответа языковой моделью. Ниже — честное сравнение без преувеличений.

RAG не "лучше" классического поиска во всём. Он закрывает зону, где человек не знает точных терминов или формулирует запрос как другу. За это приходится платить скоростью, деньгами и риском ошибок модели.

Когда RAG работает, а когда — нет

Эта технология — не серебряная пуля. Она блестяще решает одни задачи, но создаёт новые проблемы в других условиях. Ниже — два чек-листа для принятия решения.

Когда RAG даёт настоящий прорыв

• Документация с большим объёмом сценариев (ERP-системы, сложный софт, промышленное ПО). Пользователь не может вспомнить, как называется нужная функция — но может описать, что хочет сделать.
• Многоязычные базы знаний. RAG может ответить на запрос на языке, которого нет в оригинальных документах (с переводом на лету), но с осторожностью.
• Live-service игры / часто меняющиеся продукты. Постоянные патчи, новые механики — RAG легче переваривает разрозненные заметки о патчах, чем человек, который ищет по обновлённым PDF.
• Поддержка "первой линии" — чат-бот по документации, который снижает нагрузку на операторов. Успешные кейсы есть у Intercom (Fin AI) и Zendesk Answer Bot.

Когда RAG лучше не использовать

• Документация с жёсткими нормативными требованиями (медицинские инструкции, авиационная документация). Любая галлюцинация опасна, а уверенно отключить генерацию можно, но требует дополнительных механизмов — лучше классический поиск с прямым цитированием.
• Маленькая статичная документация (50 страниц, устоявшаяся). Здесь RAG - только лишние затраты. Пользователь быстрее нажмет Ctrl+F или посмотрит оглавление.
• Контент с высокой долей таблиц, кода, точных параметров. LLM склонна упрощать или терять цифры. Например, для спецификации API RAG чаще вредит, чем помогает — разработчики хотят точный JSON, а не пересказ. Векторный поиск плохо различает похожие коды ошибок или числовые ID, для них нужен полнотекстовый точный поиск.
• Когда нет внутренних ресурсов на эксплуатацию. RAG — это не "раз поставил и забыл". Вы будете менять chunking, модели, пост-процессинг. Если команда из одного техписа — отложите.

Скрытые сложности

1. Нарезка (chunking)

Векторный поиск работает с кусками текста. Нарежете слишком мелко (1-2 предложения) — теряете контекст. Слишком крупно (абзацы на экран) — шум и низкая релевантность. Для пользовательских инструкций идеальный чанк часто совпадает с "шагом" в процедуре. Но у вас нет такой разметки? Значит, пилите заново. Многие идут в лоб: чанк в 512 токенов с перекрытием в 100. Но на документации с кодом и таблицами такой подход трещит по швам. Решения — только кастомная обработка и мета-теги.

Альтернатива — семантический чанкинг. Вместо фиксированного размера текст нарезается по естественным границам (конец предложения, конец абзаца) с контролем семантической близости соседних кусков. Алгоритм: разбиваете документ на предложения, получаете эмбеддинг каждого, затем идёте по предложениям и склеиваете их в чанк до тех пор, пока косинусное расстояние между эмбеддингом текущего чанка и эмбеддингом следующего предложения не превысит порог (например, 0.3). Как только порог пройден — текущий чанк закрывается, следующий начинается с этого предложения. Так чанки получаются разной длины, но логически цельными. Для документации с таблицами и кодом семантический чанкинг работает лучше фиксированной нарезки, хотя требует больше вычислений при индексации. Библиотеки: LlamaIndex (SemanticSplitterNodeParser), LangChain (SemanticChunker).

2. Мёртвая аналитика: вы не знаете, почему RAG ответил плохо

Классический поиск: пользователь ввёл слова, не нашёл — вы видите нулевые результаты. RAG: он получил ответ, но неправильный. Будет ли жалоба? Скорее всего, нет — пользователь просто подумает, что документация бесполезна, и уйдёт к конкуренту. Отследить галлюцинации без явного фидбека почти невозможно. Нужно встраивать рейтинг ответов (палец вверх/вниз) и логировать полные диалоги. А это дополнительная инфраструктура и риск PII.

Современное решение: интеграция метрик типа Faithfulness, Answer Relevance и Context Recall (библиотеки RAGAS, DeepEval) в CI/CD пайплайн документации. Это позволяет автоматически оценивать качество ответов при каждом обновлении базы знаний.

3. Совокупная стоимость владения (TCO): реальные цифры

Для RAG типичного размера (10 000 страниц, 5000 запросов/день) возможны два сценария:

• Облачный (управляемый): Pinecone/Qdrant Cloud (~$150–300/мес), LLM API (GPT-4o mini или Gemini Flash ~$0.01–0.03/запрос) → $150–450 в день, плюс инфраструктура для эмбеддингов (~$100/мес). Итого может доходить до $8 000–12 000/мес.
• Open‑source on‑prem: Qdrant community на SSD-сервере (~$200/мес за хостинг), Llama 3.1 8B или Mistral 7B на одном GPU (аренда ~$500/мес), эмбеддинги BGE на CPU. Итого ~$800–1500/мес, но требует инженера на полставки (ещё ~$2000). Реалистичный диапазон для среднего проекта — $2000–5000/мес. Для многих компаний всё равно дороже двух операторов поддержки, но выигрыш в масштабируемости.

Elasticsearch на том же железе обойдется в 200-500 долларов и работает себе тихонько, не требуя присмотра.

Сценарий для малого проекта (500 запросов/мес): если у вас 500–1000 запросов в месяц, затраты резко снижаются. Можно использовать бесплатный или очень дешёвый стартовый tier Pinecone (до 100 тыс. векторов бесплатно) или Qdrant Cloud (бесплатный 1‑гигабайтный кластер). LLM API при 500 вызовах в месяц (например, GPT-4o mini) обойдется в $5–15. Эмбеддинги можно генерировать бесплатной моделью локально или через API с низкой ценой. Итого: $20–50 в месяц + возможная переработка документации своими силами. Для таких объёмов подойдут готовые платформы без штатного инженера (Dify, AnythingLLM, R2R), которые дадут RAG "из коробки" за пару вечеров настройки.

Разумеется, на момент чтения этого материала цены изменятся.

4. Документация пишется для людей, а RAG требует её переписывать для машин

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

Anthropic в своём исследовании (2024) показал, что добавление "контекстного ретривера" увеличивает точность на 15-20% за счёт предварительного анализа структуры документа. Но это ещё один слой сложности.

5. Галлюцинации и методы их контроля (дополнение 2026)

Риск галлюцинаций можно снизить, но не устранить полностью. Работающие техники:

• Температура и top‑p — установка низкой температуры (0.1–0.3) для более детерминированных ответов.
• Детекция галлюцинаций через self‑check: модель перепроверяет свой ответ по исходным чанкам (SelfCheckGPT, контрастивные методы).
• Порог уверенности ретривера: если максимальная релевантность < 0.7 — не генерировать ответ, а предложить поиск по ключевым словам.

На практике гибридные системы с прямым цитированием (каждая фраза ответа снабжается ссылкой на источник) значительно повышают доверие пользователей.

6. Версионирование эмбеддингов — неожиданная миграция

Модели эмбеддингов обновляются: BGE‑large‑v1.5 → v1.6, OpenAI меняла ada‑002 на text‑embedding‑3. Если вы сменили модель эмбеддингов (или обновили её версию), то старые векторные представления документов становятся несовместимыми — поиск по смыслу сломается. Вам придётся пересчитать все эмбеддинги всех чанков документации заново. Для 10 000 страниц это может занять дни и стоить сотни долларов вычислительных ресурсов. Планируйте такие миграции заранее: держите отдельную векторную БД под новую модель, пересчитывайте порционно, делайте A/B‑тест перед переключением.

7. Multi‑turn RAG: когда диалог идёт вразрез с поиском

В реальном чат-боте пользователь редко ограничивается одним вопросом. Он уточняет: "А как для Windows?", "Нет, у меня старая версия". Это разрушает простую схему "вопрос → поиск → ответ". Для многошагового диалога RAG требует дополнительной механики:

• Сжатие истории — предыдущие вопросы и ответы не должны каждый раз заново подаваться в LLM (переполнят контекст). Нужно их резюмировать или выделять только релевантные части.
• Переписывание запроса (rewrite) — текущий вопрос ("А как для Windows?") преобразуется в самодостаточный запрос с учётом истории ("Как сменить язык интерфейса в программе X на Windows?"). Только тогда поиск найдёт правильные чанки.
• Разделение памяти — где хранить историю диалога между сессиями? В Redis, в базе данных, в самом промпте?

Без этих механизмов ваш RAG-чат будет отвечать на первый вопрос хорошо, а на второй — "забывать" контекст и давать нелепые ответы. Готовьте инженерный бюджет на реализацию multi‑turn с rewrite или выбирайте платформы, поддерживающие это из коробки (например, RAGFlow, Dify с расширенными настройками диалога).

8. Метрики качества RAG: что считать нормой

Внедрить метрики - полдела. Нужно еще знать, какая цифра считается нормой. Ориентировочные пороги для пользовательской документации (на основе опыта продакшен-систем):

Измеряйте эти метрики на тестовом наборе из 50–200 вопросов, собранных из реальных обращений в поддержку. Если после обновления документации какая-то метрика падает — значит, вы сломали retrieval (неправильно нарезали чанки, испортили метаданные или изменили эмбеддинги). Пороги, приведённые выше, годятся для документации средней сложности; для нормативно-жёстких систем требуйте faithfulness > 0.95.

Гибридные подходы: не верьте в "чистый RAG"

На практике умные команды комбинируют методы. Не "RAG или классика", а "гибридный поиск + LLM как опция".

Атрибуты (метаданные) — то, о чём забывают в 90% внедрений

Даже идеально нарезанные чанки не спасут, если RAG не умеет фильтровать или приоритизировать их по дополнительным признакам. Здесь на сцену выходят атрибуты — метаданные, которые пришиваются к каждому чанку. Это может быть:

• версия продукта (v2.0 vs v3.0),
• тип контента (инструкция, справочник, пример кода, известная проблема),
• уровень доступа (публичный, внутренний, NDA),
• дата последнего обновления,
• гео или язык,
• имя раздела или теги сценария.

В классическом векторном поиске атрибуты используются на этапе фильтрации (до или после retrieval). Например: "Найди чанки, где version = 2026 и type = troubleshooting". Это резко повышает точность, потому что модель не будет путать старые и новые инструкции.

В более продвинутых RAG-пайплайнах атрибуты также влияют на ранжирование (вес более свежих чанков выше) и на решение, запускать ли LLM (если чанк имеет низкую достоверность по атрибуту "источник", можно отдать только цитату без генерации).

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

Схема, которая работает в 2026 году

1. Пользователь задаёт вопрос.
2. Система параллельно делает полнотекстовый поиск (BM25) и векторный поиск (эмбеддинги).
3. Ранжер (например, Cross-encoder) переупорядочивает результаты, отдавая приоритет точным цитатам из документации.
4. Проверка на early exit: после ранжирования, если оценка топ-1 результата превышает 0.95 (почти идеальное совпадение с вопросом) И этот чанк помечен как "исчерпывающий" (атрибут is_complete=true), то можно сразу отдать его содержимое в виде цитаты, не вызывая LLM вообще. Это экономит 2–3 секунды и деньги. Early exit также срабатывает, если вопрос является типовым и уже есть готовый ответ в кэше (см. семантическое кэширование).
5. Если топ-1 результат имеет высокую точность (по метрике релевантности >0.9) — отдаём его как есть (быстро и без LLM).
6. Если нет — запускаем RAG-генерацию на топ-3 чанках, но с проверкой: если максимальная релевантность среди всех чанков ниже 0.5, генерацию не запускаем (вероятность галлюцинации слишком высока). Вместо этого возвращаем fallback: "Не нашёл точного ответа. Попробуйте переформулировать вопрос или воспользоваться поиском по ключевым словам".
7. Показываем ответ и обязательно приводим ссылки на исходные разделы документации, чтобы пользователь мог перепроверить.

Такой гибрид дает скорость, прозрачность и защиту от галлюцинаций. Его использует GitLab для своей документации и Elastic с их RRF (Reciprocal Rank Fusion).

Кэширование и оптимизация латентности

Для частых запросов (значительная часть повторяется) применяется семантическое кэширование: эмбеддинг вопроса сравнивается с кэшем по косинусной близости — при совпадении > 0.95 отдаётся сохранённый ответ. Это снижает задержку с 3 секунд до 50 мс и сокращает затраты на LLM на 60–80%.

Безопасность и PII: RAG-пайплайн может случайно вытянуть чувствительные данные из документации (реальные имена в примерах, ключи API, IP-адреса). Обязательно внедряйте фильтрацию на уровне эмбеддингов (вырезание PII через регулярные выражения или NER-модели) и пост-процессинг ответа. Также логирование диалогов должно быть анонимизировано.

Fine‑tuning vs RAG: когда что выбрать?

Для узкой, стабильной документации (например, внутренние регламенты) дешевле и надёжнее сделать fine‑tuning маленькой модели (Phi-3, Mistral 7B) на 500–2000 парах вопрос-ответ. Fine‑tuning даёт низкую задержку (200–300 мс), отсутствие риска вытянуть нерелевантный кусок и не требует поддержки векторной БД. Минус — переобучение при каждом обновлении документации. RAG выигрывает при частых изменениях контента и когда нужны ответы с цитатами.

Как готовить датасет для fine‑tuning

Для fine‑tuning маленькой модели (Phi-3, Mistral 7B) вам понадобится 500–2000 пар (вопрос, ожидаемый ответ). Формат: инструкция + вопрос + ответ. Пример разметки:

{ "instruction": "Ты помощник по документации продукта X. Отвечай точно по инструкции, не добавляй лишнего.", "input": "Как сбросить пароль в личном кабинете?", "output": "Перейдите в раздел «Профиль» → «Безопасность» → «Сбросить пароль». Вам придёт письмо с одноразовой ссылкой." }

Важные правила подготовки:

• Балансировка: не менее 20% примеров должны быть с негативным сценарием ("не найдено", "эта функция не поддерживается"). Иначе модель будет галлюцинировать ответ на любой вопрос.
• Разнообразие формулировок: для одного и того же факта добавьте 3–5 разных вариантов вопроса (синонимы, перефразировки).
• Ограничение длины: ответы не длиннее 300 токенов, иначе модель будет многословной.

Деплой fine‑tune модели без даунтайма

После обучения у вас есть новая версия весов. Стратегия замены без остановки сервиса:

1. Загрузите новую модель на отдельный инференс‑сервер (или GPU).
2. Направьте на неё 1–5% трафика (canary deployment), сравните метрики (точность, задержка) со старой моделью.
3. Если точность не снизилась, постепенно увеличивайте процент трафика до 100%.
4. Старую модель оставьте в резерве на 24 часа для отката по первой жалобе.

Такой подход позволяет обновлять fine‑tune модель раз в неделю без простоев поддержки. Для автоматизации используйте LLMOps‑инструменты (MLflow, BentoML, или встроенные функции платформ Replicate, Predibase).

Выбор модели эмбеддингов: на что обратить внимание

Качество retrieval напрямую зависит от модели эмбеддингов. Для технической документации хорошо работают модели с размерностью 768–1024, обученные на технических текстах (BGE‑large, GTE‑large, Voyage‑2). При тестировании на реальных данных они дают recall@5 на 10–15% выше, чем универсальные модели (text‑embedding‑ada‑002 или open source multilingual‑E5).

• BGE‑large‑en (1024d) — хороший компромисс, работает на CPU с приемлемой скоростью.
• Voyage‑2 и Cohere embed‑english‑v3.0 — дороже, но выше точность для длинных документов и кода.
• OpenAI text‑embedding‑3‑small/large — удобны в API, но дороги при большом объёме чанков и дают высокую размерность (1536/3072), что увеличивает затраты на хранение и вычисления.

Проверьте 2-3 модели на своих 50 вопросах. Разница в точности может достигать 15 пунктов - и сразу станет ясно, куда копать.

Реальный кейс: RAG в ERP-системе — когда цифры хорошие, а люди всё равно нервничают

В 2025 году исследователи задокументировали внедрение RAG в средней дистрибьюторской компании в Таиланде. У них стоял Odoo ERP, и проблема была не в отсутствии документации, а в том, как до неё добраться. Чтобы ответить на вопрос вроде "Какие товары заканчиваются на складе и какие у них были продажи в прошлом месяце?", сотруднику приходилось пройти пять разных экранов ERP, вручную настроить системные фильтры и собирать данные из нескольких модулей. На это уходило от 20 до 45 минут. Команда собрала агентный чат-бот на RAG, подключённый напрямую к XML-RPC API Odoo. Автоматизированное тестирование показало 95 % точности по OpenAI Evals, 90 % по Ragas и 85 % по DeepEval. Удовлетворённость конечных пользователей - 4,33 из 5.

Но вот шкала System Usability Scale выдала 66,67 из 100 - едва "приемлемый прототип". Пользователям нравилась идея, но они не верили, что справятся с ботом самостоятельно: многие чувствовали, что без эксперта рядом - никуда. "Провал" был не технический. Бот выдавал правильные цифры, но сотрудники не готовы были ставить на них в свои рабочие решения без человека в цепочке. Доверие не появилось автоматически вместе с точностью.

Кейс показал: RAG в ERP работает не тогда, когда API отдаёт корректный JSON, а тогда, когда человек готов действовать по ответу бота без дополнительных проверок. Без проработки этого доверия — метаданных, явных ссылок на источники, понятных объяснений, откуда взялась цифра, - даже 95 % точности остаются просто красивым числом в отчёте.

RAG требует не API-ключей, а инженерной дисциплины в самом контенте. Pinecone пишет об этом же: "лучшие результаты RAG начинаются с разметки данных, а не с модели".

Прогноз: llms.txt, агентная документация и роль техписа

Две тенденции станут мейнстримом.

1. Файл llms.txt как маршрутная карта для RAG

Спецификация llms.txt, предложенная Answer.AI в конце 2024 года, становится стандартом де-факто. Крупные игроки (Cloudflare, Microsoft, Adobe, PayPal, Stripe, Slack, Zendesk) уже добавили его на свои сайты документации. Этот файл — аналог robots.txt для LLM. Он указывает, какие разделы оптимальны для индексирования, какой чанкинг предпочтителен и где лежат обновления. Техписам придётся поддерживать llms.txt наравне с sitemap. Пример простейшего файла:

# llms.txt для документации продукта /guides/getting-started.md /api/reference.md chunk_size=1024
overlap=128 /changelog.md do_not_index=true

2. От RAG к агентной документации

Следующий шаг — не просто отвечать на вопросы, а выполнять действия в интерфейсе продукта по инструкции из документации. Например, "обнови драйвер до последней версии" — агент находит раздел, понимает последовательность, вызывает API системы обновления. Для пользовательской документации это означает, что она становится исполняемым контентом. В 2026 такие эксперименты уже есть у Anthropic (tool use) и в проекте Glean. Требования к безопасности и авторизации здесь кратно возрастают: агент должен действовать от имени пользователя с чёткими ограничениями.

Как должна выглядеть документация для агента (tool‑use). Если вы хотите, чтобы агент не просто отвечал, а выполнял действия (например, "обнови драйвер"), то в документации нужно описывать не только текст, но и метаописания функций. Пример фрагмента, который агент сможет использовать:

# tool: update_driver описание: "Обновляет драйвер устройства до последней версии" параметры: - device_id:
строка, обязательный, идентификатор устройства (можно получить из system_info) - version:
строка, опциональный, целевая версия (по умолчанию "latest") возвращает:
статус операции, сообщение об ошибке, ссылку на лог пример вызова:
update_driver("GPU-0", "531.18") ограничения:
требуется права администратора; не работает для сетевых адаптеров.

Агент прочитает это, поймёт, какой API вызвать, какие параметры обязательны, и выполнит действие от имени пользователя (предварительно запросив подтверждение). Для описания инструментов в документации всё чаще используется формат OpenAPI (для REST) или JSON Schema, пришитый к чанку через атрибут tool_schema. Без такого структурированного описания агент не сможет ничего выполнить — он останется просто чат‑ботом.

Начните с одного‑двух простых действий (например, "создать тикет в поддержке", "перезапустить службу"). Опишите их в документации отдельным разделом "Инструменты для агента" и добавьте в векторную базу с тегом is_tool=true. Затем в промпте разрешите модели вызывать эти инструменты. Это дешевле и безопаснее, чем давать агенту полный доступ к системе.

Техпис больше не пишет статичные страницы. Он проектирует связи, метаданные, размер чанков и сценарии для агентов. Без понимания RAG это делать невозможно.

Практический чек-лист внедрения RAG за 3 месяца

Для команды из 2–3 человек (техпис + разработчик) примерный план:

• Месяц 1 — подготовка контента и метрик:
  • Выделите 50–100 типовых вопросов из тикет‑системы или логов чата поддержки.
  • Разметьте для каждого вопроса ожидаемый ответ (точную цитату или краткое решение). Это ваш золотой набор для тестирования.
  • Проведите аудит документации: добавьте атрибуты (версия, тип, теги), перепишите 20% самых частых сценариев в формат "один сценарий — один чанк".
• Месяц 2 — гибридный поиск без LLM (baseline):
  • Разверните Elasticsearch или Qdrant с hybrid search (BM25 + векторы).
  • Подберите модель эмбеддингов (BGE‑large или Voyage).
  • Замерьте метрики (Context Recall, Precision) на вашем тестовом наборе. Добейтесь recall@5 > 0.7.
• Месяц 3 — добавление LLM и fallback:
  • Подключите LLM только для запросов, где максимальная релевантность ниже 0.9.
  • Внедрите семантическое кэширование и порог отказа (если релевантность < 0.5, не генерировать, а вернуть fallback).
  • Запустите A/B‑тест на 10% трафика поддержки, сравните с ручными операторами.

Этот график предполагает, что вы не переписываете всю документацию сразу, а только самые частые сценарии. Остальной контент остаётся на классическом поиске. Через 3 месяца вы получите рабочий прототип, который уже снизит нагрузку на поддержку на 20–30%.

Заключение: прагматичный путь

• RAG решает проблему "пользователь не знает точных терминов", но не отменяет классический поиск — используйте гибрид.
• Главные затраты не в API, а в переработке контента под чанки и в постоянной эксплуатации. На малых проектах RAG не окупается.
• Галлюцинации неизбежны, но их можно сократить детекцией, порогами уверенности и строгим цитированием источников.
• Пользовательская документация требует chunking по сценариям, а не по абзацам. Готовьтесь переписывать статью как минимум один раз.
• К 2026 году файл llms.txt станет стандартом де-факто. Освойте его за пару часов.
• Не внедряйте RAG, если у вас нет метрик на точность ответов (RAGAS, DeepEval) и инженера, который будет чинить pipeline.
• Агентная документация (исполнение инструкций) — следующий этап, но он требует зрелого RAG и зрелой продуктовой команды.
• Самый прагматичный путь: стартуйте с гибридного поиска (Elasticsearch + простой ранжер), добавьте LLM только на неуверенные запросы. Это даст 80% выгоды за 20% усилий.
• Техписам нужно осваивать эмбеддинги и метаданные. Просто писать хорошие тексты больше недостаточно — RAG пережевывает только структурированный контент.
• Не верьте в "RAG из коробки". Любые успешные кейсы — это тысячи часов ручной настройки контента и пайплайнов.

RAG - не хайп, а новая реальность. Вопрос не в том, внедрять ли его, а в том, как не разориться и не потерять доверие пользователей. Стартуйте с гибридного поиска, а LLM подключайте позже.