RAG для техподдержки разработчиков: контекст из документации улучшает ответы, но вредит краткости

RAG работает в 2 этапа (выполняются автоматически внутри одного запроса):

ЭТАП 1: Поиск контекста
Вопрос разработчика → Семантический поиск по документации/коду → 
Топ-N релевантных фрагментов

ЭТАП 2: Генерация с контекстом
Промпт = [Системная инструкция + Найденные фрагменты + Вопрос] → 
GPT генерирует ответ

В исследовании: RAG система автоматически искала по 77,900 сообщениям из чатов, документации и коду Firefox.

В обычном чате: Вы вручную загружаете документы и просите модель использовать их.

⚠️ Ограничение метода: RAG эффективен для технических вопросов с документацией. Не подходит для креативных задач, мнений, вопросов без справочной базы.

Задача: Вы консультант, помогаете клиенту выбрать CRM. У него свои требования, у каждой CRM — своя документация. Нужен точный ответ на основе реальных возможностей систем.

Промпт:

Прикрепляю документацию трёх CRM: amoCRM, Битрикс24, Мегаплан.

Вопрос клиента: "Какая CRM позволяет автоматически создавать задачи 
в Jira при смене статуса сделки?"

Найди ответ ТОЛЬКО в приложенной документации. Ограничься одним абзацем.
Укажи конкретные страницы документов, где нашёл информацию.

Результат:

Модель просканирует все три документа, найдёт разделы про интеграции и автоматизацию, и выдаст ответ вроде: "Битрикс24 и Мегаплан поддерживают интеграцию с Jira через REST API (Битрикс: раздел 'Webhooks', стр. 47; Мегаплан: 'Интеграции', стр. 23). amoCRM такой возможности не предлагает по состоянию документации."

Вместо общих фраз "обычно CRM умеют интегрироваться" вы получите конкретный ответ с ссылками на источники.

Слабость LLM: Модель не знает специфику вашего проекта, версии софта, внутренние соглашения. Она генерирует ответ из общего обучения, которое может быть устаревшим или неточным. Для Firefox это означало ответы про несуществующие функции (GPT выдумывал --enable-release флаг, которого нет).

Сильная сторона LLM: Модель отлично синтезирует информацию — берёт куски текста и формулирует связный ответ. Если дать ей правильные исходники, она сделает из них понятное объяснение.

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

Трейдофф: Больше контекста = более comprehensive ответ, но часто это означает больше слов. В исследовании RAG был самым многословным источником (22.9% concise vs 29.1% у GPT). Инженеры ценили детальность, но жаловались на "слишком много информации".

Рычаги управления:

• Ограничение длины — "ответь одним абзацем" сокращает verbose (так делали в исследовании)
• Фильтр источников — загружай только нужные разделы документации, не всё подряд
• Инструкция на вывод — "только факты из документов, без общих рассуждений"
• Приоритет краткости — явно проси "максимально кратко", если conciseness важнее comprehensive

Прикрепляю документацию: {список_файлов}

Вопрос: {твой_вопрос}

Требования к ответу:
- Используй ТОЛЬКО информацию из приложенных документов
- Если ответа нет в документах — скажи "не нашёл в документации"
- Укажи источник (название файла / раздел / страницу)
- Ограничься {лимит_длины} (например: "одним абзацем", "3 пунктами")

Ответ:

Как заполнять:

• {список_файлов} — загрузи PDF, MD, TXT с документацией проекта
• {твой_вопрос} — конкретный вопрос, на который должен быть ответ в документах
• {лимит_длины} — "одним абзацем", "максимум 100 слов", "3 пунктами" — контролирует verbose

🚀 Быстрый старт — вставь в чат:

Вот шаблон для работы с документацией. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит какие документы загрузить, какой вопрос задать, какой формат ответа нужен — потому что ей нужно знать область поиска и ожидания по структуре. Она возьмёт паттерн из шаблона и адаптирует под задачу.

⚠️ Многословность: RAG часто перебарщивает с деталями. Был самым verbose среди трёх источников (люди, GPT, RAG). Инженеры говорили "слишком много лишней информации".

⚠️ Качество зависит от документации: Если в документах нет ответа или документы устаревшие — RAG выдаст некачественный результат. Garbage in, garbage out.

⚠️ Не для всех задач: RAG эффективен для справочных вопросов (как сделать X? что делает функция Y?). Для креативных задач, мнений, абстрактных вопросов — избыточен.

⚠️ Требует контекстного окна: Чем больше документации, тем больше токенов съедается. Для огромных баз знаний чат может не потянуть — понадобится полноценная RAG-система с векторной БД.

Команда Mozilla взяла 52 реальных вопроса из чатов разработчиков Firefox за 2024 год. Отфильтровали из 77,900 сообщений — оставили только технические вопросы про код, документацию, фичи (не про версии, не абстрактные, не переадресации).

Для каждого вопроса получили три ответа:

1. Human — оригинальный ответ из чата от разработчика Firefox
2. GPT — ответ от GPT-4o без доп.контекста
3. RAG — ответ от GPT-4o + автоматически найденные фрагменты из документации/кода Firefox

