Трансформация рабочих процессов с помощью нейросетей

Ранее в блоге компании АСКОН я уже делился подборкой инструментов ^[1], которые использую в своей повседневной работе. Сегодня хочу продолжить эту тему и рассказать, как нейросети поменяли мой рабочий процесс, какие задачи они помогают решать, и почему вам не обязательно быть ML-инженером, чтобы эффективно использовать ИИ на практике. А кроме того расскажу, как с помощью нейросетей добавляют полезный функционал в инженерное программное обеспечение.

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

Виды моделей и инструменты, которые я использую

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

1. ASR (Распознавание речи). Для конвертации речи в текст я использую Whisper Desktop ^[2] – это удобный оффлайн-интерфейс к мощной модели Whisper от OpenAI. На практике он показал себя отлично: работает быстро даже на среднем “железе”, поддерживает множество языков и дает очень достойную точность распознавания, что критично для дальнейшей обработки.

2. “Классические” NLP. Когда понимание смысла текста необязательно, а достаточно точного извлечения структурированных данных по заданным правилам (сущности, грамматический разбор, шаблоны), я использую инструменты, которые часто называют “NLP-моделями” (хотя строго говоря, LLM – тоже часть NLP). В основном я использую библиотеку spaCy ^[3]. Но стоит отметить, что в этой области также представлены и российские продукты, такие как DeepPavlov ^[4] и Natasha ^[5]. Их развитие активно поддерживается местными компаниями и open-source сообществом. По сравнению с большими языковыми моделями (LLM), классические методы NLP работают невероятно быстро и предсказуемо. Для многих рутинных задач анализа большого объема текста (парсинг, извлечение данных по шаблону) их точности более чем достаточно. Еще одна библиотека, не совсем NLP, но о ней стоит также упомянуть, поскольку может помочь в составлении текстов – это pymorphy ^[6] – морфологический анализатор, который поможет выявить и изменить род, число и падеж слова. Этого набора в большинстве случаев достаточно для решения задач обработки текста.

3. LLM (Большие языковые модели). Когда нужна работа со смыслом – анализ больших объемов текста, генерация кода или связного контента, понимание глубокого контекста, то тут в дело вступают LLM-модели. Для локальных экспериментов и работы с open-source моделями (Llama, Mistral и др.) я использую LM Studio ^[7]. Его большой плюс – удобный интерфейс и поддержка REST API, аналогичного OpenAI, что позволяет легко интегрировать локальные LLM в другие приложения.

4. RAG (Retrieval-Augmented Generation). Сегодняшние LLM-модели достаточно мощны, но их знания ограничены тренировочными данными. RAG – улучшение LLM, которое позволяет «скармливать» модели данные, чтобы “научить” модель опираться на вашу специфическую информацию (документы, базы знаний). Для построения локальной RAG-системы я иногда использую Anything LLM ^[8]. Он позволяет легко создавать векторные базы из моих данных и гибко подключать к ним как локальные LLM (через тот же LM Studio), так и облачные (OpenAI и др.).

5. Мультиагентные системы. Такие системы позволяют нескольким LLM-“агентам” взаимодействовать друг с другом, а кроме того взаимодействовать и с внешними инструментами (базами данных, API, поиском, специфичным софтом). Это уже уровень автоматизации комплексных процессов. Для оркестрации таких взаимодействий я использую n8n ^[9], который развертываю локально. Мне нравится, что можно визуально построить цепочку действий (workflow) и подключать инструменты или даже MCP (Multi-Call Plugin) – сервера. Таким образом LLM-модель может самостоятельно решать, какие внешние функции (найти что-то в интернете, запросить данные из БД, выполнить расчет) использовать для решения той или иной задачи.

Полезные ресурсы: куда смотреть и где учиться

Помимо конкретных инструментов, хочу поделиться ресурсом, который стал для меня своеобразной отправной точкой в мире ИИ, и я его использовать как для обучения ^[10], так и для экспериментов. Речь о Hugging Face ^[11], где расположено множество секций:

1. Models ^[12]: Огромный модельный зоопарк, здесь сообщество выкладывает тысячи разных моделей: для генерации изображений (Stable Diffusion и аналоги), создания 3D-объектов, распознавания объектов на фото/видео, синтеза речи, анализа аудио и многого другого. Это позволяет быстро найти вариант решения практически под любую задачу, связанную с данными.

