Я разрабатываю инструмент ИИ, чтобы найти ошибки известного оборудования и найти новые схемы отказа. Этот файл журнала основан на времени и содержит известные сообщения (информация и ошибка). Я использую библиотеку JavaScript. Событие сбрасывается, чтобы мягко показывать данные, но моя настоящая работа и сомнения заключаются в том, чтобы научить ИИ находить известные шаблоны и найти новые возможные шаблоны. У меня есть некоторые требования:
1 - Инструмент должен либо: не зависит от установки дополнительной среды или б. чем меньше, тем лучше (идеальный сценарий - запустить инструмент полностью в браузере в автономном режиме);
2 - Возможность сделать анализатор фрагментов фрагментированным, своего рода модульность, один модуль на ошибку;
Каков рекомендуемый тип алгоритма для этого (нейронная сеть, генетический алгоритм и т. Д.)? Есть что-то, чтобы работать с помощью JavaScript? Если нет, то какой язык лучше всего использовать для этого ИИ?
источник
Ответы:
Корреляция между записями
Первая рекомендация состоит в том, чтобы гарантировать, что соответствующие предупреждения и информационные записи в файле журнала представлены вместе с ошибками в компонентах машинного обучения решения. Все записи журнала являются потенциально полезными входными данными, если возможно наличие корреляции между информационными сообщениями, предупреждениями и ошибками. Иногда корреляция является сильной и поэтому имеет решающее значение для максимизации скорости обучения.
Системные администраторы часто воспринимают это как серию предупреждений, за которыми следует ошибка, вызванная условием, указанным в предупреждениях. Информация в предупреждениях больше указывает на основную причину сбоя, чем на запись об ошибке, созданную при критическом сбое системы или подсистемы.
Если кто-то строит панель мониторинга работоспособности системы для части оборудования или множества машин, которые взаимодействуют, что, как представляется, имеет место в этом вопросе, основная причина проблем и некоторые возможности раннего предупреждения - это ключевая информация для отображения.
Кроме того, не все плохие состояния системы приводят к сбоям.
Единственные записи в журнале, которые должны быть исключены путем фильтрации до представления в механизм обучения, - это записи, которые, безусловно, не имеют отношения к делу и не коррелируют. Это может быть тот случай, когда файл журнала представляет собой совокупность журналов из нескольких систем. В таком случае записи для анализируемой независимой системы должны быть извлечены как изолят от записей, которые не могут соотноситься с анализируемыми явлениями.
Важно отметить, что ограничение анализа одной записью за раз значительно ограничивает полезность панели инструментов. Состояние системы не равно показателям состояния самой последней записи в журнале. Это даже не линейная сумма показателей здоровья последних N записей.
Состояние системы имеет очень нелинейные и очень зависимые от времени отношения со многими записями. Паттерны могут появляться постепенно в течение многих дней во многих типах систем. Базовая (или базовая) нейронная сеть в системе должна быть обучена определять эти нелинейные признаки здоровья, надвигающихся опасностей и условий риска, если требуется очень полезная панель инструментов. Чтобы отобразить вероятность надвигающегося сбоя или проблемы контроля качества, в эту нейронную сеть должно войти все временное окно записей журнала значительной длины.
Различие между известным и неизвестным паттернами
Обратите внимание, что идентификация известных шаблонов отличается в одном важном отношении от идентификации новых шаблонов. Особенности синтаксиса записей известных ошибок уже выявлены, что значительно снижает нагрузку на обучение на этапах нормализации ввода для этих записей. Синтаксические идиосинкразии новых типов ошибок должны быть обнаружены в первую очередь.
Записи известного типа также могут быть отделены от неизвестных, что позволяет использовать известные типы записей в качестве обучающих данных, чтобы помочь в изучении новых синтаксических паттернов. Цель состоит в том, чтобы представить синтаксически нормализованную информацию для семантического анализа.
Первый этап нормализации, характерный для файлов журнала
Если отметка времени всегда находится в одном и том же месте в записях, ее можно преобразовать в относительные миллисекунды и, возможно, удалить любые символы 0x0d перед символами 0x0a, прежде чем что-либо еще сделать первым шагом в нормализации. Трассировки стека также можно свернуть в массивы уровней трассировки с разделителями табуляции, чтобы между записями журнала и строками журнала было однозначное соответствие.
Синтаксически нормализованная информация, возникающая как из известных, так и неизвестных записей ошибок и записей, не относящихся к типу ошибок, может затем быть представлена в неконтролируемые сети для наивной идентификации категорий семантической структуры. Мы не хотим классифицировать числа или текстовые переменные, такие как имена пользователей или серийные номера деталей.
Если синтаксически нормализованная информация надлежащим образом помечена для обозначения сильно изменяющихся символов, таких как счетчики, емкости, метрики и метки времени, может быть применено извлечение признаков для изучения шаблонов выражений таким образом, чтобы поддерживать различие между семантической структурой и переменными. Поддержание этого различия позволяет отслеживать более непрерывные (менее дискретные) тренды в системных показателях. Каждая запись может иметь ноль или более таких переменных, независимо от того, известны ли они априори или недавно получены путем извлечения признаков.
Тенденции могут быть построены по времени или по количеству экземпляров определенного вида. Такая графика может помочь в выявлении механической усталости, приближения условий избыточной емкости или других рисков, которые перерастают в точку отказа. Дальнейшие нейронные сети могут быть обучены формировать предупреждающие индикаторы, когда тренды указывают на такие условия.
Lazy Logging
Весь этот анализ журналов был бы спорным, если архитекторы программного обеспечения и технические специалисты прекратили оставлять формат хранения важной системной информации на различные удобные прихоти разработчиков программного обеспечения. Файлы журналов обычно являются беспорядком, и извлечение статистической информации о шаблонах в них является одной из наиболее распространенных проблем в контроле качества программного обеспечения. Вероятность того, что строгость когда-либо будет универсально применяться к ведению журналов, невелика, поскольку ни одна из популярных систем ведения журналов не поощряет строгость. Скорее всего, поэтому этот вопрос рассматривался часто.
Раздел требований этого конкретного вопроса
В конкретном случае, представленном в этом вопросе, требование № 1 указывает на предпочтение запускать анализ в браузере, что возможно, но не рекомендуется. Несмотря на то, что ECMA - замечательный язык сценариев, а механизм регулярных выражений, который может помочь в изучении синтаксических анализаторов, встроен в ECMA (что соответствует другой части требования № 1, не требуя дополнительных установок), некомпилированные языки не так уж и хороши. эффективен как Java. И даже Java не так эффективна, как C, из-за сбора мусора и неэффективности, возникающей из-за делегирования отображения байт-кода в машинный код во время выполнения.
Во многих экспериментах по машинному обучению используется Python, еще один замечательный язык, но большая часть работы, которую я проделал в Python, была затем перенесена на вычислительно эффективный C ++ для увеличения скорости почти от 1000 до одного во многих случаях. Даже поиск метода C ++ был узким местом, поэтому порты используют очень мало наследования в стиле ECMA, но гораздо быстрее. В типичном традиционном коде ядра использование структур C и указателя функции устраняет накладные расходы vtable.
Второе требование модульных обработчиков является разумным и подразумевает триггерную среду правил, о которой многие могут подумать, что она несовместима с NN-архитектурами, но это не так. Как только категории шаблонов были идентифицированы, поиск наиболее распространенных категорий сначала в дальнейших входных данных уже подразумевается в известном / неизвестном различии, уже встроенном в процесс выше. Однако с этим модульным подходом есть проблема.
Поскольку работоспособность системы часто обозначается тенденциями, а не отдельными записями (как обсуждалось выше) и поскольку работоспособность системы не является линейной суммой значения работоспособности отдельных записей, модульный подход к обработке записей не должен просто передаваться на дисплей без дополнительной анализ. Это на самом деле, где нейронные сети обеспечат наибольшую функциональную выгоду в мониторинге здоровья. Выходные данные модулей должны войти в нейронную сеть, которую можно обучить, чтобы идентифицировать эти нелинейные признаки здоровья, надвигающейся опасности и условий риска.
Кроме того, временной аспект поведения перед отказом подразумевает, что в эту сеть должно входить все временное окно записей журнала значительной длины. Это также подразумевает неуместность ECMA или Python в качестве выбора для вычислительно интенсивной части решения. (Обратите внимание, что тенденция в Python - делать то, что я делаю с C ++: использовать объектно-ориентированный дизайн, инкапсуляцию и простые в использовании шаблоны проектирования для контрольного кода и очень эффективный в вычислительном отношении код, подобный ядру, для реального обучения и других вычислительно сложных или интенсивно работающих с данными функции.)
Алгоритмы выбора
Не рекомендуется выбирать алгоритмы на начальных этапах архитектуры (как подразумевалось в конце вопроса). Архитектор процесса первым. Определите обучающие компоненты, тип их необходимых, их целевое состояние после обучения, где можно использовать подкрепление, и как будет генерироваться сигнал здоровья / ошибки для усиления / исправления желаемого поведения сети. Основывайте эти определения не только на желаемом контенте дисплея, но и на ожидаемой пропускной способности, требованиях к вычислительным ресурсам и минимальной эффективной скорости обучения. Алгоритмы, язык и планирование мощности для системы могут быть осмысленно выбраны только после того, как все эти вещи хотя бы приблизительно определены.
Подобная работа в производстве
Простой адаптивный анализ выполняется здесь в лаборатории как часть автоматизации социальных сетей, но только для ограниченного набора символов и последовательных шаблонов. Он масштабируется без перенастройки в произвольно большие базовые лингвистические единицы, префиксы, окончания и суффиксы, ограниченные только нашими аппаратными возможностями и пропускной способностью. Существование библиотек регулярных выражений помогло сохранить простоту проектирования. Мы используем библиотеку серии PCRE версии 8, снабженную ансиотропной формой DCNN для извлечения объектов из окна, перемещающегося по входному тексту с настраиваемым размером окон и размером шага перемещения. Эвристика, примененная к входной текстовой статистике, собранной за первый проход, создает набор гипотетических PCRE, расположенных в два слоя.
Оптимизация происходит для применения более высоких вероятностных весов к лучшим PCRE в хаотически возмущенном текстовом поиске. Он использует те же стратегии сходимости градиентного спуска, которые используются при обратном распространении NN при обучении. Это наивный подход, который не делает предположений, таких как наличие обратных следов, файлов или ошибок. Он будет одинаково адаптироваться к арабским и испанским сообщениям.
На выходе получается произвольный ориентированный граф в памяти, который похож на дамп объектно-ориентированной базы данных.
Хотя повторно введенный алгоритм для версии подкрепления заглушен, и сигнал оздоровления уже доступен, другая работа прервала развитие адаптивного синтаксического анализатора или переход к следующему шагу, чтобы использовать работу для естественного языка: сопоставление ориентированных графов с сохраненным ориентированным графом фильтры, представляющие идеи, которые будут имитировать аспект повторения идеи языкового понимания.
Заключительные комментарии
Система имеет компоненты и архитектуру процесса, аналогичную проблеме анализа журналов, и подтверждает концепции, перечисленные выше. Конечно, чем больше дезорганизации в способе ведения журнала между разработчиками системы, делающими запись, тем труднее человеку или искусственному агенту устранить неоднозначность записей. Некоторые системные журналы так плохо контролируют качество, что журналы практически бесполезны.
источник