RAG построили на базе Cognita Framework (опенсорс) — доработали, чтобы индексировал код (.js, .jsx), документы (.md, .html, .pdf). Проиндексировали репозиторий Gecko-Dev (код Firefox) + wiki + документацию. Стоимость: ~$28 на векторизацию, $3 на инференс.

8 инженеров Mozilla оценивали ответы вслепую (не знали кто автор). Каждый получил 10 вопросов: 6 уникальных + 4 общих (чтобы измерить согласованность оценок). Оценивали по 4 критериям:

• Helpful — помогает ли решить проблему?
• Comprehensive — полный ли ответ?
• Concise — краткий без потери сути?
• Preferred — какой бы выбрал на практике?

Результаты показали:

• RAG обогнал людей по comprehensive (62.5% vs 54.1%) — детальнее
• RAG догнал людей по helpful (75% vs 79.1%) — почти так же полезен
• RAG проиграл по concise (22.9% vs 25% люди, 29.1% GPT) — многословный
• RAG чаще выбирали на практике (39.5% vs 34.8% люди, 25.6% GPT)

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

Корреляция показала: Helpful сильнее всего влияет на выбор ответа (0.84), потом Comprehensive (0.76), слабее всего Concise (0.51). Детальность важнее краткости для разработчиков, когда речь про технические вопросы.

Интересный инсайт: GPT иногда выдавал уверенно неправильные ответы (например, предлагал флаг --enable-release, которого не существует). RAG таких ляпов избегал, потому что опирался на документацию.

Исследователи использовали такой промпт для генерации ответов:

Контекст (для GPT и RAG):

You are a helpful assistant for developers working on the Mozilla Firefox project.
Please provide a concise response to the following question in a single paragraph.

Для RAG добавлялось:

Context:
[Retrieved documentation fragments here]

Question: [Developer's question]

Пример RAG-ответа из исследования (Question 5):

Вопрос: "Can i convert nsString to nsCString?"

RAG ответ:

Yes, you can convert an nsString (UTF-16) to an nsCString (UTF-8) using 
the NS_ConvertUTF16toUTF8 helper class. For example, you can do: 
nsCString utf8String = NS_ConvertUTF16toUTF8(utf16String); 
where utf16String is your nsString instance.

Контекст: Исследователи специально ограничивали ответы "одним параграфом", потому что ранние версии без этого ограничения были слишком verbose для чата. Это важный паттерн — явно контролируй длину, иначе RAG разойдётся.

💡 Адаптация для поддержки клиентов:

Вместо технической документации Firefox — база знаний вашего продукта. Загружаете FAQ, инструкции, политики возврата. Клиент задаёт вопрос → RAG ищет ответ в базе → выдаёт точный ответ со ссылкой на раздел.

Прикрепляю базу знаний: FAQ.pdf, Инструкция_по_возврату.pdf, Политика_доставки.md

Вопрос клиента: "Можно ли вернуть товар, если я его уже открыл?"

Требования:
- Используй ТОЛЬКО информацию из приложенных документов
- Укажи раздел документа, где нашёл ответ
- Ограничься 2-3 предложениями

💡 Адаптация для обучения:

Студент изучает сложный учебник. Загружает главы в чат и задаёт вопросы. RAG ищет ответы прямо в учебнике, а не в общем знании модели.

Прикрепляю главы учебника: Глава_3_Макроэкономика.pdf, Глава_4_Инфляция.pdf

Вопрос: "Как Центробанк влияет на инфляцию через ключевую ставку?"

Требования:
- Цитируй учебник дословно, где это важно
- Укажи номер главы и страницы
- Объясни простыми словами после цитаты

🔧 Техника: Убрать ограничение на длину → видеть полное рассуждение

В оригинале промпта есть "ответь одним параграфом". Если убрать — модель покажет пошаговую логику, как пришла к выводу. Полезно для сложных вопросов, где важно понять ход мысли.

Прикрепляю документацию: {твои_файлы}

Вопрос: {сложный_технический_вопрос}

Требования:
- Используй ТОЛЬКО информацию из документов
- Покажи пошагово: какие разделы изучил, какие выводы сделал
- В конце — итоговый ответ

🔧 Техника: Добавить "объясни почему" → глубже понимание

Стандартный RAG выдаёт факт. Если добавить "объясни логику" — модель не только найдёт ответ в документации, но и расскажет почему так работает.

Прикрепляю документацию: API_reference.pdf

Вопрос: "Почему метод fetchData() требует токен авторизации?"

Требования:
- Найди требование в документации
- Объясни техническую причину (безопасность, архитектура)
- Приведи пример из документации

A Comparison of Conversational Models and Humans in Answering Technical Questions: the Firefox Case

Авторы: João Correia, Daniel Coutinho, Marco Castelluccio, Caio Barbosa, Rafael de Mello, Anita Sarma, Alessandro Garcia, Marco Gerosa, Igor Steinmacher

Организации: Pontifical Catholic University (Rio de Janeiro), Federal University of Rio de Janeiro, Northern Arizona University, Oregon State University, Mozilla Corporation

Упоминаемые технологии: Cognita Framework (опенсорс RAG система), Matrix.org (платформа общения разработчиков), GPT-4o