Конференция по конкурентоспособности качества TiD2020 пригласила Чжао Мина, главу отдела качества и инженерной эффективности промежуточного этапа искусственного интеллекта TAL, выступить перед участниками с замечательным докладом на тему «Практика исследований и разработок платформы повышения инженерной эффективности искусственного интеллекта».
Чжао Мин поделился архитектурой и практикой индикаторов алгоритмов ИИ и оценочной платформой, архитектурой и практикой платформы тестирования производительности микросервисов ИИ, архитектурой и практикой платформы управления наборами данных, а также соответствующими демонстрациями случаев из трех ключевых слов: квази, быстрый и стабильный.
Точность: алгоритмы ИИ должны соответствовать потребностям реальных бизнес-сценариев и обеспечивать высокую точность. Быстро: после обработки изображения алгоритмом результат возвращается на сторону приложения/веб-сайта пользователя.Необходимо оценить его сквозные показатели, такие как 200~300 миллисекунд, есть ли быстрый отклик и возвращение. Основываясь на этом спросе, мы разработали платформу тестирования производительности микросервисов. Стабильный: например, когда голос, изображение или текст отправляются в модель, не будет задержки или даже коллапса модели, что тесно связано с надежностью модели.
TAL стремится сочетать технологии искусственного интеллекта с образовательными сценариями, создавать различные возможности искусственного интеллекта и постоянно улучшать опыт и эффективность обучения. Существует три основных типа разработки моделей, связанных с технологией ИИ.
**Первая речь**, включая распознавание речи, оценку речи, распознавание эмоций и анализ эмоций. Например, ASR преобразует речь в текст и оценивает беглость и точность чтения на английском языке. Это его образовательная сцена.
**Второе изображение**, такое как распознавание текста OCR, поиск фотографий и оценка аккуратности заметок, просмотр содержания учебных сцен и т. д., будут использовать модели алгоритмов изображения для повышения эффективности.
**Третья часть интеллектуального анализа данных** частично связана с обработкой естественного языка НЛП, такой как текстовый поиск по ключевым словам, статистика характеристик в классе, захват чудесных моментов, оценка способности китайского устного выражения. Возможности этой серии моделей будут развернуты на платформе PaaS в качестве микросервиса искусственного интеллекта для каждого абонента.
(1) Алгоритмы часто тестируются без автоматизации
На уровне алгоритма изменения модели, такие как повышение скорости квазивызовов, повышение надежности и увеличение количества новых данных; уровень обслуживания, такой как оптимизация производительности, изменения интерфейса и т. д., должен быть полностью проверено, поэтому тест очень частый. Этот процесс не автоматизирован, и его эффективность относительно низка.
(2) Отсутствие восприятия лидерства в отрасли
Инженеры-алгоритмы будут использовать лидерство в отрасли как очень объективную основу для формулирования KPI. Например, 50% возможностей ИИ могут быть первыми в отрасли, это измерение фактически является целью алгоритма KPI. Как оценить эту цель? Нам нужно измерить его и отобразить индикаторы через платформу. Без этой платформы лидерство в отрасли было бы незаметным.
(3) Высокая стоимость оценки производительности после настройки производительности.
Будь то модель алгоритма или сервис-ориентированная оптимизация и расширение, нам необходимо провести сквозную оценку производительности. По мере увеличения частоты оценок растет и стоимость.
(4) Фрагментация данных
Данные — это кровь ИИ. В процессе производства и разработки ИИ каждое звено неотделимо от данных. Данные должны передаваться в каждой роли. Для продуктов, алгоритмов, инженерных исследований и разработок, а также тестирования требуется унифицированное управление данными. Если данные различных сторон бизнеса, в том числе данные различных версий, не будут иметь единой платформы, они будут очень фрагментированы и сложны в управлении и обслуживании.
Исходя из болевых точек, мы внесли улучшения, то есть построение платформы. Мы надеемся, что вышеупомянутые четыре типа проблем бизнеса могут быть решены путем создания платформы оценки алгоритмов, платформы тестирования производительности и платформы управления наборами данных.
(1) Строительство системы инструментальной платформы
Создание инструментов требует наделения каждой роли полномочиями. Например, требования к продукту, в том числе эффект после запуска продукта, инструментов для отслеживания ссылок на самом деле много. Для алгоритмов, таких как базовая модель возможностей ИИ, также необходимы некоторые цепочки инструментов, помогающие улучшить выходные данные алгоритма. Модель предоставляет инструмент как сервисно-ориентированный интерфейс для внешнего вызова. Мы должны обеспечить его качество на протяжении всего процесса и контролировать всю связь через Devops, систему эксплуатации и обслуживания.
С точки зрения качества продукты отвечают за качество требований, алгоритмы отвечают за качество моделей ИИ, разработка отвечает за качество кода, тестирование отвечает за качество сквозных продуктов, а операции и обслуживание несет ответственность за качество онлайн-продуктов после их запуска.Все ссылки неразделимы.Поддержка открытых данных и инструментов, связанных с качеством.
(2) Алгоритм индекса Al и архитектура и практика платформы оценки
1. Требования к сценарию и пользователи
Первый сценарий, неразмеченные данные: скрининг плохих регистров с помощью алгоритма ИИ. Нет необходимости заранее аннотировать данные, и вы можете автоматически отсеивать плохие случаи в процессе анализа и сравнения конкурирующих продуктов. Второй сценарий, неразмеченные данные: точность алгоритма новых данных тщательно исследуется. Мы будем использовать новые данные, чтобы провести тщательное исследование точности алгоритма, основанного на этой платформе. В третьем сценарии данные размечены: показатели алгоритма ИИ, оценка конкурентного продукта и опережающий анализ. Он будет использовать отмеченные данные в качестве индикаторов алгоритма и оценивать объективно и количественно, включая анализ лидерства на рынке. Четвертый сценарий помечен как данные: оценка и анализ индекса алгоритма ИИ. Для размеченных данных показатели алгоритма могут быть дополнительно проанализированы и оценены, включая поиск плохих случаев и предоставление этих данных алгоритму для дальнейшей оптимизации модели. В этих четырех сценариях нашими основными пользователями являются алгоритмы, специалисты по тестированию алгоритмов и менеджеры по продуктам.
2. Техническая архитектура
Техническая архитектура индекса и платформы оценки алгоритма AI разделена на уровень базовых функций и вызова интерфейса, уровень логической абстракции и уровень пользовательского интерфейса.
Базовые функции и уровень вызовов интерфейса, включая управление полномочиями, управление источниками данных, управление хранилищем, модуль управления экземплярами анализа и управление отчетами. Вышеупомянутое вызовет интерфейс собственной разработки и интерфейс конкурирующего продукта через вызов интерфейса, а также проведет унифицированное управление через библиотеку сценариев, например, входные параметры, возврат выходных параметров и стандартизацию форматов.
Слой логической абстракции предназначен для интеграции основных функций в рабочий процесс, для расчета показателей алгоритма или для сквозной обработки данных. Данные должны быть предварительно обработаны — десенсибилизированы, шумоподавлены, очищены, повернуты или отфильтрованы для пустого звука. Результаты обработки разных моделей имеют разные правила оценки показателей алгоритма. Например, показателем речи является частота ошибок в словах. Метрикой для изображений является скорость квазивызовов. Итак, как их можно унифицировать и управлять ими единым образом? Регистрация возможностей ИИ предназначена для унификации новых возможностей разработки. Как зарегистрировать его на этой платформе, когда основная логика и верхний пользовательский интерфейс остаются неизменными? Например, сейчас имеется от 10 до 100 возможностей, и необходимо минимизировать изменения и влияние внешней и внутренней логики или рефакторинга кода из-за регистрации новых возможностей. Проще говоря, он отделяет базовую инфраструктуру от бизнеса микросервисов искусственного интеллекта верхнего уровня. Для экспорта результатов мы будем сообщать о соответствующих результатах обработки в соответствии с различными шаблонами и различными моделями алгоритмов. Ее можно преобразовать в таблицу для последующей сортировки и анализа отчетов.
Над уровнем логической абстракции также будет находиться многоконкурентный механизм обработки продуктов, который используется для неразмеченных данных и автоматического анализа плохих случаев, включая сравнение данных других конкурирующих продуктов для выявления собственных недостатков.
Слой пользовательского интерфейса. Есть примеры оценки, визуальное расположение, а также просмотр плохих случаев и отображение отчетов через некоторые визуальные интерфейсы.
3. Фактический эффект
Платформа индекса и оценки алгоритма Al может предоставить плохой вариант алгоритма и предоставить разработчикам алгоритмов справочную информацию для оптимизации модели. Например: ошибка распознавания OCR, в процессе распознавания изображения данные шума, вызванные проблемами печати, повлияют на распознавание. На приведенном выше рисунке «____in» распознается как «-tin» в процессе распознавания. Следовательно, при обработке модели алгоритмом необходимо повысить надежность самой модели, и для этого сценария необходимо выполнить специальную настройку модели. Ошибка транскрипции ASR — это несоответствие размеченным данным в процессе преобразования речевых данных в текст. Например, помеченные данные — это количество предложений нашего отдела в этом году. А вот точность модели АВ не очень. Произошла ошибка в процессе распознавания. Модель А распознала как «один год, в этом году, у нас мало баллов в этом году», а модель Б распознала как «сколько баллов было у нашего отдела в этом году?» Предложение и точки плохо различимы.
Мы составим список ошибок, организуем и соберем унифицированные отчеты для плохих случаев и предоставим их инженерам-алгоритмам для оптимизации модели.
4. Метрики для алгоритмической оценки модели
Независимо от того, хороша модель или плоха, стандарту оценки необходим набор объективных показателей.
Статистические показатели для изображений включают точность, правильность, полноту, F1 и т. д. Точность, полнота и точность могут быть рассчитаны по формулам через параметры TP, FN, FP и TN, и, наконец, можно оценить соответствующую скорость и точность отзыва, чтобы увидеть, что необходимо улучшить по сравнению с предыдущей версией. Для речи в качестве статистического показателя можно использовать WER/CER (коэффициент ошибок слов/частей). Чем ниже этот показатель, тем лучше. В качестве показателя расчета используется ошибка вставки, ошибка удаления, ошибка подстановки, деленная на общее количество слов. Расчетные индикаторы встроены в платформу в виде скриптов.
Для показателей производительности мы используем CPU, MEM, GPU и т. д. в качестве статистических показателей. Для показателей стабильности в качестве статистических показателей в основном используются частота сбоев и утечка памяти. Благодаря этим измерениям мы можем объективно оценить, является ли модель точной, быстрой и стабильной.
5.Demo1-Алгоритм автоматического скрининга Badcase
Для сценариев с неразмеченными данными
Во-первых, у нас будет визуальный интерфейс макета, сначала перетащите источник данных. Этот источник данных на самом деле представляет собой набор данных на FTP, который на самом деле является папкой, в которой сохраняются тестируемые изображения. Мы проведем предварительную обработку изображения, например, десенсибилизацию данных, автоматическое выравнивание и т. д. Поскольку изображение может быть не положительным, некоторые модели будут использоваться для его исправления. Это облегчает анализ модели. Мы сравним десенсибилизированные данные с тремя внешними конкурирующими моделями одновременно.
Badcase похож на метод голосования. Например, есть три модели ABC. Если результаты, полученные с помощью анализа речи, все «Сегодня пятница», то его достоверность очень высока. Если результаты самоисследования отличаются от результатов анализа этих трех моделей, то с высокой вероятностью это Badcase. Его преимущество в том, что его не нужно маркировать, и он может брать данные из Интернета и автоматически фильтровать их. После обработки модели будет выполнена некоторая постобработка для удаления некритических факторов, таких как знаки препинания, пробелы и возврат каретки. После обработки Badcase отобразится на странице. На этой странице мы можем настроить порог. Чем выше порог, тем больше вероятность плохого случая. Например: точность Badcase составляет 0,9, что указывает на то, что это, скорее всего, будет badcase. Если он равен 0,2, это может быть ложным срабатыванием.
Для печатной формы мы проведем оценку распознавания текста для преобразования изображения в текст, включая Goodcase и Badcase. Мы можем автоматизировать анализ неразмеченных данных через платформу. Проанализированный Badcase может быть предоставлен инженерам-алгоритмам для основной итерации и оптимизации.
6.Demo2-Конкурсная оценка показателей алгоритма
Для помеченных данных
Сначала с помощью интерфейса визуальной оркестровки создайте экземпляр и назовите версию.
Мы перетащили данные с FTP, а затем выполнили анализ модели и ввели данные одновременно в три модели, одна из которых была собственной разработкой. Мы посмотрим на разрыв между самостоятельно разработанной моделью и конкурирующей моделью и, наконец, импортируем помеченные данные, а затем проанализируем их.
Размеченные данные эквивалентны стандартному ответу. Так в итоге получится три вида индикаторов. Каждая модель имеет набор показателей. Таким образом, мы можем проанализировать, как наша модельная индустрия лидирует. Это помогает алгоритму разработать KPI.
Показатели количественной оценки для класса OCR имеют два измерения — точность последовательности и точность символов. Эти две точности позволяют оценить эффект модели. На разных временных итерациях критерии для каждой модели оценки будут разными. Например, в каждом измерении кто-то может быть впереди нас, а кто-то отставать. Эта метрика может показать, где мы находимся в отрасли.
Конечно, мы также можем фильтровать. Этот скрининг может быть нацелен на разные измерения или на разные конкурирующие продукты.Вы можете видеть, что ниже представлен Badcase с тремя моделями. Крайний слева — собственная разработка.
Эффект собственной разработки лучше, чем у двух других конкурирующих продуктов. Так его Badcase будет меньше. Эта страница представляет собой сравнение модели ABC со стандартными данными. Если он точно совпадает со стандартными данными, он точен. Если они несовместимы, это означает, что идентификация неверна.
Для модели алгоритма распознавания формулы печати введите изображение и, наконец, выведите содержимое изображения в виде текста. Для более сложного распознавания формул необходимо повысить надежность модели. Это несколько сложно. Как только что было показано, мы можем оценить этот показатель. Он получит результат, вычислив логическую формулу. Тогда вы можете увидеть лидерство в отрасли.
Этот алгоритм платформы и партнеры по тестированию могут использовать его. Продукты могут использовать эту платформу для проведения тщательного исследования новых данных без привлечения алгоритмов или тестирования. Ему не нужно понимать очень сложную логику вычислений, и он может помочь инженерам быстро сделать выводы с помощью визуального устройства, такого как перетаскивание.
(3) Архитектура и практика платформы тестирования производительности микросервисов ИИ
1. Требования к сценарию и пользователи
Платформа тестирования производительности микросервисов ИИ призвана решить «быструю» проблему.
Первым требованием является управление и совместное использование алгоритмов и тестовых сред на основе служб. У инженеров-алгоритмистов есть локальная среда исследований и разработок, а у сервис-ориентированной разработки есть набор сред. Задействовано множество версий модели, включая версию базовой зависимой библиотеки Python и другие библиотеки. Стандарты этих библиотек должны быть максимально простыми, а самый простой способ — контейнерное управление и совместное использование среды.
Второе требование — автоматизация развертывания. После тестирования все среды для тестирования производительности должны быть автоматически подготовлены, например сценарии.
Третье требование — автоматическое определение давления, включая установку максимального TPS и параллелизма для реализации автоматического определения давления.
Четвертое требование — анализ узких мест производительности. Анализ узких мест является важной частью. Есть проблемы со скоростью обработки. Для самой модели выполняются сжатие и сокращение модели, чтобы повысить скорость обработки и сократить потери аппаратных ресурсов.
Пользователи платформы тестирования производительности микросервисов ИИ — это тестирование сервисов, тестирование алгоритмов, НИОКР и менеджеры по продуктам. Менеджеры по исследованиям и разработкам и продуктам могут получать показатели эффективности и сообщать клиентам, соответствуют ли они потребностям бизнеса.
2. Техническая архитектура
Архитектура платформы тестирования производительности микросервисов ИИ включает в себя источник данных, уровень интерфейса и уровень пользовательского интерфейса.
Нижний слой — это источник данных, и мы будем использовать Prometheus для удаленного мониторинга данных. Для источника данных будет база данных для постоянного хранения.
Средний уровень — это интерфейсный уровень. Будет предусмотрена логика для автоматического определения давления, включая дистанционное выполнение, развертывание, расчет индексной посадки и дистанционное управление терминалом. Вы также можете войти в систему одним щелчком мыши.
Верхний уровень — это уровень пользовательского интерфейса, который может входить в систему через интерфейс платформы, включая приложение и выпуск ресурсов, автоматическое определение давления и анализ узких мест.
3. Фактический эффект
Платформа может реализовать автоматическое определение давления без участия оператора и определить максимальное значение TPS или количество одновременных запросов системы в кратчайшие сроки в соответствии с алгоритмом дихотомии.
Дихотомия заключается в том, что параллелизм начинается со 100, 100 — это начальное давление, и размер шага также равен 100. Мы проводим инкрементное измерение давления 100 200 300 400. Когда он достигает наибольшей точки перегиба TPS, как показано на рисунке выше, после появления максимального значения 300 давление упадет до 200-300, до 250. Без этой платформы нам пришлось бы каждый раз вручную менять параллелизм. Поскольку существует множество типов служб, некоторые из них основаны на протоколе HTTP, а некоторые — на протоколе Websocket. В целях упрощения и обобщения нижний слой по-прежнему реализуется на основе Jmeter, а затем конфигурация в файле JMX заменяется логикой замены шаблона. Функция инструмента с открытым исходным кодом Jmeter относительно мощная.
В среднем каждый микросервис ИИ должен быть запущен примерно в течение 10 раундов тестирования под давлением с разными числами параллелизма. Раунд 60 минут, 10 раундов это 600 минут, очень много времени. Каждый раз нужно менять скрипт, запускать опрессовку и наблюдать за выводом различных индикаторов. Сервер сообщает об ошибке и должен снизить давление. Если индикатор в норме, продолжайте давление. Это трудоемко и повторяется. А вот с автоматизацией эффект очень очевиден.Его можно сократить с 600 минут до 10. Наконец, просмотрев данные и сообщив, что проблем нет, можно сразу сделать вывод, что очень быстро.
4.Demo3-автоматическое определение давления и анализ узких мест
Сначала подайте заявку на тестер давления. После подачи заявки на тестер давления мы можем войти в систему одним щелчком мыши через терминальное соединение. Здесь можно использовать различные команды. Затем вы можете выполнить развертывание сценария в соответствии с недавно развернутым тестером давления и выполнить развертывание постоянного давления в течение 30 секунд для файла собственного формата Jmeter, а также выполнить мониторинг после развертывания. На этой платформе можно выполнять всю работу, включая приложение ресурсов, удаленное развертывание и выполнение скриптов, вывод результатов, возврат и отображение данных мониторинга. Эту платформу можно использовать в качестве рабочей среды, а различные сценарии можно настроить в соответствии с фактическими потребностями, включая вывод соответствующих отчетов о результатах. Этот отчет отображается как собственный отчет Jmeter. В этом отчете могут отображаться различные показатели, такие как TPS.
В то же время мы также можем выполнять сценарии автоматического обнаружения давления. Давление 100 и размер шага тоже 100. Каждый раунд длится около 60 секунд, а настоящий тест длиннее этого. Тогда зернистость 20, и здесь есть сцена, которая является порогом выхода, то есть настройка зернистости. Гранулярность означает, что разница между максимальным давлением успеха и минимальным давлением отказа меньше значения. Чем мельче размер частиц, тем больше раундов вы проведете.
Как видно из графика мониторинга, после периода работы видно, что когда график достигает 300, TPS достигает точки перегиба, что означает, что TPS имеет узкое место. Когда появится узкое место, нам нужно снизить давление до 250.
Когда мы закончим работу, мы увидим отчет, показывающий, что TPS составляет 551 при 100, TPS составляет 733 при 200, а TPS снижается до 722 при 300. Поэтому нам нужно снова снизить давление до 250~225. Таким образом, мы можем узнать, при каком типе параллелизма его TPS будет самым большим, а пропускная способность будет самой большой. Это сценарий TPS, и есть параллельный сценарий, сколько параллелизма можно допустить без ошибок. Это можно связать с собственными отчетами Jmeter. Это сквозная информация, включая передачу по сети, обработку на основе услуг и продолжительность вызова модели.
Мы можем выбрать временное окно для мониторинга структуры и анализа узких мест. Мы отслеживаем основные показатели, такие как утечки памяти. Порог для утечек памяти можно контролировать, и значение по умолчанию установлено на 5%. Если конечная точка более чем на 5 % выше начальной, мы считаем, что имеется подозрение на утечку памяти. Этот порог процесса можно регулировать. В будущем мы сделаем его еще умнее.
Порог обнаружения использования ЦП, если порог позволяет 80%, а его среднее использование составляет 90%, он сообщит об ошибке о превышении верхнего предела, включая сетевой трафик. Это канбан для общего мониторинга. Разрабатывая сервис фоновой логики, данные забираются обратно из Prometheus для некоторой обработки и обработки, а затем возвращаются через интерфейс для рендеринга из фронтенда. Такая форма может быть достигнута: автоматическое обнаружение стресса в необслуживаемых ситуациях, таких как выходной в пятницу вечером, запуск автоматизированного сценария, определяющего максимальный TPS или параллелизм. Тогда вы сможете получить все отчеты в понедельник утром и даже запустить в нескольких группах. Это экономит время.
Это можно рассматривать как гибкое тестирование с нашими инструментами и платформами, постоянно сокращающими цикл обратной связи для алгоритмов или исследований и разработок.
(4) Архитектура и практика платформы управления наборами данных
1. Требования к сценарию и пользователи
Для различных сценариев спроса он в основном используется для обучения и тестирования. Классификация данных должна быть помечена разными метками, например, какой тип данных относится к какому бизнесу или принадлежит к разным версиям, будь то положительные данные или отрицательные данные, для применения к различным категориям моделей алгоритмов, что собственно для оценки категория.
Некоторые данные могут использоваться инженерами-алгоритмами. Мы используем данные черного ящика при проведении объективных оценок. Это невидимо для инженеров-алгоритмов. Но есть некоторые данные для самотестирования алгоритма, которые можно использовать для тестирования алгоритма вместе с некоторыми данными дымового теста.
Запросите помеченные данные, пометьте данные и посмотрите, какие данные были собраны в прошлом, какие были помечены, а какие нет, или качество их пометки относительно низкое, и эту часть данных необходимо пометить заново.
Нам нужно построить хаотическую тестовую систему, чтобы улучшить стабильность и повысить надежность модели.
Есть также много пользователей платформы управления наборами данных, включая алгоритмы, тестирование алгоритмов, менеджеров по продуктам и операции с данными.
2. Процесс
Сначала выберите набор данных, затем автоматизируйте загрузку, затем выполните обработку, связанную с моделью, и, наконец, проверьте результаты. Обработка модели заключается в отслеживании того, нормально ли работают различные индикаторы в модели расположения данных. В середине этого процесса отслеживание уровня точности, является ли мониторинг точным, быстрым, стабильным или нет, с помощью этого измерения, соответствует ли фактический эффект мониторинга ожиданиям пользователей и бизнеса.
Для различных типов данных, таких как шумовые данные, пустые данные, размытые изображения, недопустимые форматы, увеличенные изображения, данные низкого качества, данные за пределами допустимых значений, фрагментированные данные, изображения источников света и враждебные данные, мы будем обращать внимание на производительность модели алгоритма через различные измерения.
3. Фактический эффект
Мониторинг использования памяти и ЦП в один и тот же период времени может определить, является ли модель стабильной. Как показано на рисунке выше, использование памяти за один и тот же период постоянно меняется и колеблется, а диапазон колебаний составляет 6–8 ГБ.
В то же время колебания загрузки ЦП также нормальны. Колебание максимального значения составляет около 50%, что также находится в допустимых пределах. Таким образом, обработка этого пакета данных не представляет большого риска с точки зрения использования ресурсов, что показывает, что стабильность модели достигла стандарта поставки.
(1) Цели
Принимая во внимание критерии оценки различных измерений, в будущем мы сосредоточимся на высоком качестве, повышении эффективности и снижении затрат, чтобы помочь группам по производству, исследованиям, расчетам и измерениям более гибко предоставлять продукты и микросервисы ИИ с помощью цепочки инструментов или платформы R&D. . это наша цель.
(2) Направление
Для «квази»: мы продолжим оснащать платформу интеллектуальными рекомендательными возможностями, поддерживающими направление оптимизации индикаторов алгоритма. Какая модель используется, на основе анализа Badcase, какие параметры используются и т. д., можно дать интеллектуальную рекомендацию для данных этих измерений, а инженеру-алгоритму можно указать направление следующей оптимизации.
Для «быстрых»: найдите узкое место системы алгоритмов для достижения интеллектуального позиционирования и анализа. Например, можно ли повысить эффективность обработки модели, можно ли выполнить некоторое сжатие данных на инженерном уровне, можно ли повысить производительность при передаче по сетевому каналу и следует ли выполнять горизонтальное расширение при подаче заявки на ресурсы как услугу. .
Для «стабильной»: выполните поиск и обнаружение утечек памяти на основе алгоритмов и служб. Утечки памяти влияют не только на сервис, но и на качество проекта. Это убийца номер один, влияющий на стабильность системы. Как быстро локализовать проблему утечек памяти очень важно и сложно. Обычно для обнаружения проблемы с утечкой памяти, которая совместно анализируется отделами исследований и разработок и алгоритмов, может потребоваться несколько дней. Это противоречит гибким итерациям НИОКР. Поэтому мы продолжаем изучать способы получения формы статического и динамического сканирования с помощью некоторых инструментов для дальнейшего точного позиционирования.