2. Spaces ^[13]: Предоставляет возможность поиграть с уже готовыми, развернутыми на мощностях Hugging Face (или сообщества) демонстрационными приложениями на базе различных моделей. Хотите понять, как работает новая модель для анимирования картинок или перевода технической документации – заходите в Spaces, находите релевантный пример, загружаете свои данные и тестируйте.

3. Learn ^[14]: Бесплатные и качественные материалы для обучения. Здесь собраны отличные бесплатные курсы (в основном на английском) по ключевым направлениям: NLP, архитектуре трансформеров, тонкой настройке моделей и другим аспектам ML/DL. Форматы материалов разнообразны: видео, тексты, интерактивные блокноты. Если видео на английском смотреть сложно и непонятно, то можно использовать браузер с функцией перевода видео. Качество машинного перевода сейчас очень достойное, я, например использовал, Яндекс.Браузер для изучения темы про трансформеров.

Дополнительно хочу порекомендовать книги, которые мне понравились, и на мой взгляд они помогут разобраться в том, “что твориться под капотом”.

1. «Машинное обучение для абсолютных новичков». Автор – Оливер Теобальд. Ориентирована на начинающих, не требует опыта ^[15] в программировании и содержит простые объяснения с практическими примерами.

2. «Грокамем машинное обучение». Автор Луис Серрано. Книга содержит доступное объяснение принципов работы машинного обучения и нейросетей.

Трансформация моих рабочих процессов

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

Сейчас же я просто надиктовываю текст — пусть даже с оговорками, запинками, словами-паразитами вроде «ээ», «ну», «я не знаю». Текст надиктовываю подробно, иногда даже избыточно подробно — и ASR-модель хорошо распознает речь, а LLM-модель извлекает суть и выдает уже структурированный результат. Для меня такой вариант работы с материалом оказался гораздо продуктивней и удобнее.

Второе изменение касается подхода к прототипированию. Если раньше я использовал Lazarus IDE для быстрого создания прототипа приложения, отработки визуальных интерфейсов и проверки взаимодействия компонентов, то теперь чаще работаю с Python и JavaScript. C LLM-моделями — генерация кода на Python, написание скриптов, HTML-страниц, правка CSS — стала гораздо проще и быстрее благодаря тому, как хорошо языковые модели справляются с подобными задачами. Для работы я использую VS Code вместе с модулем Cline, через который подключаюсь к локально развёрнутой языковой модели в LM Studio.

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

Кейс: Проверка гипотезы — привязка требований к тексту из DOCX

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

Как проводилась работа с помощью запроса к LLM

Для LLM был составлен первый промпт для поиска направления решения задачи:

Процесс захвата требований выглядит следующим образом. 
Есть источник в виде текстового документа в формате **docx**. 
Из этого источника путем анализа и парсинга должны быть зафиксированы 
разделы спецификации и требования для которых фиксируется наименование 
и описание (если оно есть). Наименование это текст со стилем заголовок, 
описание - это участок текста между заголовками, 
который может содержать текст, картинки, таблицы. 
Задача состоит в том, чтобы при импорте этой информации в 
систему сформировалась связь с источником и в атрибуте этой 
связи хранить информацию о том, из какого места в текстовом 
документе блок с информацией был сформирован. 
Помимо этого, хотелось бы при открытии документа источника 
видеть какие участки этого текстового документа попали в 
систему в виде разделов или требований, а какие участки 
были проигнорированы и не были захвачены в систему. 
Предложи решение, которое позволит хранить информацию о том, 
какие участки текстового документа были захвачены. 
Помимо этого предложи вариант отображения информации в текстовом 
документе открываемом в текстовом редакторе Microsoft Word 
или LibreOffice с возможностью визуально увидеть какие участки 
текста были сформированы в виде требований в системе, а какие 
участки текста не были задействованы.

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

