Автор статьи: Александр Летуновский

Проблематика

Современные крупные организации сталкиваются с большим числом ИТ‑инцидентов — счет может идти на тысячи в месяц. Инциденты нередко повторяются со временем, однако найти похожий случай в базе знаний или в системе регистрации инцидентов непросто: стандартный поиск по ключевым словам часто неэффективен, а «держать в голове» детали всех инцидентов невозможно.

Отсюда возникает проблема: при поступлении нового инцидента инженеру трудно выяснить, не случалось ли подобное раньше и как тогда было решено. Многие знания остаются «рассеянными» по прошлым тикетам и не переиспользуются. В лучшем случае на помощь приходит опытный коллега, который вдруг вспоминает: «Да, в прошлом месяце у нас уже было нечто подобное, и причина тогда была такая‑то».

Такая ситуация натолкнула на идею создать систему, которая выступала бы искусственной «памятью» ИТ‑команды: мгновенно просматривала бы все предыдущие инциденты и находила релевантную информацию, когда она нужна. По сути, хотелось, чтобы при разборе нового инцидента система играла роль своего рода опытного инженера, «видевшего» все предыдущие проблемы, и подсказывала возможное решение.

Цель работы

Целью проекта стало автоматизировать сопоставление новых инцидентов с ранее решёнными и предоставлять инженерам рекомендации по их решению в виде комментария в тикете. Иными словами, требовалось разработать помощника, который при каждом новом инциденте будет искать в накопленной базе знаний несколько самых схожих по описанию случаев и на основе описаний их решений формулировать совет: что может быть причиной проблемы и как её устранить. Такой подход, совмещающий поиск по базе знаний с генерацией текста, известен как Retrieval‑Augmented Generation (RAG) — генерирование ответа с дополнением из внешней базы знаний.

В рамках проекта предполагалось реализовать минимально жизнеспособный прототип (MVP) и интегрировать его в промышленную среду системы Service Desk. Основные критерии успеха — ускорение анализа инцидентов (уменьшение времени на поиск решения) и повышение процента повторного использования знаний, накопленных в организации.

Ограничения и особенности внедрения

Проект развернут и эксплуатируется в условиях существенных ограничений инфраструктуры. Во‑первых, среда полностью офлайн: ни база инцидентов, ни сервис генерации не имеют доступа к интернету или облачным API. Это обусловлено внутренними политиками безопасности. Поэтому все компоненты — от моделей до баз данных — должны быть размещены локально. Не было возможности воспользоваться облачными сервисами вроде OpenAI API или managed‑векторными базами, все пришлось настраивать «on‑premise».

Вторым ограничением стало отсутствие производительных графических процессоров (GPU) на этапе MVP. Сервер, на котором разворачивается решение, оснащен только CPU. Это повлияло на выбор моделей и инструментов: предпочтение отдавалось легковесным и оптимизированным вариантам.

Из‑за офлайн‑режима также встали вопросы обновления и поддержки. Все обновления моделей (как эмбеддинг модели, так и LLM) требуют отдельной процедуры загрузки моделей в контур. Тем не менее, подобный автономный режим — частая ситуация в корпоративных внедрениях, и дкльнейшее решение показало, что даже без доступа к облачным мощностям можно эффективно применять методы NLP на локальных ресурсах.

Ход работы

Для решения поставленной задачи была спроектирована архитектура RAG‑агента, включающая интеграцию с системой Service Desk, векторную базу данных для знаний об инцидентах и использование большой языковой модели (LLM) для генерации подсказок. Агент реализован на Python. Ниже приведена схема логики работы разработанного агента.

Как показано на схеме, процесс состоит из нескольких шагов:

1. Получение инцидента: агент отслеживает появление нового инцидента в системе Service Desk и через API выгружает его описание в текстовом формате (HTML‑разметка очищается до чистого текста).

2. Дополнение описания: исходное описание инцидента при необходимости автоматически дополняется или переформулируется с помощью большой языковой модели, чтобы уточнить суть проблемы (например, извлечь ключевые симптомы, дополнить короткое описание, удалить лишние детали из описания).

3. Векторизация описания: текст инцидента (как в оригинале, так и переформулированный вариант) преобразуется в векторное представление — embedding — при помощи модели эмбеддинга.

