Uploaded by Boris Vishnyakov

Статья анализ требований v4.1.4

advertisement
УДК 004.934
Б. В. Вишняков, канд. физ.-мат. наук (ФГУП «Государственный научноисследовательский институт авиационных систем» ГНЦ РФ, Москва, Россия),
И. В. Сгибнев, Ю. А. Солоделов, Д. В. Краснощеков, К. А. Николаев, Г. В.
Воронков, С. А. Брянский, А. Д. Власенкова, А. С. Штраух
e-mail: vishnyakov@gosniias.ru
АНАЛИЗ ТЕКСТОВ НА ЕСТЕСТВЕННОМ ЯЗЫКЕ В ЗАДАЧЕ
ОЦЕНКИ ТРЕБОВАНИЙ К ПРОЕКТИРОВАНИЮ
КОНСТРУКЦИИ АВИАЦИОННОГО БОРТОВОГО
ОБОРУДОВАНИЯ
Аннотация. Проанализирована проблема автоматической оценки технических
требований. Одним из аспектов, рассматриваемых в статье, является обоснование
подготовки специфических данных, которые должны использоваться при обучении
архитектуры нейронной сети типа «трансформер». Для этого проведено сравнение
содержания требований к программному обеспечению и конструкторских требований. В
статье приведено обоснование выбора критериев корректности требований и на примерах
продемонстрированы варианты нарушения этих критериев. В данной статье предложен
метод, позволяющий классифицировать требования на их соответствие и несоответствие
правилам. Рассмотрены архитектуры: RuBERT, RuBERT-tiny, RuRoBERTa-large,
RuDeBERTa, RuDeBERTa-distill. Для проведения экспериментов был собран небольшой
набор данных с требованиями к программному обеспечению с корректными и
некорректными примерами для правила завершенности. В качестве оценки точности
алгоритмов
использовалась
F1-мера.
Выявлено,
что
модель
RuBERT-tiny
продемонстрировала оптимальный результат на небольшом наборе данных с точки зрения
минимального времени вывода и значения F1-меры, равного 0.93. Другие рассмотренные
архитектуры также позволили получить высокие значения F1-меры. Это свидетельствует о
возможности использования архитектур нейронных сетей для задач автоматической оценки
и классификации технических требований, что потенциально может улучшить качество
предварительного анализа и сократить временные затраты на проверку их корректности в
процессе разработки программного обеспечения.
Ключевые слова: анализ требований, обработка естественного языка, нейронные сети,
архитектура трансформер, NLP, BERT.
B. V. Vishnyakov, Candidate of Physical and Mathematical Sciences (State
Research Institute of Aviation Systems (GosNIIAS), Moscow), I. V. Sgibnev, Yu.
A. Solodelov, D. V. Krasnoshchekov, K. A. Nikolaev, G. V. Voronkov, S. A.
Brianskiy, A. D. Vlasenkova, A. S. Shtraukh
e-mail: vishnyakov@gosniias.ru
ANALYSIS OF NATURAL LANGUAGE TEXTS IN THE TASK OF
ASSESSING REQUIREMENTS FOR THE DESIGN OF AIRCRAFT
AVIONICS
Abstract. In this paper, we analyze the problem of automatic assessment of technical
requirements. One of the aspects considered is the rationale for the preparation of specific data
that should be used in the training of a “transformer” neural network. For this purpose, we compare
the software requirements with the design requirements. We provide the criteria for the
requirement correctness check, show the cases of violation of these criteria. We propose the
method that allows us to classify requirements according to their compliance and non-compliance
with the rules. We consider such state-of-the-art transformer architectures as RuBERT, RuBERTtiny, RuRoBERTa-large, RuDeBERTa, RuDeBERTa-distill. We use the small dataset of software
requirements containing both correct and incorrect examples for the “completeness” rule to
conduct experiments. We calculate the F1-score to evaluate the algorithms. Our experimental
results show that the RuBERT-tiny model demonstrates optimal performance on this small dataset
in terms of minimum inference time and F1-score of 0,93. We also obtained high values of the F1score for the other models. We conclude that the considered neural network architectures can be
used for the tasks of automatic assessment and classification of technical requirements. The use of
a “transformer” neural network can potentially improve the quality of preliminary analysis and
reduce the time spent on verifying their correctness in the software development process.
Key words: requirements analysis, natural language processing, neural networks, transformer
architecture, NLP, BERT.
Введение
Для успешного создания любой технической и не только системы,
удовлетворяющей ожиданиям заказчика и пользователя, необходимо уделить
тщательное
внимание
формулированию
требований.
Большинство
документов с требованиями пишутся на естественном языке. Такое
представление облегчает их восприятие, но приводит к ошибкам в
формулировках, из-за которых требования могут быть по-разному поняты
разработчиками, тестировщиками и другими заинтересованными сторонами,
участвующими в разработке проекта. Международные стандарты требуют,
чтобы
документы
с
требованиями
были
ясными,
полными,
недвусмысленными, точными, выполнимыми, поддающимися проверке,
тестированию и техническому обслуживанию.
Разработка требований является длительным процессом, который может
существенно ускориться благодаря автоматизированной инструментальной
поддержке.
На
стыке
различных
направлений
науки
(лингвистика,
математика, информатика, искусственный интеллект) возникла компьютерная
лингвистика (КЛ). В ее задачи входит разработка методов и средств
построения лингвистических процессоров для различных прикладных задач
по автоматической обработке текстов на естественном языке.
Обзор существующих работ
Классические методы автоматического анализа текстов на
естественном языке
К
базовым
методам
автоматической
обработки
входного
текста
относятся [1]: токенизация (графематический анализ), морфологический
анализ, поверхностный синтаксический анализ и локальный семантический
анализ.
Разработка и применение лингвистических процессоров опирается на
использование
тех
или
иных
лингвистических
ресурсов:
лексических (словарных) и текстовых. К лексическим ресурсам относятся
словари, тезаурусы, онтологии.
Для создания модулей лингвистических процессоров применяется два
главных подхода: основанный на правилах или инженерный (rule-based) и
основанный на машинном обучении (machine learning). Подход на основе
правил заключается в описании необходимой лингвистической информации в
виде формальных правил. Для записи правил используется либо уже готовый
формальный язык, либо подобный язык специально создается для
разрабатываемого приложения.
Поскольку правила обычно декларативны и легко понимаемы, их просто
поддерживать: модифицировать и расширять. Машинное обучение устраняет
необходимость в ручном составлении правил и сокращает время разработки
систем. В нем источником лингвистической информации выступают не
правила, а отобранные тексты проблемной области. Тем не менее, результаты
моделей машинного обучения сложны для интерпретации, так как они не
поддаются явному лингвистическому объяснению.
При этом с увеличением количества размеченных данных все чаще
прибегают именно к машинному обучению: как более быстрому способу
достижения требуемых результатов. Среди методов, применяемых в рамках
данного подхода, выделяют методы обучения с учителем (supervised),
обучения без учителя (unsupervised, self-supervised) и частичного обучения с
учителем (semi-supervised).
Нейросетевые подходы и большие языковые модели
Отдельным современным подходом к решению задач анализа текстов
являются нейросетевые алгоритмы:
 Неглубокие модели, такие как word2vec [2], используются для
