Привет, Хабр! На связи Денис Романов, директор департамента Professional Services компании «Базис». Яркое появление китайских языковых моделей заставило нас по-новому посмотреть на возможности нейросетей, и вот уже несколько месяцев мы активно внедряем их в рабочие процессы — от автоматизации рутинных задач до поддержки клиентов.

Но начнем рассказ с начала. Как-то рано утром я ехал на «Сапсане» из Москвы в Санкт-Петербург и, листая профильные чаты, обратил внимание на сообщения о новых моделях DeepSeek и Qwen. Меня заинтересовали обзоры их возможностей и восторженные отзывы пользователей. Я решил изучить новые нейросети и не заметил, как очнулся четыре часа спустя уже в Питере. До этого момента нейросети казались мне игрушкой, экспериментальной технологией без особой практической ценности, но тогда пришло понимание — мы имеем дело с мощным инструментом, способным перевернуть рабочие процессы. Следом явилось желание немедленно перейти к практике. Собрал команду, обсудили возможности и перспективы, затем подобрали оборудование — на первом этапе для тестирования гипотез использовали личный ноутбук одного из сотрудников. Поставили и запланировали первые задачи.

От идеи к реализации

К моменту знакомства с новыми нейросетями у нас уже был собственный телеграм-бот, который мы активно развивали и использовали. В частности, автоматизировали с его помощью процесс реагирования на инциденты. Ранее при возникновении у клиента аварии процесс реагирования запускался вручную. Дежурный инженер должен был в соответствии с регламентом оповестить о происшествии, после этого сформировать аварийную группу и создать групповые аварийные чаты, куда добавлялись необходимые специалисты и клиентский менеджер. Также необходимо было уведомить руководство и, само собой, активно участвовать в устранении аварии, а именно: фиксировать проблемы, собирать и структурировать информацию.

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

Шаблоны сообщений от бота

• скрипт для управления аварией;

• алгоритм действий, который позволяет минимизировать время на устранение инцидентов.

(Вообще, к метрике «Скорость устранения аварии» мы относимся серьезно, регулярно собираем и анализируем ее в едином дашборде Professional Services. Но это совсем другая история.)

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

Архитектура и техническое решение

Сначала разработали общую архитектуру решения. Для создания бота, способного отвечать на вопросы о наших продуктах, требовались три ключевых компонента:

1. Векторная база данных — хранилище, способное искать информацию не только по ключевым словам, но и по смыслу;

2. LLM-модель, обрабатывающая естественный язык;

3. Интерфейс взаимодействия — способ общения пользователей с системой.

Мы остановились на связке из Elasticsearch для векторного поиска и Ollama для запуска LLM-моделей, а в качестве интерфейса решили использовать нашего телеграм-бота. Такая система сначала ищет релевантные фрагменты документации, затем передает их в нейросеть и возвращает ответ пользователю.

Необходимые инструменты разместили внутри собственной инфраструктуры и в "Публичном облаке" РТК-ЦОД (параметры сервера - CPU 64 cores / RAM 500 GiB / Disk 500 GB | GPU - A100 на 80 GB). Поскольку для реализации проекта мы выбрали open-source-модели, то смогли организовать работу нейросети — в том числе ее обучение и инференс — в изолированном защищенном контуре, без обращения к внешним системам. В результате данные остаются внутри нашей сети, требования к безопасности и конфиденциальности соблюдаются, а мы получили гибкость в управлении и масштабировании решения..

Подготовка качественных данных

Качество работы помощника напрямую зависит от качества обучающих данных, поэтому мы уделили особое внимание структурированию документации. Первым делом разработали шаблон для статей в базе знаний. Например, для материалов о решении проблем мы ввели строгую структуру:

• применимость;

• описание проблемы и ее воспроизведения;

• причина проблемы;

• решение проблемы;

• проверка решения.

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

• отказ от сокращений и жаргона;

• использование системы меток для классификации (продукт, тип статьи, уровень доступа);

• стандартизированные таблицы и блоки кода.

Каждый пакет данных мы загрузили в векторную БД.

Настройка Elasticsearch для векторного поиска

Для эффективного поиска нужных фрагментов документации по смыслу запроса мы развернули Elasticsearch. Обычный текстовый поиск здесь не подходил — нам требовалось найти информацию по косвенным признакам и синонимам.