4. Поиск похожих инцидентов: полученный вектор сравнивается с векторами ранее решённых инцидентов, хранящимися в векторной базе данных, с использованием метрики косинусного расстояния. В результате извлекаются несколько наиболее похожих описаний из базы (топ-5 по оригинальному тексту и топ-5 по переформулированному).

5. Генерация рекомендаций: собранная информация подаётся на вход большой языковой модели — формируется запрос (prompt), содержащий описание новой проблемы и сведения о найденных похожих инцидентах (описания и решения). LLM анализирует этот контекст и генерирует рекомендацию — комментарий с предположением о причине проблемы и советом по её решению.

6. Обновление базы знаний: векторное представление нового инцидента сохраняется в векторной базе (вместе с текстом описания и решения после закрытия инцидента) для использования в будущем.

7. Публикация решения: сгенерированная LLM рекомендация и список ссылок на похожие прошлые инциденты автоматически отправляется в систему Service Desk в виде комментария к соответствующему тикету, где его видят инженеры.

Далее рассмотрены ключевые компоненты этой системы и принятые решения при её реализации.

Извлечение текста инцидентов из HTML

Первым шагом стало подключение к системе управления инцидентами (Service Desk) и извлечение необходимых данных. Интеграция реализована через REST API: агент периодически опрашивает систему на наличие новых тикетов или получает уведомление о них. Для каждого нового инцидента с помощью API вытягивается текст поля «Описание» (Description). Поскольку в Service Desk описания хранятся с разметкой (HTML), этот контент приводится к чистому тексту — удаляются HTML‑теги, лишние символы, приводятся в порядок списки и форматирование. Разбор HTML выполняется с помощью библиотеки парсинга BeautifulSoup4, добиваясь на выходе связного текста, пригодного для последующей обработки.

Пример кода очистки HTML от лишней информации:

def clean_html(html_content):
    """Remove HTML tags from the content."""
    if html_content is None:
        return None
    soup = BeautifulSoup(html_content, 'html.parser')
    return soup.get_text(strip=True)

При извлечении текста описания агент также может получить связанные с инцидентом данные, например дату/время создания инцидента, категорию проблемы, затронутый сервис или компоненты. Эти сведения в текущей версии напрямую не используются для поиска, но в будущем могут помочь фильтровать результаты (например, ограничивать поиск схожих инцидентов тем же сервисом или близким временем). Пока же основным источником информации для поиска выступает текстовое описание симптомов инцидента.

Векторизация описаний инцидентов

Когда от нового инцидента получен текст описания, следующей задачей является получение его векторного представления (embedding). Векторное представление — это набор чисел (координат векторов в многомерном пространстве), которые отражают смысл текста. Современные трансформерные модели способны превращать фразу или документ в такой числовой «отпечаток», близкий для похожих по содержанию текстов и далекий для несхожих. Иными словами, если два описания инцидентов описывают схожие проблемы, их векторы будут расположены близко друг к другу в пространстве; если же тематика разная — векторы будут далеки. Важное свойство эмбеддингов (в отличие от простых хеш‑функций) состоит в том, что концептуально схожий ввод приводит к близким векторным значениям — даже если тексты формально не совпадают по словам. Благодаря этому можно сравнивать семантическое сходство: по сути, алгоритм научается «сравнивать яблоки и апельсины» по смыслу, а не по буквальному совпадению.

Для вычисления степени близости векторов используется метрика косинусного расстояния (cosine similarity) — она возвращает значение от 0 до 1, отражающее степень сходства, и широко применяется для ранжирования похожести текстов. Чем меньше значение метрики, тем ближе по смыслу тексты.

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

• all‑MiniLM‑L6-v2 — компактная модель размерности 384, давала хорошую скорость, но уступала по качеству: в исторических данных пропускала релевантные случаи или ранжировала их ниже;

• LaBSE‑en‑ru — урезанная модель от Google с размерностью вектора 768, содержащая только токены русского и английского языка, очень хорошо справлялась с текстами инцидентов;

• ru‑en‑RoSBERTa — русско‑английская модель с размерностью векторов 1024, специально дообученная для работы с двуязычными текстами.

По итогам экспериментов победителем по качеству поиска схожих инцидентов стала модель ru‑en‑RoSBERTa: она показала наилучшее ранжирование и точность сопоставления, особенно при анализе инцидентов, содержащих технические термины, коды ошибок и смешанную лексику. В частности, она лучше других справлялась с короткими описаниями и контекстами без явных ключевых слов. Поэтому окончательный выбор пал на ru‑en‑RoSBERTa как наиболее сбалансированную по качеству и применимости к задачам проекта.