создания векторных представлений слов.
 Рекуррентные нейронные сети (Recurrent Neural Network – RNN)
представляют собой нейронные сети с направленными циклами, где
текущий вывод зависит от предыдущих наблюдений, что позволяет
решать задачи обработки естественного языка (Natural Language
Processing – NLP), такие как распознавание рукописного текста или
речи.
 Сети долгой краткосрочной памяти (Long Short-Term Memory –
LSTM)
представляют
собой
разновидность
архитектур
рекуррентных нейронных сетей, спроектированных для более
точного
моделирования
временных
последовательностей
и
долгосрочных зависимостей.
 Трансформеры, предложенные разработчиками из Google Brain [3] в
2017 году, используют модули внимания и могут обрабатывать
входные
последовательности
параллельно,
что
позволяет
эффективно использовать графические процессоры.
Создание
архитектур
типа
«трансформер»
и
использование
предварительного обучения без учителя на больших объемах текстовой
информации привели к разработке больших языковых моделей (Large
Language Models – LLM) и фундаментальных моделей, способных решать
широкий спектр задач анализа текста и семантической информации на уровне
человека. Среди наиболее значимых моделей данного класса следует отметить
GPT-4 [4] и BERT [5].
Модель GPT-4 представляет собой мультимодальную систему, способную
обрабатывать и текст, и изображения, и производить текстовые выводы. GPT4 демонстрирует результаты, сопоставимые человеческому уровню, в
различных профессиональных и академических тестах. Настройка модели
после обучения с помощью методики RLHF [6] привела к улучшению как
корректности ответов, так и соответствия реакций системы запрашиваемому
поведению.
BERT показала впечатляющие результаты в решении различных задач
обработки естественного языка. От ранее предложенных моделей BERT
отличалась наличием двунаправленного трансформера и предобучением на
маскированных данных. Двунаправленность подразумевает, что внимание
направлено как с начала, так и с конца входной последовательности, то есть
на все токены (последовательностей символов от разделителя до разделителя).
Предварительное обучение BERT происходит на задачи предсказания
следующего предложения и «демаскирования» текста. Слова заменяются на
системный токен случайным образом, а затем предсказываются. Модель
называется маскированной, поскольку токены заменяются по случайно
сгенерированной битовой маске.
Интеллектуальные методы анализа текстов на естественном языке
Существует отдельная область исследований и разработок, называемая
инженерией требований и направленная на применение технологий NLP к
документам с требованиями. Она включает в себя четыре основных этапа:
выявление, анализ, моделирование, а также валидация и верификация.
В
рамках
инженерии
требований
решаются
различные
задачи
лингвистического анализа:
 Детектирование (обнаружение) – выявление лингвистических