Мы настроили систему анализаторов текста с поддержкой морфологии русского и английского языков. Hunspell-словари для русского и английского языков подключили вручную, поместив dic- и aff-файлы в директорию hunspell внутри контейнера Elasticsearch. Также реализовали фильтр e_char_filter, нормализующий «ё» в «е».

{

  "settings": {

    "index": {

      "analysis": {

        "tokenizer": {

          "ngram_tokenizer": {

            "type": "ngram",

            "min_gram": 1,

            "max_gram": 2,

            "token_chars": ["letter", "digit"],

            "custom_token_chars": ".,-_"

          }

        },

        "filter": {

          "russian_stemmer": {

            "type": "stemmer",

            "language": "russian"

          },

          "ru_hunspell": {

            "type": "hunspell",

            "language": "ru_RU"

          },

          "en_hunspell": {

            "type": "hunspell",

            "language": "en_US"

          },

          "russian_stop_words": {

            "type": "stop",

            "ignore_case": true,

            "stopwords": ["и", "в", "во", "не", "что", "он", "на", "я", "с", "со", "как", "а", "то", "все", "она", "так", "его", "но", "да", "ты", "к", "у", "же", "вы", "за", "бы", "по", "только"]

          },

          "english_stop_words": {

            "type": "stop",

            "ignore_case": true,

            "stopwords": ["i", "me", "my", "myself", "we", "our", "ours", "ourselves", "you", "your", "yours", "yourself", "yourselves", "he", "him", "his", "himself"]

          },

          "word_delimiter": {

            "type": "word_delimiter",

            "catenate_all": true,

            "preserve_original": true

          }

        },

        "char_filter": {

          "e_char_filter": {

            "type": "mapping",

            "mappings": ["Ё=>Е", "ё=>е"]

          }

        },

        "analyzer": {

          "ru_en_hunspell": {

            "tokenizer": "ngram_tokenizer",

            "filter": [

              "lowercase",

              "ru_hunspell",

              "en_hunspell",

              "russian_stop_words",

              "english_stop_words",

              "word_delimiter"

            ],

            "char_filter": [

              "e_char_filter"

            ]

          }

        }

      }

    }

  }

}

Алгоритм поиска релевантных контекстов

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

Сначала Elasticsearch рассчитывает коэффициенты близости запроса к каждой статье. Затем мы отбираем только те материалы, релевантность которых превышает определенный порог, — используем медиану + половину стандартного отклонения. Это позволяет автоматически адаптировать чувствительность поиска в зависимости от разброса результатов.

# Получаем настройки для данного чата

es_client = Elasticsearch(ES_URL)

es_index = ''

prompt = ''

if 'index' in CHATS[chat_id]:

    es_index = CHATS[chat_id]['index']

if 'prompt' in CHATS[chat_id]:

    prompt = CHATS[chat_id]['prompt']

if es_index != '':

    if not es_client.indices.exists(index=es_index):

        await update.message.reply_text(f'Index "{es_index}" does not exist.')

        return

    # Замена сокращений в запросе пользователя

    like = question

    for k,v in REPLACE.items():

        like = like.replace(k, v)

    # Формирование запроса с использованием more_like_this

    query = {

        'more_like_this': {

            'fields': ['context'],

            'like': like,

            'min_term_freq': 1,

            'min_doc_freq': 1,

            'max_query_terms': 100

        }

    }

    # Выполнение запроса к Elasticsearch

    es_result = es_client.search(index=es_index, query=query)

    hits = es_result['hits']['hits']

    if len(hits) < 1:

        await update.message.reply_text('Нет подходящих контекстов.')

        return

    # Статистический анализ результатов 

    scores = [h['_score'] for h in hits]

    sep = statistics.median(scores) + (statistics.stdev(scores) / 2)

    hits = [h for h in hits if h['_score'] >= sep]

    if len(hits) < 1:

        await update.message.reply_text('Нет подходящих контекстов.')

        return

    # Формирование запроса для языковой модели

    question = prompt + '\nВопрос пользователя: ' + question + '\n\nКонтексты:\n\n'

    titles = []

    tinyuis = []

    for i in range(len(hits)):

        question += '\n' + str(i + 1) + '.\n\n<html>' + hits[i]['_source']['html'] + '</html>\n'

        titles.append(hits[i]['_source']['title'])

        tinyuis.append(hits[i]['_source']['tinyui'])

Настройка промптов и параметров модели