Пример кода, как использовать модель для получения эмбеддингов текста:

# Загрузка модели
model = SentenceTransformer('ru-en-RoSBERTa')

# Векторизация текста
vectors_description = model.encode(df['description'].tolist())

Переформулировка описаний с LLM. Особенностью подхода стало использование большой языковой модели (LLM) для улучшения качества векторизации. Как было сказано выше, иногда описания инцидентов бывают скудными или неочевидными, или наоборот слишком длинными. Например, тикет может содержать лишь фразу «Приложение не работает» или фрагмент лога, не коррелирующий напрямую с истинной проблемой. В таких случаях даже хорошая модель эмбеддинга может «не понять» суть и выдать не самых релевантных соседей. Поэтому был реализован шаг дополнительной обработки описания с помощью LLM: перед векторизацией агент может запросить у языковой модели переформулировать или дополнить/сжать описание, подчеркнув ключевые детали. По сути, LLM выступает как «улучшатель» запроса для поиска. Получив на вход краткий текст ошибки, модель генерирует более развернутое описание проблемы (например, предполагает, что именно не работает и при каких условиях), которое затем тоже превращается в вектор. Далее поиск похожих инцидентов (шаг 4) производится и по исходному, и по переформулированному описанию, выбирая наиболее близкие по смыслу инциденты. Такой прием позволил в ряде случаев извлекать из базы инцидентов более точные совпадения.

Пример промпта для LLM для переформулирования текстов инцидентов:

    prompt_template = """
Вы являетесь ИТ-специалистом, который обрабатывает ИТ-инциденты. 
Ваша задача — обработать описания ИТ-инцидентов, чтобы улучшить качество извлечения похожих текстов из векторного хранилища. Следуйте этим инструкциям:
Если запрос совсем короткий и недостаточно информативен, дополните его, добавив возможные причины, контекст или дополнительные детали.
Если запрос длинный и содержит много лишних деталей, в том числе повторяющихся - сократите его, оставив только ключевую информацию.
Уберите излишние подробности, но сохраните контекст, необходимый для понимания проблемы.
Верните только измененное описание инцидента, ничего больше.
Описание инцидента:
{query}

Ваш вариант:
"""

Векторная база данных

Для хранения всех эмбеддингов прошлых инцидентов и выполнения поиска по ним понадобилась специализированная база данных, поддерживающая операции с векторами. Рассматривалось несколько вариантов векторных баз данных (Vector DB): как интегрированных решений, так и отдельных движков. Среди популярных — полнофункциональные векторные хранилища Weaviate, Chroma, FAISS, а также расширения для классических СУБД, такие как PGVector для PostgreSQL.

PGVector добавляет тип данных «Vector», обеспечивая хранение эмбеддингов в виде векторов и поиск ближайших векторов по косинусному расстоянию, а также другими способами. Из достоинств такого решения — привычная работа с СУБД PostgreSQL и SQL запросами, надежность, масштабируемость.

Взвесив все варианты, был выбран именно PGVector.

Альтернативные решения как правило работают быстрее, иногда значительно быстрее. Но необходимо озаботиться вопросами надежности, сохранения/репликации данных, разбираться в нюансах администрирования. В данном случае скорость не так важна, поэтому выбор пал на PGVector.

Пример SQL кода создания таблицы для хранения инцидентов:

#Создание таблицы с инцидентами
conn = psycopg2.connect(**DB_CONFIG)
cur = conn.cursor()
cur.execute("""
    CREATE TABLE IF NOT EXISTS incidents (
        id SERIAL PRIMARY KEY,
        number INTEGER,
        creation_date DATE,
        report_text TEXT,
        theme TEXT,
        description TEXT,
        service TEXT,
        embedding_description vector(1024),
        llm_response TEXT
    );
""")
conn.commit()
cur.close()
conn.close()

В реализованной системе векторная база содержит таблицу, где для каждого ранее решенного инцидента хранится его идентификатор, время создания, ИТ‑сервис, по которому зарегистрирован инцидент, текстовые поля (описание, решение и др.) и векторное представление описания. При поступлении нового инцидента выполняется SQL‑запрос с оператором поиска ближайших соседей по вектору. В запросе указывается количество требуемых ближайших соседей k и условие по метрике (косинусной близости). Например, можно найти 5 наиболее похожих инцидентов по косинусному расстоянию, превышающему некоторый порог.