проблем в документах с требованиями.
 Классификация
–
распределение
требований
по
различным
категориям в зависимости от цели, для которой применяется задача.
 Извлечение – определение ключевых абстракций и концепций
предметной области.
 Моделирование – определение концепций моделирования и
построение концептуальных моделей.
 Отслеживание и установление связей – анализ связей между
требованиями или между требованиями и другими артефактами,
такими как модели, код, тестовые примеры и правила.
 Поиск и извлечение требований или наборов требований из
существующих репозиториев.
В ряде современных работ [7] успешно решается задача извлечения
формальных спецификаций из описаний на естественном языке. В частности,
рассматриваются три способа представления формальных спецификаций:
регулярные
выражения,
высказывания
логики
первого
порядка
и
высказывания логики линейного времени.
Поскольку большинство моделей при обучении использует данные на
английском языке, для перевода с языка документа на английский
используется языковая модель, например, T5 [8], которая дообучается под
каждую из задач отдельно.
Описание задачи
Задача разработки корректных требований всегда сталкивается с
субъективизмом как технических писателей, так и инженеров-разработчиков.
Поэтому поиск объективного способа оценки созданных требований ведется
давно.
В
настоящей
статье
рассматривается
задача
выявления
(классификации) слабоформализуемых ошибок в написанных на русском
языке требованиях к программному обеспечению (далее – ПО) с
использованием нейронных сетей.
Выбор для данной работы именно требований к ПО (а не требований к
оборудованию или к системам) подчеркивается тем, что у требований к ПО
есть своя специфика, делающая их анализ более сложным по сравнению с
требованиями к другим типам объектов. Чтобы пояснить эту мысль,
рассмотрим различия в конструкторских требованиях и требованиях к
программному обеспечению на следующем примере:
Таблица 1 – Пример требований к конструированию и программированию.
Конструирование
Пульт управления должен позволять
выбирать диапазон дальности в пределах
до 500 км.
Программирование
Функция Range должна обрабатывать
диапазон данных в пределах до 500 км.
Для нейронной сети, обученной на анализ корректности требований к
конструкции, оба требования корректны, но для разработки правильного
программного кода требование из правого столбца не является корректным.
При программировании необходимо конкретизировать типы данных и
объектов разработки. Кроме того, для проектирования пульта управления не
обязательно указывать условия, при которых он должен выполнять свои
функции, а для функции Range требование на условия ее вызова является
обязательным. Все перечисленные (и ряд других) отличия нужно учитывать
при подготовке данных для обучения нейронной сети для классификации
нарушения критериев в требованиях к проектированию кода. Кроме того,
существуют квалификационные требования на разработку критичного по
безопасности ПО. В итоге должны получиться варианты корректных
требований примерно такого вида:
Таблица 2 – Пример корректных требований.
Функция расчета дальности полета Range.
VOID Range (FLOAT Volume, FLOAT Load, FLOAT* Distance);
Предусловия:
 Самолет находится на земле (OnGround=True);
 Проводится предполетная подготовка (PreFlight=True);
 Загрузка завершена (Loaded=True);
 Заправка завершена (FuelTank=True).
