Спасибо за вопросы - по сути всё верно поняли, риски есть. Кратко, как у нас устроено.
Инъекции. Текст тикета действительно попадает в языковую модель, и в описании теоретически можно попытаться "переписать" её поведение. Но в автоматической обработке Jira модель не крутится в свободном цикле "сама решает, что делать дальше" - порядок шагов задан заранее: проверка тикета - выбор маршрута (логи, документация, база) - сбор фактов - формулировка ответа - публикация комментария.
Данные из логов и базы модель не "вытягивает сама по тексту тикета" - их собирают отдельные сервисы. В финальный запрос попадают уже проверенные факты, а не всё подряд. Комментарий в Jira собирается по шаблону, перед отправкой из текста вырезается явно опасное (например, команды изменения базы).
В чате у модели тоже не произвольный доступ ко всему - только заранее описанный набор действий: поиск по документации, разбор логов, запрос к базе и т.д.
Полной защиты от таких атак нет - мы снижаем ущерб тем, что даже "обманутая" модель не может одним текстом тикета выполнить произвольный запрос или опубликовать что угодно.
Доступ через MCP. Система живёт во внутренней сети, снаружи недоступна. Пользуются ею сотрудники команды - разработка, поддержка, аналитика и.тд.
MCP здесь не "прямой провод ко всей инфраструктуре", а прослойка к нашим сервисам. К базе можно обратиться только к заранее разрешённым базам и таблицам, только на чтение, с ограничением числа строк. К логам - только через сервис анализа и только для микросервисов из каталога, а не к произвольному хранилищу.
Персональные данные. Мы не обезличиваем всё перед каждым вызовом модели. При разборе инцидента ей нужны конкретные идентификаторы - иначе ответ бесполезен.
Что делаем:
в модель не отдаём сырые логи целиком - только сжатую таблицу ошибок и короткое резюме;
в логах работы сервисов маскируем чувствительные данные;
Модели используются только для ответа на запрос, без дообучения на наших тикетах и логах. Один диалог не "перетекает" в другой.
База данных. Запросы идут в реплику для чтения, не в основную базу. Дополнительно: роль только на чтение, белые списки таблиц, проверка текста запроса, лимит строк и таймауты на уровне сервиса.
Основную базу таким запросом не положить. Реплику теоретически можно перегрузить тяжёлым запросом - для этого как раз стоят ограничения сверху.
Да, знаком. GraphRAG хорош для multi-hop reasoning - когда нужно связать несколько фактов в цепочку, а не просто найти один кусок текста.
Но за это платишь сложностью: нужно строить и поддерживать граф знаний (сущности, связи, обновления, контроль качества - чтобы в граф не попадали ложные, устаревшие или противоречивые связи). Это сильно тяжелее, чем классический RAG с гибридным поиском.
В проде использовать можно, но технология ещё относительно молодая и требует зрелого пайплайна.
У нас сейчас запросы в основном не требуют сложного многошагового вывода по связям между сущностями, поэтому хватает hybrid RAG. GraphRAG держим в поле зрения на будущее.
Команда небольшая - фактически два человека. Руководитель проекта (он как раз описывал свою роль в первой части статьи) и я, на мне была вся кодовая часть решения.
Первый коммит появился примерно полгода назад. Разработка шла без выделенного фуллтайма - в основном в свободное от основной работы время.
В тестировании также участвовали коллеги из команды технической поддержки - подключались все желающие и давали обратную связь.
Предварительно, для оценки качества мы остановились на двух основных метриках:
Качество ответов - измеряем семантическое сходство с эталонным ответом: Similarity (косинусная схожесть) - сравниваем эмбеддинги полученного и эталонного ответов. Значение от 0 до 1, где 1 - полное совпадение по смыслу.
Качество retrieval - оцениваем точность поиска документов: Precision@5 - доля релевантных документов среди первых 5 результатов поиска. Показывает, насколько точно система находит нужные документы для ответа.
Спасибо за вопросы - по сути всё верно поняли, риски есть. Кратко, как у нас устроено.
Инъекции. Текст тикета действительно попадает в языковую модель, и в описании теоретически можно попытаться "переписать" её поведение. Но в автоматической обработке Jira модель не крутится в свободном цикле "сама решает, что делать дальше" - порядок шагов задан заранее: проверка тикета - выбор маршрута (логи, документация, база) - сбор фактов - формулировка ответа - публикация комментария.
Данные из логов и базы модель не "вытягивает сама по тексту тикета" - их собирают отдельные сервисы. В финальный запрос попадают уже проверенные факты, а не всё подряд. Комментарий в Jira собирается по шаблону, перед отправкой из текста вырезается явно опасное (например, команды изменения базы).
В чате у модели тоже не произвольный доступ ко всему - только заранее описанный набор действий: поиск по документации, разбор логов, запрос к базе и т.д.
Полной защиты от таких атак нет - мы снижаем ущерб тем, что даже "обманутая" модель не может одним текстом тикета выполнить произвольный запрос или опубликовать что угодно.
Доступ через MCP. Система живёт во внутренней сети, снаружи недоступна. Пользуются ею сотрудники команды - разработка, поддержка, аналитика и.тд.
MCP здесь не "прямой провод ко всей инфраструктуре", а прослойка к нашим сервисам. К базе можно обратиться только к заранее разрешённым базам и таблицам, только на чтение, с ограничением числа строк. К логам - только через сервис анализа и только для микросервисов из каталога, а не к произвольному хранилищу.
Персональные данные. Мы не обезличиваем всё перед каждым вызовом модели. При разборе инцидента ей нужны конкретные идентификаторы - иначе ответ бесполезен.
Что делаем:
в модель не отдаём сырые логи целиком - только сжатую таблицу ошибок и короткое резюме;
в логах работы сервисов маскируем чувствительные данные;
Модели используются только для ответа на запрос, без дообучения на наших тикетах и логах. Один диалог не "перетекает" в другой.
База данных. Запросы идут в реплику для чтения, не в основную базу. Дополнительно: роль только на чтение, белые списки таблиц, проверка текста запроса, лимит строк и таймауты на уровне сервиса.
Основную базу таким запросом не положить. Реплику теоретически можно перегрузить тяжёлым запросом - для этого как раз стоят ограничения сверху.
Да, знаком. GraphRAG хорош для multi-hop reasoning - когда нужно связать несколько фактов в цепочку, а не просто найти один кусок текста.
Но за это платишь сложностью: нужно строить и поддерживать граф знаний (сущности, связи, обновления, контроль качества - чтобы в граф не попадали ложные, устаревшие или противоречивые связи). Это сильно тяжелее, чем классический RAG с гибридным поиском.
В проде использовать можно, но технология ещё относительно молодая и требует зрелого пайплайна.
У нас сейчас запросы в основном не требуют сложного многошагового вывода по связям между сущностями, поэтому хватает hybrid RAG. GraphRAG держим в поле зрения на будущее.
Команда небольшая - фактически два человека.
Руководитель проекта (он как раз описывал свою роль в первой части статьи) и я, на мне была вся кодовая часть решения.
Первый коммит появился примерно полгода назад. Разработка шла без выделенного фуллтайма - в основном в свободное от основной работы время.
В тестировании также участвовали коллеги из команды технической поддержки - подключались все желающие и давали обратную связь.
Предварительно, для оценки качества мы остановились на двух основных метриках:
Качество ответов - измеряем семантическое сходство с эталонным ответом: Similarity (косинусная схожесть) - сравниваем эмбеддинги полученного и эталонного ответов. Значение от 0 до 1, где 1 - полное совпадение по смыслу.
Качество retrieval - оцениваем точность поиска документов: Precision@5 - доля релевантных документов среди первых 5 результатов поиска. Показывает, насколько точно система находит нужные документы для ответа.