Пример SQL кода поиска похожих инцидентов:

# Функция для поиска похожих векторов по embedding
def search_similar_vectors(query, k=5, distance_threshold=0.5):
    query_vector = model.encode([query])[0].tolist()

    try:
        cur.execute("""
            SELECT id, number, creation_date, report_text, theme, description, service, embedding_combined,
                   (embedding_combined <=> %s::vector) AS distance
            FROM incidents
            WHERE embedding_combined <=> %s::vector < %s
            ORDER BY distance
            LIMIT %s
        """, (query_vector, query_vector, distance_threshold, k))

        results = cur.fetchall()
        return results
    except Exception as e:
        conn.rollback()
        print(f"Ошибка при поиске векторов: {e}")
        return []

На практике порог пришлось откорректировать: изначально допускались совпадения с близостью >0.5, но это приводило к попаданию нерелевантных случаев. После наблюдения за работой сервиса на протяжении пары недель порог был снижен до 0.15. Качество отбора существенно улучшилось — в список кандидатов стали попадать действительно только схожие тикеты. В дальнейшем возможно более тонкое ограничение — например, по категории услуги или по давности (не брать слишком старые инциденты), чтобы сузить контекст поиска.

Найденные похожие инциденты извлекаются из БД вместе с их описаниями и решениями. Отбирается до 5 записей, которые будут переданы языковой модели на анализ. После генерации рекомендации (шаг 5) информация о новом инциденте заносится в базу: сохраняется его эмбеддинг (чтобы будущие запросы находили и этот случай) и при закрытии инцидента — текст решения, связанный с данным описанием. Таким образом, база знаний постоянно пополняется новыми примерами, и со временем качество подсказок будет расти.

Выбор и использование LLM: Ollama + Gemma 3

Важнейшим компонентом системы является большая языковая модель (LLM), которая используется дважды: для улучшения описания (переформулировки) и для финальной генерации текста рекомендации. Поскольку проект развёртывается в офлайн‑среде (без доступа к облачным API), выбор пал на open‑source модель, которую можно запускать локально на имеющемся оборудовании. Дополнительные ограничения на этапе MVP — ограниченные ресурсы (отсутствие GPU) — означали, что модель должна быть относительно небольшой по числу параметров, иначе скорость ответа была бы неудовлетворительной. Исходя из имеющихся ресурсов (виртуальная машина с 48 vCPU и 32 Gb RAM), после тестирования нескольких моделей приемлемую скорость удалось получить на моделях размером не более 4В (4 млрд. параметров).

Были рассмотрены несколько современных открытых LLM. Среди них: Qwen 2.5, T‑lite 1.0, YandexGPT-5-Lite, Gemma-3. В итоге для прототипа была выбрана модель от Google Gemma 3–4b‑instruct — это LLM с 4 миллиардами параметров, обученная следовать инструкциям (instruct‑tuned). Хотя 4 млрд параметров — это существенно меньше, чем у самых продвинутых моделей, она справилась с задачами проекта. Модель была загружена в квантованном виде (4-бит), что еще больше снизило требования к памяти (до нескольких гигабайт) при минимальной потере качества. Использование 4-битной квантованной модели позволило запускать LLM инференс на CPU достаточно быстро — генерация рекомендации занимала порядка минуты.

Для простоты развёртывания модель Gemma 3b запускалась через инструмент Ollama — это локальный сервис, оптимизированный для LLM, который предоставляет простой API для генерации текста. Ollama облегчает использование моделей вроде Llama/Gemma: он берет на себя загрузку модели в память, управление контекстом, ускорение за счёт квантования и так далее. Агент взаимодействует с Ollama по API, отправляя промпт и получая завершённый ответ.

При работе выявились некоторые проблемы со стабильностью Ollama — иногда не удаётся получить ответ от модели без видимых проблем в логах. В дальнейшем планируется постоянно обновлять версию Ollama, пока не будет исправления. А в перспективе — полная замена Ollama на другой подобный инструмент, например VLLM, при появлении сервера с GPU.