Аргументы:
Volume [Вход] – объем заправленного топлива (литр)
Load [Вход] – загрузка (кг)
Distance [Выход] – ожидаемая дальность полета
Возвращаемое значение:
Возвращаемое значение отсутствует.
При вызове функция должна:
 Вызвать функцию расчета дальности полета RangeCalc с параметрами Volume и
Load;
 Если полученное значение больше 500.0 км, то установить значение
Distance=500.0, иначе Distance присваивается возвращаемое значение функции
RangeCalc.
Родительское требование: Нет.
Обоснование производного требования:
Выводимое на дисплей пилота значение дальности полета не должно превышать
разрешенное для данной модели значение.
Отметим, что обычно требования и вспомогательная информация
(аргументы, возвращаемое значение) располагаются в отдельных объектах,
что позволяет многократно использовать, например, описание одних и тех же
терминов, констант или предусловий в разных требованиях. В данной работе
использовался такой же подход (описания и требования располагались
отдельно), но при передаче требований на вход нейронной сети их текст
механически дополнялся содержимым необходимых объектов-описаний.
В литературе выделяют достаточно большое разнообразие свойств
требований, которые могут быть нарушены (см. [9], [10], [11], [12], [13]).
Полный список критериев качества требований, собранных из разных
источников, приведен в таблице 3.
Таблица 3 – Критерии качества требований.
BABOK
[9]
Полное (Complete)
Однозначное
(Unambiguous)
Атомарное (Atomic)
Тестируемое (Testable)
Выполнимое (Feasible)
Непротиворечивое
(Consistent)
Ранжированное
(Prioritized)
Краткое (Concise)
Wiegers
(Karl Wiegers)
[10]
Необходимое
(Necessary)
Invest
(Bill Wake)
[11]
Необходимое (Necessary)
Полное (Complete)
Однозначное
(Unambiguous)
Однозначное
(Unambiguous)
Тестируемое
(Verifiable)
IBM
[12], [13]
Тестируемое
(Testable)
Независимое
(Independent)
Верное (Correct)
Выполнимое
(Feasible)
Приоритизированное Полезное
(Prioritized)
(Valuable)
Компактное
(Small)
Понятное
(Understandable)
Обсуждаемое
(Negotiable)
Атомарное (Atomic)
Тестируемое (Testable,
verifiable)
Независимое
(Independent)
Верное (Correct)
Выполнимое (Feasible,
realistic, possible)
Непротиворечивое
(Consistent)
Четкое (Clear, concise,
terse, simple, precise)
Не избыточное
(Nonredundant)
Понятное
(Understandable)
Нет деталей реализации
(Implementation-free)
Необходимо отметить, что не все критерии корректности требований
могут быть проверены при рассмотрении отдельного требования. Например,
для распознавания критерия непротиворечивости нужно анализировать не
только рассматриваемое требование, но и всю спецификацию в целом.
Поэтому в данной работе рассматриваются только критерии, которые могут
быть проверены при рассмотрении отдельных требований, а рассмотрение
более крупных совокупностей требований запланировано для дальнейшего
развития данных работ.
В итоге выделен набор критериев, для которых были сформированы
обучающие примеры с корректными требованиями и требованиями с
нарушенными правилами разработки:
Таблица 4 – Итоговый набор критериев.
Единичность
Требование описывает одну и только одну
(Неделимость)
вещь. Требование «атомарно». То есть оно
(Атомарность)
не может быть разбито на ряд более
детальных требований без потери
завершенности.
Завершенность
Требование полностью определено в
(Выполнимость)
одном месте, и вся необходимая
(Полнота)
информация присутствует.
Однозначность
Требование кратко определено без
обращения к техническому жаргону,
акронимам и другим скрытым
формулировкам. Оно выражает
объективные факты, не субъективные
мнения. Возможна одна и только одна
интерпретация. Определение не содержит
нечетких фраз. Использование
отрицательных утверждений и составных
утверждений запрещено.
Корректность
Термины в формулировках условий,
(Верное)
значений и действий соответствуют типам
объектов и данных. Набор параметров
соответствует типу требования.
В полном списке критериев упоминается еще один критерий корректности
– «Тестируемое», но он является объединяющим для трех других правил
«Однозначность» + «Завершенность» + «Корректность» и поэтому отдельно
этот критерий не рассматривается.
Предлагаемый метод
Архитектуры классификаторов
Для решения задачи классификации требований применены модели типа
«трансформер». Нейронные сети такого типа эффективно обучаются и
позволяют рассматривать контекст произвольной длины. Такие свойства
достигаются благодаря нелинейному слою самовнимания (Self-Attention).
Оригинальный трансформер был применен в задачах машинного перевода,
однако такие модели применяются и для задач суммаризации, генерации
текста, извлечения именованных сущностей, стилизации текста или
классификации.
Ввиду малочисленности обучающих примеров были использованы
предобученные модели, то есть уже адаптированные к естественному языку.
Этот подход позволяет при дообучении на малом объеме данных учесть
информацию, полученную на обучающей выборке во время предобучения
модели.
В качестве классификатора были рассмотрены следующие модели
(таблица 5).
Таблица 5 – Список рассмотренных моделей
RuBERT [15]
Модель
для
русского
языка,
предобученная
аналогично BERT на задачи демаскирования текста
и
предсказания
следующего
предложения
и
содержащая около 180 миллионов параметров.
Архитектурно
трансформера,
кодирования
она
в
является
котором
использована
для
энкодером
числового
техника
Byte-Pair-
29.4
миллионов
Encoding [16].
RuBERT-tiny [17]
Модель,
имеющая
около
параметров и отличающаяся от RuBERT размером.
RuRoBERTa-large [18] предобучена аналогично RoBERTa-large [19] на
задачу демаскирования текста и содержит около
355 миллионов параметров. От BERT, помимо
задачи предобучения, данная модель отличается
набором
гиперпараметров
и
настройками
обучения.
Русскоязычная модель, аналогичная DeBERTa [20]
RuDeBERTa
и содержащая около 124 миллионов параметров.
Архитектурно она отличается от модели BERT
модифицированным слоем самовнимания.
 RuDeBERTa-distill
 Аналогична DeBERTa-distill [21] и содержит около