{
    "type": "header",
    "name": "Подраздел 1",
    "hash_name": "5295a7ec",
    "xpath": {
        "name_start": "/doc/body/section[1]/p[2]",
        "name_end": "/doc/body/section[1]/p[2]",
        "description_start": "",
        "description_end": ""
    },
    "hash_description": "",
    "children": [
        {
            "type": "reqm",
            "name": "Требование 1.1",
            "hash_name": "b7c7503d",
            "xpath": {
                "name_start": "/doc/body/section[1]/p[3]",
                "name_end": "/doc/body/section[1]/p[3]",
                "description_start": "/doc/body/section[1]/p[4]",
                "description_end": "/doc/body/section[1]/p[6]"
            },
            "description": "Какой-то текст....",
            "hash_description": "71180f902d"
        },
        {
            "type": "reqm",
            "name": "Требование 1.2",
            "hash_name": "b98de458",
            "xpath": {
                "name_start": "/doc/body/section[1]/p[8]",
                "name_end": "/doc/body/section[1]/p[8]",
                "description_start": "/doc/body/section[1]/p[9]",
                "description_end": "/doc/body/section[1]/p[9]"
            },
            "description": "Какой-то текст",
            "hash_description": "87b43dee"
        }
    ]
}

После чего в контексте чата был задан запрос на формирование скриптов Python:

Сформируй два скрипта Pyhton:
1. **Скрипт №1** — Парсер DOCX. Скрипт должен извлекаь текст из документа,
идентифицировать требования и сразу складывает их в структуру JSON.
Каждый элемент включает сам текст, идентификатор и позицию в исходнике.

4. **Скрипт №2** — Подсветка данных в DOCX.
На вход скрипта подается путь до json фала с информацией,
скрипт получает путь до оригинального файла и проходится
по исходному документу, на основе данных в json файле скрипт
выделяет цветом те фрагменты, откуда были "взяты" требования.
Он также визуально выделяет:
   * не изменённые участки;
   * изменённые (по хешу);
   * проигнорированные части текста.

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

В результате такой работы с LLM, была получена JSON-структура и два скрипта, которые позволили проверить гипотезу о возможности такой работы и дали основу для более детальной проработки.

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

Кейс: Быстрая генерация интерфейса

Современные инструменты проектирования интерфейсов всё чаще поддерживают интеграцию с нейросетями через MCP‑серверы: например, Figma предлагает Dev Mode MCP Server ^[16], позволяющий подключать LLM‑модели (такие как Cursor, Claude или Copilot) для генерации UI‑компонентов прямо по словесному описанию, а Pixso предоставляет Plugin API ^[17], через который можно автоматизировать стили, данные и взаимодействие с макетами. Если хочется набросать прототип, то всегда можно запросить у нейросети одностраничный макет с нужной стилистикой — это быстрый, хоть и менее гибкий способ генерации интерфейса.

В рамках моей работы передо мной стояла задача — быстро переработать интерфейс окна для выгрузки данных о требованиях в текстовый документ. Мне захотелось немного поэкспериментировать и создать, как мне казалось, максимально информативный и удобный интерфейс.

Я надиктовал описание задачи и внешний вид интерфейса: какие поля должны присутствовать, как должны отображаться элементы, какие функции должен выполнять интерфейс. После нескольких итераций получился, на мой взгляд, удачный вариант. Результатом стал одностраничный HTML-документ, включающий в себя JavaScript и CSS — таким образом, логика ^[18], оформление и структура находились в одном месте. Дополнительно я просил модель добавлять комментарии в код, чтобы упростить последующую доработку.

Конечно, с первого раза не всё получилось идеально. Иногда приходилось просить нейросеть сдвинуть элемент влево или вправо, изменить цвет кнопки и т.д. Благодаря тому, что в HTML-коде присутствуют поясняющие комментарии (например, к какой функции относится конкретная кнопка), модель легко интерпретировала структуру и корректно вносила правки.

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

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

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

Использование моделей для реализации функционала в продуктах

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

Кейс: Выявление числовых характеристик требования

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

Для реализации данной функциональности применялась NLP-библиотека spaCy, в рамках которой использовались следующие возможности:

• синтаксический разбор предложений (выделение подлежащего, сказуемого, дополнений, обстоятельств и корневой структуры);

• распознавание именованных сущностей (NER);

• определение пользовательских сущностей и фрагментов текста с помощью правил (Rule-Based Matching) на основе заранее заданных паттернов.

Пример формирования правила для фрагментов текста

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

Пример паттерна:

{
  "label": "CharDef_ValueGapPMDeviation",
  "pattern": [
    {"ENT_TYPE": {"IN": ["Number", "TextNumber"]}},
    {"ENT_TYPE": "MUnit", "OP": "*"},
    {"ENT_TYPE": "PMNumber"},
    {"ENT_TYPE": "MUnit", "OP": "+"}
  ],
  "id": "Номинал с отклонениями",
  "note": "Здесь считаем, что основное значение (Value)"+
          "отделено от допуска (±...), но допуск сразу "+
          "сопровождается своей единицей измерения"
}