Качество ответов выбранной модели оказалось вполне приемлемым. Несмотря на небольшой размер, Gemma-3–4b в большинстве случаев формулировала корректные и уместные рекомендации для инцидентов. Инженеры, оценивавшие ответы, отметили их полезность и адекватность. Модель редко «галлюцинировала», генерируя посторонний контент — все выводы действительно основывались на предоставленном контексте, как и требовалось. Очевидно, ограничение области знания только информацией об инцидентах компании (через примеры из базы) дисциплинирует даже небольшую LLM и помогает ей генерировать правдоподобные и целевые советы.

Применение LangChain и RAG

Для организации описанного взаимодействия компонентов использовался фреймворк LangChain, который предоставляет абстракции для построения цепочек вызовов LLM с дополнением из внешних источников. Сценарий работы RAG‑агента был реализован как последовательность из нескольких шагов (Chain) с промежуточным хранением результатов. По сути, была сформирована связка «Retriever — Analyzer — Action»: сначала блок Retriever выполняет векторный поиск похожих случаев, затем блок Analyzer (LLM) на основе найденного анализирует ситуацию и формирует ответ, и наконец блок Action доставляет этот ответ обратно в систему, в нашем случае — публикует комментарий.

В LangChain предусмотрены компоненты для интеграции с векторными хранилищами (VectorStore). Однако прямой поддержки PGVector нет, поэтому обращение к базе PostgreSQL осуществлено через собственный запрос. Тем не менее, концептуально это тот же retriever: агент получает на вход текст запроса (описание инцидента), обращается к векторному индексу и получает топ‑N документов (описаний прошлых инцидентов) в качестве релевантного контекста. Далее формируется промпт для LLM, содержащий описание нового инцидента и извлеченные описания прошлых.

Пример кода, реализующего запрос к LLM через Langchain:

#Обработка инцидента с помощью LLM
def get_llm_response (query, context):
    # Настройка LangChain
    llm = OllamaLLM(model="gemma-3-4b-it.Q4_K_M:latest", base_url="http://localhost:11434", num_ctx=8192)

    # Создание промпта
    prompt_template = """
    Вы являетесь ИТ-специалистом, который обрабатывает ИТ-инциденты.
    На основе предоставленной информации о ранее закрытых инцидентах, дайте заключение о том, как лучше решить текущий инцидент.
    Ответ должен быть не более 3000 символов.
    Не повторяйтесь.
    Информация о ранее закрытых инцидентах:
    {context}

    Текущий инцидент:
    {query}

    Ваше заключение:
    """
    prompt = PromptTemplate(
        input_variables=["context", "incident"],
        template=prompt_template
    )

    # Создание цепочки
    chain = RunnableSequence(prompt | llm | StrOutputParser())

    # Обработка результата с помощью LLM
    llm_response = chain.invoke({"context": context, "query": query})
    # Вывод результатов
    return llm_response

После генерации текста LangChain‑цепочка выполняет финальный шаг: передает полученный ответ обратно через API Service Desk, добавляя комментарий в тикет. Инженер, работающий с системой, видит новый комментарий от виртуального ассистента (агента) с рекомендацией и списком ссылок на схожие инциденты. Дальше он может следовать совету либо игнорировать его — решение всегда остается за человеком, а агент лишь предоставляет информацию для поддержки решения.

Статистика внедрения и эффективность

Разработанный RAG‑агент был развернут как MVP на части потока инцидентов для тестирования. На момент подготовки статьи система обработала около 500 инцидентов. Среднее время, затрачиваемое агентом на полный цикл (от получения данных до публикации комментария), составило 1–2 минуты на инцидент. Это время существенно меньше, чем тратил бы инженер на ручной поиск похожих случаев и анализ, плюс гораздо меньше время реакции. По оценкам, экономия составляет в среднем 10 минут на каждый инцидент. Таким образом, например при ~1000 инцидентах в месяц потенциально экономится порядка 167 человеко‑часов, что эквивалентно работе примерно 1 инженера полной занятости.

Некоторые ключевые метрики и результаты внедрения MVP:

• Сокращение времени анализа: ~10 минут экономии на инцидент, что даёт более 80 часов в месяц экономии труда специалистов (напомню, это только часть общего потока инцидентов). Инженеры могут направить это время на более сложные задачи вместо поиска в документации.

• Оптимизация штата: высвобождение эквивалента 0,5 инженера за счет автоматизации.