81.5 миллионов параметров. От DeBERTa она
отличается тем, что в процессе предобучения
использована техника дистилляции.
Стоит отметить, что каждая из приведенных моделей не обучена на
практическую задачу. Смысл предобучения состоит исключительно в том,
чтобы сформировать универсальное состояние весов, которое далее
используется лишь как точка инициализации для дообучения модели.
Универсальность достигается за счет существенного объема обучающих
данных
и
нетривиальности
задачи.
Причем,
как
правило,
задача
формулируется так, чтобы данные не требовали прямой разметки:
продолжения текста, восстановления пропусков. Такой подход именуется как
обучение без учителя.
Рисунок 1 – Предлагаемый метод.
Предлагаемый метод применительно к задаче классификации требований
к проектированию конструкции авиационного бортового оборудования
проиллюстрирован на рисунке 1. Вначале происходит преобразование текста
с требованием S в токены 𝑇𝑜𝑘𝑖 , 𝑖 = 1. . 𝑁, где 𝑁 – число токенов. Перед всеми
токенами предложения помещается особый токен классификации 𝐶𝐿𝑆. Затем
для каждого токена получают эмбеддинг 𝐸(𝑇𝑜𝑘𝑖 ). Эмбеддингом называется
векторное представление токена. Затем эмбеддинг проходит через модель
обработки текста (одну из предложенных в таблице 5). На выходе для каждого
поданного на вход эмбеддинга 𝐸(𝑇𝑜𝑘𝑖 ) будут сформированы выходные
вектора 𝑇𝑖 . При решении задачи классификации текста используется только
вектор, полученный для токена 𝑇0 размерности 𝐻 (определяемой архитектурой
нейронной сети), этот вектор подается на вход линейному слою при помощи
которого получаются так называемые «логиты» 𝐿 = 𝑇0 × 𝑊 𝑇 размерности 𝐾,
где 𝐾 – число критериев к требованиям, определенных в таблице 4, 𝑊 –
матрица обучаемых параметров размерности 𝐾 × 𝐻. Затем логиты при
помощи функции 𝑠𝑜𝑓𝑡𝑚𝑎𝑥 [22] преобразовываются в распределение
вероятностей принадлежности к каждому классу.
Обучение модели
Поскольку рассмотренные языковые нейросетевые модели изначально не
предназначены для решения задачи классификации, перед дообучением
исходная архитектура нейронной сети (каждая из предложенных в таблице 5)
была адаптирована. Эта адаптация может быть описана как логистическая
регрессия на признаках, извлекаемых предобученной нейронной сетью:
𝑇0 = 𝑃𝑟𝑒𝑡𝑟𝑎𝑖𝑛𝑒𝑑𝑀𝑜𝑑𝑒𝑙(𝑆)[0],
𝐿 = 𝑇0 × 𝑊 𝑇 ,
𝑇
𝑒 𝐿1
𝑒 𝐿2
𝑒 𝐿𝐾
𝑝 = ( 𝐾 𝐿 , 𝐾 𝐿 ,…, 𝐾 𝐿 ) ,
∑𝑖=1 𝑒 𝑖 ∑𝑖=1 𝑒 𝑖
∑𝑖=1 𝑒 𝑖
𝑙𝑜𝑠𝑠 = − ∑𝐾
𝑖=1 𝑦𝑖 𝑙𝑜𝑔(𝑝𝑖 ) ,
где 𝑆 – входная последовательность символов, 𝑃𝑟𝑒𝑡𝑟𝑎𝑖𝑛𝑒𝑑𝑀𝑜𝑑𝑒𝑙(𝑆)[0]
– нулевой выход обученной модели на последовательности 𝑆, 𝑇0 – нулевой
вектор представления 𝑇𝑖 входной последовательности 𝑆,
𝑝 – вектор
предсказанного распределения вероятностей принадлежности к каждому
классу для входной последовательности 𝑆, 𝑦 – вектор истинного
распределения классов для 𝑆, 𝑙𝑜𝑠𝑠 – значение функции потерь. Приведенная
функция потерь может быть оптимизирована посредством градиентного
спуска.
Результаты экспериментов
Набор данных
Набор данных для проведения экспериментов представляет собой
список требований к проектированию конструкции авиационного бортового
оборудования, для каждого из которых указан тип нарушенного правила из
четырех (неделимость, однозначность, завершенность, корректность) и
приведен соответствующий исправленный пример.
Модели обучались определять, соответствует ли требование, которое
подается на вход, заданному критерию. Поскольку для качественного
обучения моделей требуется достаточное количество данных, из общего числа
примеров были отобраны некорректные и корректные требования по
критерию завершенности, как содержащие не менее 10 текстов требований.
Итоговый набор данных состоял из 72 записей: 36 записей, содержащих
ошибку, и 36 – без ошибки. Пример некорректных и корректных требований
по критерию завершенности представлен в таблице 6.
Набор данных был разделен на обучающий (80 %) и проверочный
(20 %). Таким образом, для проверочной выборки случайным образом были
выбраны 15 записей.
Таблица 6 – Пример некорректных и корректных требований по критерию
завершенности.
Некорректное требование
Система адресной связи ACARS должна
содержать модем.
Кабина пилотов должна быть оборудована
многофункциональным пультом
управления.
Система должна согласовывать
отклонения элеронов и интерцепторов.
Корректное требование
Система адресной связи ACARS должна
содержать модем, способный
осуществлять преобразование цифровых
данных в аналоговую форму и обратно.
Кабина пилотов должна быть оборудована
многофункциональным пультом
управления, способным принимать
сообщения, набирать сообщения экипажем
и отправлять их.
Система должна согласовывать
отклонения элеронов и интерцепторов
между собой, чтобы не допустить
сваливание.
Оценка точности
В качестве оценки точности алгоритма используется F1-мера (F1measure), рассчитываемая по формуле:
𝐹1 = 2
𝑅𝑒𝑐𝑎𝑙𝑙 ∙ 𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛
.
𝑅𝑒𝑐𝑎𝑙𝑙 + 𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛
Точность (precision) – доля правильно предсказанных нарушений
правила среди всех требований, где модель предсказала нарушения,
рассчитываемая как:
𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 =
𝑇𝑃
.
𝑇𝑃 + 𝐹𝑃
Полнота (recall) – доля правильно предсказанных нарушений правила
среди всех требований, где требования были действительно нарушены:
𝑅𝑒𝑐𝑎𝑙𝑙 =
𝑇𝑃
.
𝑇𝑃 + 𝐹𝑁
В данных формулах:
 𝑇𝑃 (true positive) – модель верно определила, что в требовании
