Как поиск по смыслу помогает ИИ находить решения инцидентов в runbook‑документации

В операционной работе инженеры нередко тратят время на повторное «изобретение» решений для уже известных инцидентов, хотя нужные инструкции давно описаны во внутренних runbook. Корень проблемы в поиске. Обычный поиск по ключевым словам пропускает записи, если они сформулированы иначе. Например, в runbook проблема может называться «connection pool exhausted», тогда как алерт сообщает «too many clients already». Речь об одном и том же инциденте, но совпадающих слов нет. Как сообщает Towards AI, закрыть этот разрыв помогает использование embeddings и подхода retrieval‑augmented generation (RAG): поиск начинает опираться на смысл, а не на буквальные совпадения текста.

Embedding‑модель переводит текст в числовой вектор, то есть список чисел размерностью обычно от нескольких сотен до пары тысяч. Модель обучена так, что тексты с близким смыслом оказываются рядом в этом пространстве. Сходство измеряют через cosine similarity, метрику угла между векторами. Её значение лежит между −1 и 1: чем ближе к 1, тем ближе смысл. В рабочей системе каждый документ сначала переводят в вектор. Затем создаётся вектор для пользовательского запроса, после чего выполняется поиск ближайших документов, top‑K nearest neighbor search.

RAG использует этот поиск как первый шаг. Система не полагается на «память» языковой модели. Сначала она извлекает несколько документов, наиболее близких по смыслу, из внутренней базы, добавляет их в prompt и только потом генерирует ответ. В таком сценарии модель не пытается угадывать решение, она формирует ответ на основе найденных runbook.

Когда такой подход внедряют в процесс реагирования на инциденты, всплывают практические вопросы. Embedding остаётся самой дорогой операцией, поэтому документы обычно векторизуют один раз при добавлении или изменении и кэшируют результат, например через хеш содержимого. Реальные запросы часто собираются из логов, stack trace и названий сервисов, в них могут попадать секреты или PII. По этой причине текст очищают перед отправкой на embedding‑endpoint, а извлечённые фрагменты дополнительно фильтруют. Поиск также ограничивают контекстом конкретного сервиса, иначе в корпусе из тысяч документов появляется слишком много шума.