• Снижение финансовых затрат: экономия фонда оплаты труда оценочно достигает 200–300 тыс. рублей в месяц за счёт автоматизации рутины, даже с учетом стоимости вычислительных ресурсов для работы агента.

• Ускорение решения инцидентов: быстрее находя решение, компания снижает время простоя сервисов и сопутствующие убытки. Выгода от сокращения downtime может составлять до нескольких миллионов рублей в месяц для инцидентов, влияющих на продажи или критичные процессы.

• Затраты на поддержку решения: использование открытых моделей позволило избежать прямых расходов на лицензии. Стоимость инфраструктуры, поддержка и доработка совокупно обходится не более, чем в 100 тыс. руб/мес. С учётом достигаемой экономии, окупаемость решения — порядка 1–2 месяцев. Первоначальные вложения (включая разработку) были невелики и тоже быстро окупились.

В целом, пилотное внедрение подтвердило ценность системы: агент экономит время и улучшает качество решения инцидентов.

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

Выводы и дальнейшее развитие

Проделанная работа продемонстрировала, что подход с использованием векторных представлений и больших языковых моделей может эффективно помочь в управлении инцидентами. По итогам MVP принято решение развивать проект дальше, расширяя его охват и функциональность.

Качество рекомендаций. Анализ итогов MVP показал, что советы агента в большинстве ситуаций корректны и полезны. Инженеры подтвердили, что полученные рекомендации соответствуют реальным причинам и решениям проблем, часто совпадая с их собственными выводами. Конечно, бывают ситуации, когда агент может предложить не оптимальное или не относящееся к ситуации решение — например, если в базе ещё нет похожего кейса или описания инцидента слишком размыты. Но даже в таких случаях наличие подсказки расширяет круг рассмотрения и может навести инженера на мысль.

Проблемы и уроки. В ходе внедрения выявлены некоторые проблемные моменты, требующие внимания.

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

Во‑вторых, качество исходных данных накладывает ограничения: если текст решения в прошлом инциденте был заполнен формально (например: «Исправлено» или «Решение применено»), то даже найдя такой кейс, агент принесет мало пользы. Требуется работа по улучшению качества закрытия инцидентов — возможно, регламентировать заполнение поля «Решение» или автоматически проверять тексты решений инцидентов с помощью той же LLM.

В‑третьих, обнаружилось, что для некоторых специфических услуг или систем даже семантический поиск не даёт результатов ввиду малого числа примеров. Это указывает на необходимость использовать и накапливать базу знаний по редким категориям — например, создавать отдельные векторные базы по каждому направлению, куда можно добавлять не только инциденты, но и связанные артефакты (документацию, FAQ) для повышения качества.

Планы развития. Следующими шагами в развитии системы станут: улучшение стабильности и производительности (в том числе перенос вычислений на GPU‑сервер при его появлении), обновление LLM модели до более качественной и подключение полного потока инцидентов. С накоплением данных откроются новые возможности аналитики — например, автоматический анализ качества решений инцидентов и поиск скрытых закономерностей в причинах сбоев. В перспективе такой агент может эволюционировать в полноценного помощника SRE/DevOps‑команды: не только подсказывать решения, но и проактивно уведомлять о повторяющихся проблемах, предлагать классификацию инцидентов, а возможно, и взаимодействовать с пользователями для сбора дополнительной информации.

Проект RAG‑агента для инцидент‑менеджмента показал, что современные методы NLP могут успешно применяться для интеллектуальной поддержки операционных процессов. Объединение методов семантического поиска и генерации позволяет извлекать ценность из корпоративной памяти, делая знания полезными и своевременными.

Данная статья подготовлена на основе проекта, выполненного и успешно защищённого автором в рамках курса Natural Language Processing OTUS (2024).

Хотите освоить технологии, стоящие за чат-ботами и голосовыми ассистентами?
Курс Natural Language Processing (NLP) поможет вам понять, как компьютеры работают с текстом. Пройдите короткий вступительный тест — и получите рекомендации по обучению. Это первый шаг к профессии в сфере ИИ.

Рекомендуем также посетить открытые уроки:
— «Unsupervised подходы: Сегментация временных рядов» (26 мая 2025)
— «Data Science — это проще, чем кажется!» (27 мая 2025)

Узнайте основы профессии и получите ответы от экспертов.