нарушено правило;
 𝑇𝑁 (true negative) – модель верно определила, что требование не
содержит нарушений правила;
 𝐹𝑃 (false positive) – модель неверно определила, что требование
содержит нарушение правила;
 𝐹𝑁 (false negative) – модель неверно определила, что требование не
содержит нарушений правила.
Обучение и тестирование
Все предложенные модели обучались на одной видеокарте NVIDIA
GeForce RTX 3060 12 GB. Для обучения в качестве метода оптимизации
использовался стохастический градиентный метод AdamW [23]. Установлены
следующие параметры: размер партии – 16, шаг обучения – 0,0003 с политикой
возрастания в течение первых 16 эпох и уменьшения все оставшееся время
обучения. Модели и этапы обучения реализованы на фреймворке глубокого
обучения PyTorch [24].
В таблице 7 приведены результаты работы различных моделей на наборе
данных с требованиями на видеокарте NVIDIA GeForce RTX 3060 12 GB.
Таблица 7 – Результаты экспериментов на наборе данных с требованиями.
F1-мера
Время
выполнения
алгоритма, мс
RuBERT
0,86
106
RuBERT-tiny
0,93
99
RuRoBERTalarge
0,93
169
RuDeBERTa
0,93
106
RuDeBERTadistill
0,86
101
Модель
Все модели из рассмотренных позволили получить высокие значения
F1-меры. Модель RuBERT-tiny продемонстрировала оптимальный результат с
точки зрения времени вывода и точности. При данном объеме данных
взаимосвязь между количеством параметров модели и полученными
значениями метрик не обнаружена.
Поскольку работа моделей оценивалась на небольшом наборе данных,
результаты
экспериментов
являются
предварительными.
Интерес
представляет исследование применимости языковых моделей для решения
задачи оценки требований на большем объеме данных.
Заключение
В данной статье был предложен метод анализа текстов на естественном
языке применительно к задаче оценки требований в области проектирования
конструкции
авиационного
бортового
оборудования.
Качественно
сформулированные требования важны для успеха как технического проекта,
так и любого другого. Однако процесс их формирования требует
значительных временных затрат и усилий. С помощью автоматизированной
оценки требований можно значительно ускорить процесс их формирования.
Были рассмотрены архитектуры нейронных сетей типа «трансформер» и
проведены эксперименты с пятью BERT-подобными моделями, которые
обучались классифицировать тексты требований на нарушение в них правила
завершенности.
Результаты экспериментов показывают, что предложенные нейронные
сети хорошо справляются с задачей классификации технических требований.
Зависимость между размером моделей и полученными результатами на
небольшом наборе данных обнаружена не была. Учитывая высокие итоговые
значения F1-меры, можно сделать вывод, что успешно обучаться возможно
даже на небольшом наборе данных.
Библиографический список
1.
Семантический
анализ
для
автоматической
обработки
естественного языка // https://rdc.grfc.ru/2021/09/semantic_analysis.
2.
Mikolov Tomas et al. Efficient Estimation of Word Representations in
Vector Space // arXiv:1301.3781.
3.
Vaswani, Ashish et al. Attention Is All You Need // arXiv:1706.03762.
4.
OpenAI GPT-4 technical report //arXiv preprint arXiv: 2303.08774. –
5.
Devlin, Jacob et al. BERT: Pre-training of Deep Bidirectional
2023.
Transformers for Language Understanding, 2018.
6.
Ouyang L. et al. Training language models to follow instructions with
human feedback //Advances in Neural Information Processing Systems. – 2022. –
Т. 35. – С. 27730-27744.
7.
Hahn C. et al. Formal specifications from natural language //arXiv
preprint arXiv:2206.01962. – 2022.
8.
Raffel, Colin, Shazeer, Noam, Roberts, Adam, Lee, Katherine, Narang,
Sharan, Matena, Michael, Zhou, Yanqi, Li, Wei, Liu, Peter J., 2020. Exploring the
limits of transfer learning with a unified text-to-text transformer. arXiv:1910.10683,
[cs.LG].
9.
A Guide to the Business Analysis Body of Knowledge®,
https://www.iiba.org/career-resources/a-business-analysis-professionalsfoundation-for-success/babok/
10.
Karl E. Wiegers, Writing Quality Requirements, published in Software
Development, May 1999
11.
Bill Wake, INVEST in Good Stories, and SMART Tasks, Posted on
August 17, 2003
12.
Requirements Management Using IBM Rational RequisitePro,
https://www.informit.com/articles/article.aspx?p=1152528&seqNum=4
13.
IBM Corporation, IBM Rational DOORS: Get It right the first time,
1993, 2010.
14.
Ilya Loshchilov, Frank Hutter Efficient Estimation of Word
Representations in Vector Space // arXiv:1711.05101.
15.
Yuri Kuratov, Mikhail Arkhipov Adaptation of Deep Bidirectional
Multilingual Transformers for Russian Language // arXiv:1905.07213.
16.
Rico Sennrich, Barry Haddow, and Alexandra Birch. 2016. Neural
machine translation of rare words with subword units. In Proceedings of the 54th
Annual Meeting of the Association for Computational Linguistics (Volume 1: Long
Papers), pages 1715– 1725, Berlin, Germany. Association for Computational
Linguistics.
17.
Alina Kolesnikova, Yuri Kuratov, Vasily Konovalov, Mikhail Burtsev
Knowledge Distillation of Russian Language Models with Reduction of Vocabulary
// arXiv:2205.02340.
18.
Dmitry Zmitrovich et al. A Family of Pretrained Transformer
Language Models for Russian // arXiv:2309.10931.
19.
Yinhan Liu et al. RoBERTa: A Robustly Optimized BERT Pretraining
Approach // arXiv:1907.11692.
20.
Pengcheng He et al. DeBERTa: Decoding-enhanced BERT with
Disentangled Attention // arXiv:2006.03654.
21.
https://huggingface.co/deepvk/deberta-v1-distill#deberta-distill
22.
Bolin Gao, Lacra Pavel On the Properties of the Softmax Function with
Application in Game Theory and Reinforcement Learning // arXiv:1704.00805.
23.
AdamW: Decoupled weight decay regularization Ilya Loshchilov,
Frank Hutter 2019 / URL: https://arxiv.org/abs/1711.0510.
24.
PyTorch. Key Features & Capabilities. URL: https://pytorch.org/.
Download