TL;DR
RAG4Tickets — исследование, которое показывает: LLM даёт точнее решения, когда ты загружаешь в промпт похожие прошлые кейсы с их решениями. Система автоматически ищет в JIRA и GitHub похожие тикеты по смыслу (не по словам), собирает контекст (описание + комментарии + код из PR) и даёт LLM как референс. Исследователи построили это через эмбеддинги, векторный поиск FAISS и API, но принцип работает и вручную в чате.
Проблема: когда разработчик или саппорт видит новый баг, он ищет похожие случаи по ключевым словам — "React crash", "API timeout". Но тикет может быть описан иначе: "UI freezes on feature toggle" vs "app freeze due to concurrent rendering". Смысл тот же, слова разные — поиск не находит. Плюс информация размазана: описание в тикете, подсказки в комментах, фикс в GitHub PR. Приходится вручную собирать пазл, тратить часы.
Решение: семантический поиск (по смыслу проблемы) + агрегация контекста из всех источников + grounding LLM через примеры. Система находит 3-5 похожих тикетов, вытаскивает их описания, обсуждения, ссылки на PR с решениями, упаковывает в промпт. LLM синтезирует: "вот паттерн проблемы, вот как её фиксили раньше, вот конкретный код из PR #234". Время решения упало с 18.5 до 10.2 часов (−45%), разработчики приняли 68% предложений без правок.
Схема метода
Автоматическая версия (требует код):
ШАГ 1: Встроить тикет в вектор (Sentence-Transformers)
ШАГ 2: Найти top-5 похожих через FAISS (векторный поиск)
ШАГ 3: Собрать контекст: тикет + комменты + PR
ШАГ 4: Дать LLM контекст → генерация решенияРучная версия (в чате):
ШАГ 1: Найди в истории 2-3 похожих проблемы (GitHub, JIRA, Slack)
ШАГ 2: Скопируй описание + решение
ШАГ 3: Добавь свою проблему
ШАГ 4: Попроси LLM синтезировать решение на основе примеровПример применения
Задача: Ты саппорт-инженер в российской SaaS-компании (типа Битрикс24, amoCRM). Клиент жалуется: "При импорте контактов из Excel CRM зависает на файлах больше 5000 строк". Ты помнишь, что подобное было, но не помнишь точно где.
Промпт:
Я саппорт-инженер. Вот текущая проблема клиента:
ПРОБЛЕМА:
"При импорте контактов из Excel (файл 7000 строк) CRM зависает через 2 минуты.
Прогресс-бар останавливается на 30%. В консоли ошибка: timeout."
Вот похожие решённые кейсы из нашей истории:
КЕЙС 1:
Проблема: "Импорт из CSV больше 3000 строк падает с ошибкой memory limit"
Решение: Добавили batch processing — импорт по 500 строк за раз.
Код: разбили массив на chunks, добавили sleep(1) между батчами.
КЕЙС 2:
Проблема: "Excel импорт зависает на больших файлах"
Решение: Проблема в PHP timeout (30 сек). Подняли до 300 в конфиге.
Плюс добавили прогресс через AJAX — теперь frontend не ждёт ответ,
а опрашивает статус каждые 5 секунд.
На основе этих примеров:
1. Диагностируй вероятную причину текущей проблемы
2. Предложи пошаговое решение
3. Укажи что проверить в первую очередьРезультат:
LLM проанализирует паттерны из прошлых кейсов, выделит общие причины (timeout, memory, batch processing), и предложит конкретный план: проверить логи на timeout, увеличить лимиты в конфиге, реализовать chunk-based импорт. Даст конкретные цифры (batch по 500 строк, timeout 300 сек) на основе того, что работало раньше. Плюс укажет на AJAX-опрос статуса как UX-улучшение.
Почему это работает
Слабость LLM: Когда спрашиваешь "как пофиксить зависание импорта" — модель даёт общие советы из training data. Это может быть устаревшее, неточное или не подходящее для твоего стека. Hallucination — модель придумывает правдоподобно звучащие, но неработающие решения.
Сильная сторона LLM: Модель отлично синтезирует паттерны, если ей дать конкретные примеры. Она видит: "В обоих кейсах проблема с большими файлами решалась через batching + timeout increase", и применяет этот паттерн к новому случаю. Grounding через retrieval — вместо галлюцинаций модель опирается на реальные решения.
Как метод использует это: RAG (Retrieval-Augmented Generation) работает в два шага: сначала retrieval (найди похожие кейсы), потом generation (синтезируй решение из них). Это как спросить опытного коллегу: "Вспомни, как мы фиксили подобное раньше" → "Окей, вот три случая" → "Отлично, значит и тут попробуем batch processing".
Рычаги управления:
- Количество примеров (2-3 vs 5-7) → больше примеров = точнее паттерн, но длиннее промпт
- Детальность контекста (только решение vs решение + код + обсуждение) → больше деталей = конкретнее рекомендации
- Фильтр по времени (только за последний год vs вся история) → свежие примеры актуальнее, старые могут быть устаревшими
- Тип артефактов (только тикеты vs тикеты + PR + код) → добавление кода даёт implementation details
Шаблон промпта
Я {роль}. Вот текущая проблема:
ПРОБЛЕМА:
{описание_проблемы}
Похожие решённые кейсы:
КЕЙС 1:
Проблема: {описание_похожей_проблемы_1}
Решение: {как_решили_1}
{опционально: код, конфиг, детали}
КЕЙС 2:
Проблема: {описание_похожей_проблемы_2}
Решение: {как_решили_2}
{опционально: ещё кейсы}
На основе этих примеров:
1. Диагностируй вероятную причину текущей проблемы
2. Предложи пошаговое решение
3. Укажи что проверить в первую очередьЧто подставлять:
{роль}— саппорт-инженер, разработчик, DevOps{описание_проблемы}— текущий баг/вопрос со всеми деталями (симптомы, логи, контекст){описание_похожей_проблемы_X}— как была сформулирована проблема в прошлом кейсе{как_решили_X}— что конкретно сделали, чтобы пофиксить- Опционально: добавь код из PR, изменения в конфиге, обсуждение в комментах
Где искать похожие кейсы:
- GitHub Issues (твой проект + похожие open-source)
- JIRA (если есть доступ к истории)
- Внутренняя база знаний / Confluence
- Stack Overflow (для типовых проблем)
- Slack/Telegram (поиск по ключевым словам в канале техподдержки)
Ограничения
⚠️ Требует ручной работы: Без автоматизации нужно самому найти похожие кейсы — это может занять время. В исследовании это делает векторный поиск FAISS, но в чате ты ищешь вручную.
⚠️ Качество зависит от истории: Если в базе нет похожих проблем или решения были неправильными — LLM может унаследовать ошибки. Проверяй логику предложенных решений.
⚠️ Semantic drift: Если технологии изменились (React 18 → React 19, Python 2 → 3), старые решения могут быть неактуальными. Фильтруй по времени, приоритизируй свежие кейсы.
⚠️ Не работает для уникальных проблем: Если проблема новая и похожих кейсов нет — метод не поможет. LLM вернётся к общим рекомендациям.
Как исследовали
Команда собрала 15,000 тикетов из JIRA и 6,500 pull requests из GitHub с реального проекта — миграции на React 19 в микросервисной архитектуре. Проблема типичная: множество команд, куча повторяющихся багов, информация размазана по тикетам, комментам и PR.
Исследователи встроили все тикеты, комменты и PR в векторы через Sentence-Transformers (модель all-MiniLM-L6-v2 для текста, CodeBERT для кода), проиндексировали через FAISS HNSW для быстрого поиска по смыслу. Когда приходил новый тикет, система находила top-5 самых похожих, собирала контекст (описание + обсуждения + связанные PR с фиксами), и давала GPT-4/Claude как примеры в промпте.
Результаты удивили практической применимостью: система нашла релевантные кейсы в top-5 результатов в 82% случаев (Recall@5), в top-10 — 91%. Но главное — время решения упало с 18.5 до 10.2 часов (−45%), и разработчики приняли 68% предложений либо сразу, либо с минимальными правками. Это не теоретический бенчмарк — реальные люди экономили по 8+ часов на тикете.
Интересный инсайт: factual grounding (процент ответов LLM, подтверждённых реальными документами) был 84%. Остальные 16% — лёгкие hallucinations, когда модель экстраполировала за пределы примеров. Исследователи отметили: retrieval-verification layer (проверка что LLM опирается только на retrieval) — критичен для production.
Сравнивали три типа FAISS индексов: Flat (точный, но медленный), HNSW (баланс скорости и точности), IVF (быстрый, но неточный). HNSW выиграл: latency упала на 73% vs Flat, при этом recall просел всего на 2%. Это показало — для enterprise-масштаба (миллионы тикетов) нужен именно HNSW.
Ресурсы
RAG4Tickets: AI-Powered Ticket Resolution via Retrieval-Augmented Generation on JIRA and GitHub Data — Mohammad Baqar, Cisco Systems Inc.
Ключевые отсылки из исследования:
- Lewis et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" — оригинальная статья про RAG
- Johnson, Douze, Jégou (2019). "Billion-scale similarity search with FAISS" — про векторный поиск
- Reimers & Gurevych (2019). "Sentence-BERT" — про эмбеддинги для семантического поиска