Расшифровка паттерна:

1. Числовое значение (ENT_TYPE: "Number" или "TextNumber"): может быть как цифрой ("100"), так и словом ("сто").

2. Единица измерения (ENT_TYPE: "MUnit", OP: "*") — необязательная: например, “км”, “суток”.

3. Допуск с числом (ENT_TYPE: "PMNumber"): включает знак “±”, “плюс-минус” и само числовое значение.

4. Единица измерения допуска (ENT_TYPE: "MUnit", OP: "+") — может присутствовать, если отличается от основной или явно указана.

Практическое применение:
Такой паттерн позволяет автоматически извлекать числовые значения с допусками из технических текстов и спецификаций, например:

• “100 километров ±5 км”

• “5 суток плюс-минус 1 день”

Как это работает для пользователя:

1. Пользователь вводит или загружает текст с описанием требования в блочном редакторе и запускает функцию распознавания.

2. Запускается процесс анализа с помощью предобученных моделей spaCy и набора пользовательских паттернов.

3. Система автоматически выявляет ключевые сущности и их атрибуты — например, числовые значения, типы единиц измерения и допустимые отклонения.

4. На основе извлечённых данных формируются объекты типа «Характеристика». Единицы измерения автоматически подтягиваются из справочника продукта АСКОН – ПОЛИНОМ:MDM (например, «км» преобразуется в «километры» с привязкой к официальным стандартам и нормативам).

Пример окна прототипа:

Итог: интеграция NLP-библиотек, таких как spaCy, с кастомными паттернами даёт конечным пользователям мощный инструмент для автоматического структурирования неформализованных текстов. Это не только ускоряет обработку данных и сокращает количество ручных операций, но и минимизирует ошибки ^[20], повышая качество работы с информацией. Для разработчиков, заинтересованных в подобных решениях, spaCy предлагает удобные онлайн-демонстрации своих возможностей.

Кейс: Классификация требований

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

функции была реализована простая цепочка обработки запроса:

1. Заготовлен Системный промпт с плейсхолдерами.
   В системном промпте мы задаём модели роль — например, «Ты — системный аналитик» — и оставляем в тексте шаблона места для подстановки атрибута и списка его возможных значений:

   {  "role": "system",  
    "content": "Ты — системный аналитик. Проанализируй описание требования и выбери наиболее подходящий тип:  — ."
   }

2. Подгрузка релевантного контекста.
   В простом случае можно использовать три-пять общих примеров. Они всегда будут одинаковыми. В более продвинутом варианте можно использовать векторную базу, из которой мы будем извлекать несколько (5–6) примеров реальных диалогов и прошлые ответы для похожих требований. Это помогает модели «войти в ситуацию» и воспроизвести нужный стиль и логику анализа.

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

4. Классификация.
   На выходе модель выдаёт итоговый JSON‑объект с категориями требования:

   {  
     "requirement": "Новая функция поиска",  
     "type": "Функциональное",  
     "priority": "Средняя"
   }

Пример окна прототипа:

Какие LLM подходят для такой задачи

Для получения качественного ответа могут подойти открытые модели:

• Русскоязычные модели (семейство Saiga): Перетренированы на большом массиве русских текстов, хорошо понимают нюансы русского языка.

• Дистиллированные легкие варианты (Deepseek, Qwen или Gemma): Компактные и быстрые, но с чуть меньшей точностью.

• Крупные модели (Deepseek, Qwen с 27 и более миллиардом параметров): Наиболее точные, особенно при наличии достаточного контекста и «истории» общения, но требуют больше вычислительных ресурсов.

Чем больше параметров у модели и чем богаче контекст, тем ниже процент ошибок при классификации. При базовой реализации достаточно 5–6 примеров из истории, но векторная БД с десятками релевантных случаев даёт ещё более надёжные результаты.

Буквально на днях, вышла любопытная статья, посвящённая сравнению популярных локальных LLM-моделей: «Локальные LLM: обзор и тестирование» ^[21]. В ней автор анализирует некоторые популярные модели, доступные для запуска на собственном железе, оценивая их по различным критериям. Но не менее ценными, чем сама статья, для вас могут оказаться и комментарии к ней.

Заключение

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