Найденные фрагменты документации — это только половина дела. Вторая половина — правильно подготовить запрос к языковой модели. Мы написали промпт, определяющий, как модель должна отвечать на вопрос:

Ты помощник, который отвечает на вопросы, основываясь исключительно на предоставленных контекстах.
Если ответы можно найти в контекстах, изложи их полно, не изменяя блоки с кодом.
Если информация отсутствует, напиши: «Уточните вопрос, пожалуйста.».
Если обнаружатся похожие контексты, и только в этом случае, напиши «‼ДУБЛИ» и выведи их номера.

Последняя часть, кстати, весьма полезна: включив в промпт задание на поиск дублирующихся материалов, мы получили инструмент для гармонизации базы знаний. Когда модель видит, что две статьи описывают одно и то же, она предупреждает об этом. Так мы постепенно выявляем и объединяем дублирующиеся материалы.

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

Еще поэкспериментировали с параметром «температуры», который отвечает за креативность. При температуре 0 модель всегда выбирает самое вероятное следующее слово, что делает ответы предсказуемыми. При высокой температуре она начинает «фантазировать». Для технической поддержки мы выбрали низкую температуру (0,1) — достаточно предсказуемую, но с небольшим пространством для маневра.

Попутно добавили метод «зачистки вежливости» из вопросов. Когда пользователь пишет «Дорогой бот, пожалуйста, не мог бы ты помочь...», система автоматически вычищает формальности, сохраняя только суть вопроса. Это значительно улучшает точность поиска и экономит контекстное окно, хотя и может в будущем создать нам проблемы в случае восстания машин.

Выбор языковой модели и «легендарный тест»

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

Для этого мы подготовили простую проверку, которую впоследствии стали называть «легендарный тест Ивана». Легендарным он стал из-за простоты и эффективности, а Иван — имя его создателя.

Суть теста: есть три статьи, каждая из которых описывает обновление продукта Basis Dynamix Enterprise (DXE) — до версии 4.0, до 4.1 и до 4.2. И только в одной из них — в обновлении DXE до 4.1 — упоминается необходимость в обновлении MongoDB.

«Тест Ивана» — это вопрос модели: «Нужно ли обновлять Mongo при обновлении DXE с версии 3.8 до версии 4.2». Модель должна по контекстам понять, что обновление поэтапное и что нужно обновлять Mongo на этапе обновления до 4.1. Т. е. правильный ответ «да», но он не очевиден.

Elasticsearch находил все материалы по обновлению Basis Dynamix Enterprise, мы отдавали их модели вместе с вопросом и оценивали ответ. Хорошая модель должна была найти информацию об обновлении MongoDB в документации к версии 4.1 и сделать правильный вывод, хотя в инструкции к 4.2 об этом ничего не сказано.

При выборе модели мы учитывали два ключевых фактора:

1. точность ответов на основе нашей документации;

2. техническая возможность запуска на имеющемся оборудовании.

По второму пункту — нам требовалась модель, которая целиком поместится в видеопамять. Как только модель не помещается в VRAM и начинает использовать процессор, работа с ней становится невозможной из-за падения скорости. Лучше всех под наши запросы подошла QWen/QwQ-32B с 32 миллиардами параметров от Alibaba.

Пример работы бота

Приведу пример проблемы, которую помогает решать бот. Инженер столкнулся с ситуацией: виртуальные машины, запущенные до установки Basis Virtual Security, не видны системе. А если BVS не знает о машине, он блокирует любые операции с ней.

Инженер спросил у бота: «Можно ли попросить пересканировать?» Бот проанализировал вопрос, нашел нужные статьи и выдал подробный ответ с готовым скриптом для решения проблемы и ссылками на документацию. При этом бот показывает не только итоговый ответ, но и процесс размышления — отдельный блок «как думала модель».

# Отправка запроса в языковую модель

ct = time()

response = requests.post(MODEL_URL, headers=headers, json=payload, verify=False)

if response.status_code != 200:

    print('Wrong response code: ' + str(response.status_code))

    await update.message.reply_text('Wrong response code: ' + str(response.status_code))

    return

# Получение ответа и разделение на "размышления" и финальный ответ

response = response.json()['message']['content']

response = response.split('</think>')

think = response[0].replace('<think>', '').strip()

response = '</think>'.join(response[1:])

# Отправка блока "размышлений" модели пользователю

thinks = chunk_string(think, 4070)

for t in thinks:

    await update.message.reply_text('<blockquote>' + t + '</blockquote>', parse_mode='HTML')

# Разбиение ответа на части, если он слишком длинный для одного сообщения

messages = split_markdown(escape_string(response), 4096)

for m in messages:

    await update.message.reply_text(m, parse_mode='Markdown')

# Отправка информации об использованных контекстах и времени генерации

if es_index != '':

    stat = '*Scores and Contexts:*\n'

    for i in range(len(titles)):

        stat += str(round(scores[i], 1)) + ' - [' + titles[i] + '](' + BASE_URL + tinyuis[i] + ')\n'

    stat = stat + f'*Generation time {round(time() - ct, 2)}s*'

    await update.message.reply_text(stat, parse_mode='Markdown')

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

def split_markdown(markdown_text, max_length):

    """

    Функция для разбиения Markdown-текста на части не более max_length символов,

    с сохранением целостности блоков кода и других структур форматирования.

    """

    # Регулярное выражение для выделения блоков кода

    code_block_pattern = re.compile(r'(``.*?``|~~~.*?~~~)', re.DOTALL)

    # Разделяем текст на части: блоки кода и остальной текст

    parts = code_block_pattern.split(markdown_text)

    chunks = []

    current_chunk = ""

    for part in parts:

        # Если это блок кода

        if code_block_pattern.match(part):

            # Если текущий чанк + блок кода превышают max_length,

            # завершаем текущий чанк и начинаем новый

            if len(current_chunk) + len(part) > max_length:

                if current_chunk:

                    chunks.append(current_chunk.strip())

                current_chunk = ""

            current_chunk += part

        else:

            # Разделяем обычный текст на параграфы или строки

            lines = part.split("\n")

            for line in lines:

                # Если текущий чанк + новая строка превышают max_length,

                # завершаем текущий чанк и начинаем новый

                if len(current_chunk) + len(line) + 1 > max_length:

                    if current_chunk:

                        chunks.append(current_chunk.strip())

                    current_chunk = ""

                current_chunk += line + "\n"

    # Добавляем последний чанк, если он не пустой

    if current_chunk.strip():

        chunks.append(current_chunk.strip())

    return [c.strip() for c in chunks if c.strip()]

def escape_string(text):

    """

    Экранирует специальные символы в тексте, не затрагивая блоки кода.

    """

    # Регулярное выражение для поиска блоков с кодом

    code_block_pattern = r'(``.*?`|.*?`)'

    # Функция для обработки частей текста

    def process_part(part):

        # Если часть является блоком с кодом, оставляем её без изменений

        if re.match(r'^(``.*`|.*)

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

Сообщения бота

Что в результате

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

• стало проще работать с документацией;

• выросла скорость обучения новых инженеров;

• время выполнение рутинных операций сократилось на 20–50%;

• скорость решения типовых задач, связанных с написанием кода, увеличилась в 3–6 раз.

За хороший результат мы назвали обновленного нейробота «Цифровой техлид», с прицелом на будущее. Кроме централизации базы знаний по продуктам, мы обучаем его новым навыкам в таких направлениях, как написание кода, автоматизация тестирования, рефакторинг кодовой базы.

Вот, например, один из наших экспериментов: взяли пункт из ПМИ (программа и методика испытаний) — настройка группы безопасности и применение сетевого фильтра. Разработали промпт, нейросеть проанализировала API и сгенерировала код, который потребовал минимальных доработок и был внедрен за 10 минут. У человека одно только изучение API заняло бы значительно больше времени.

Будущее нейробота

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

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

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

• Цифровой бадди — помощник для онбординга. Он проведет нового сотрудника по всему пути адаптации, ответит на вопросы и подскажет, куда обратиться. Аттестует сотрудника и оценит его зрелость в рамках нашей задачи по повышению зрелости команды.

• Карма проектов — тепловая карта проектов, созданная на основе анализа переписки в проектных чатах. Помощник будет следить за активностью в проектных чатах, выявлять признаки проблем и предупреждать менеджеров: «Посмотрите в этот чат, похоже, там что-то назревает».

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

И это только ближайшие планы. Мы уверены, что технологии искусственного интеллекта будут играть ключевую роль в будущем, поэтому будем продолжать расширять возможности ботов, внедрять их в новые направления и улучшать взаимодействие с клиентами.