пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Чтобы понять сложные вещи, нам на помощь очень часто приходят простые примеры из жизни. Сейчас предлагаем просто посмотреть на свой шкаф: возможно там царит полный порядок, а возможно, анархия. Для нашего примера понадобятся оба! Для начала представим и заглянем в шкаф, где полный беспорядок: все намешано, найти что-то сложно (не говоря о том, чтобы это что-то еще и было не мятое). Переместимся в шкаф, где царит порядок, и там есть отдельные ящики для каждой категории одежды. Всё разложено по полочкам, и без труда можно найти всё, что нужно. Так вот, микросервисная архитектура по своей сути похожа на этот шкаф с идеальным порядком, только вместо шмоток — программные компоненты. Микросервисы — это не просто модный тренд в IT, а реальная необходимость для многих компаний. Почему? Потому что современные приложения становятся всё более сложными и большими, а пользователи всё более требовательными. Никто не хочет ждать, пока приложение загрузится, или терпеть сбои из-за одной маленькой ошибки. И тут то мир подарил нам микросервисную архитектуру, дабы все упорядочить.
Микросервисная архитектура — это подход к разработке программного обеспечения, при котором приложение делится на множество независимых компонентов (или сервисов). Каждый из них отвечает за свою конкретную задачу и может работать автономно. Как в нашем идеальном шкафу: отдельная полка для футболок, штанов, носков и так далее. Что еще более важно, если какой-то компонент вышел из строя: то все остальные продолжают свою работу как ни в чём не бывало. Погрузимся же глубже.
Почему именно микросервисная архитектура?
Чтобы понять, почему микросервисы стали такими популярными, стоит понять, чем они отличаются от монолитного подхода. Рассмотрим монолитное приложение как один огромный швейцарский нож. Да, он умеет всё: и резать колбаску, и открывать пиво, и чинить батарею. Но вот проблема: если один из инструментов сломается (например, лезвие затупится), то пользоваться ножом становится неудобно или даже невозможно. Но рассмотрим аналог швейцарскому ножу, т.е. простой набор инструментов: нож, открывашка, отвёртка — каждый из них работает независимо от другого. Если нож затупился, то всё ещё можно открыть бутылку. Неплохо, верно?
Монолитное приложение — это единый большой блок кода, где все части тесно связаны друг с другом. Например, если ты разрабатываешь интернет-магазин, то в монолите всё будет в одном месте: и корзина покупок, и система оплаты, и поиск товаров. Казалось бы, удобно? Только на первый взгляд. Проблемы начинаются, когда нужно внести изменения. Допустим, ты решил обновить алгоритм поиска товаров. Трогаешь одну часть кода, а что-то неожиданно ломается в корзине или на странице оплаты. Напоминает игру в дженгу и бесконечные попытки поймать все баги.
Микросервисы же работают по-другому. Здесь каждая функция приложения — это отдельный сервис. Есть отдельный «сервис корзины», «сервис оплаты», «сервис поиска». Они общаются друг с другом через чётко определённые интерфейсы (обычно через API), но при этом остаются независимыми. Если нужно обновить алгоритм поиска, просто меняешь код в соответствующем сервисе. Остальные части приложения даже не замечают этого.
Основные принципы микросервисной архитектуры
Если микросервисы — это оркестр, то принципы, о которых мы сейчас поговорим, — это дирижёрская палочка. Без этого вся система превратится в хаотичное звучание, где барабанщик ушёл в нирвану, скрипач — в классику, а пианист вообще ушёл пить кофе. Чтобы всё работало слаженно и красиво, существуют некоторые правила, о которых сейчас и пойдёт речь.
Начнём с того, что уже частично затронули выше, а именно - независимость компонентов. Каждый микросервис — это самостоятельный механизм, который просто работает свою работу. Да, это немного, но это честная работа. Независимость позволяет командам разработчиков работать автономно. Ты можешь обновлять или чинить один сервис, не боясь, что где-то в другом месте что-то сломается.
Далее в списке идёт возможность развертывания отдельных модулей. В микросервисах ты можешь развернуть (или обновить) только один конкретный сервис, а не всё приложение целиком. Поиграем снова в имадженариум, вообразим в этот раз интернет-магазин. Нужно улучшить алгоритм рекомендаций товаров. В монолите вам пришлось бы обновить весь код приложения, протестировать его и переживать за возможные сбои. А с микросервисами ты просто выкатываешь обновление для «сервиса рекомендаций», и всё остальное продолжает работать как ни в чём не бывало. Звучит как сказка, ну… почти)
Чёткие границы ответственности. Каждый микросервис отвечает за свою чётко определённую задачу. Что также удобно при работе в команде, ведь видно сразу разделение обязанностей не только в программных компонентах, но и среди разработчиков. Чёткие границы ответственности делают систему понятной и предсказуемой. Если что-то пошло не так (например, клиент не может оформить заказ), то не нужно ковыряться в монолите кода, искать, где конкретно и кто писал эту функцию, достаточно понять, какой именно это микросервис.
Окей, это было просто понять, но вот как микросервисы между собой вообще работают? Они же не должны работать всё равно вместе. Ответ прост и состоит из трёх букв – API (а вы о чём подумали?). Микросервисы общаются друг с другом через API (Application Programming Interface) — это чётко определённый язык общения между сервисами. Он позволяет каждому сервису быть независимым и при этом эффективно взаимодействовать с другими.
Познакомились с базой, так, а что там по соотношениям плюсов к минусам? Ща разложим карты и на это.
Плюсы, минусы и вызовы микросервисной архитектуры
Конечно же, начнем с плюсов микросервисной архитектуры (а ведь их реально много). Вот они, сверху вниз:
Масштабируемость.
В случае, если вашему приложению пришло время «подрасти», то с микросервисами достаточно просто добавить воды! Ладно, на самом деле увеличить мощность только необходимых сервисов или же написать новые, и не трогать остальные. Аналогично работает и с простыми обновлениями.
Независимость разработчиков по отдельности или же команд по отдельности
(в зависимости от масштаба). Они могут работать над своим микросервисом, не мешая другим. Результат? Быстрее, чище и без лишнего стресса. Тут в целом все просто. Как и во всем, если разобраться)
Надёжность
. Этого нам всем не хватает, а вот микросервесы умеют и делают. Если один сервис упал, остальные продолжают работать. Например, если в приложении временно недоступен сервис рекомендаций товаров (потому что кто-то где-то накосячил), пользователи всё равно смогут оформить заказ.
Плюсы простые, но безумно нужные. А теперь пришло время минусов.
Сложность управления.
Чем больше микросервисов, тем сложнее ими управлять. Прикинь, если бы у тебя было 50 котиков: каждый требует внимания, ухода и еды. В итоге ты больше времени тратишь на организацию, чем на саму работу.
Сетевые задержки.
Микросервисы взаимодействуют друг с другом через сеть, а это значит, что могут возникать задержки. Например, если «сервис корзины» медленно отвечает «сервису заказов», пользователь может подумать, что приложение зависло. А если сервисов много (как и предполагается), и если хотя бы некоторые из них медленно передают друг другу API, то скорости нам не видать.
Затраты
… Всего... Каждый микросервис требует своих ресурсов: серверов, баз данных и инструментов мониторинга, людей и печенек. В итоге можно потратить больше денег на инфраструктуру, что не всегда возможно, да и вообще нужно, особенно в небольших проектах.
Сложность тестирования
. Тестировать микросервисы сложнее, чем монолитное приложение. Это нужно убедиться не только в том, что каждый сервис работает правильно, но и в том, что они корректно взаимодействуют друг с другом. А это все тянет за собой все тот же пункт про затраты.
С глобальными минусами на этом все. Согласись, они были не столь очевидны. Немаловажным вопросом так же является вопрос «А когда микросервисы могут быть избыточными?»
Когда нужны микросервисы
Не всегда стоит бежать за модой и переходить на микросервисы только потому, что «все так делают, значит круто». Иногда это просто лишняя головная боль. И так, когда же?
Небольшие проекты или стартапы. Если проект небольшой (например, приложение для учёта личных расходов), то микросервисы будут избыточны. Также, если у команды банально нет опыта. Если команда никогда раньше не работала с микросервисами, переход на них может превратиться в кошмар из бесконечных багов и срывов сроков. Не того мы хотели ведь, правда? Исходя из статьи про затраты, не трудно догадаться, что если ресурсы ограничены, то микросервисы не наш выбор, ведь они требуют больше серверов, инструментов мониторинга и специалистов по DevOps, что не сочетается с маленькой командой и небольшим бюджетом.
Собственно, микросервисы – это очень крутая тема, но, как и все в этом мире, она хорошо работает только там, где нужна. Микросервисная архитектура – относительно новый тренд и как мы поняли, это очень классный тренд, помогающий увеличить эффективность разработки многократно на больших проектах. Следим за новшествами и дальше, кто знает, что изобретут уже завтра?
Привет, дорогой читатель! В сегодняшней статье, мы расскажем, как облегчить себе жизнь при работе с виртуальными машинами в среде VirtualBox. Возможно кто-то уже догадался, что речь пойдёт от о Guest Additions.
Обзор
Guest Additions - это набор системных драйверов и приложений, которые обеспечивают более тесную интеграцию хоста виртуализации и гостевых виртуальных машин, которые развёрнуты на хосте. Эти приложения оптимизируют производительность гостевых виртуальных машин и делают работу с ними более удобной. При этом, что очень важно, дополнительные ресурсы хоста виртуализации выделять не нужно!
Стоит отметить, что данный функционал реализован почти во всех популярных средах виртуализации. Например в VmWare, аналогом Guest Additions является VmWare Tools, в в Hyper-V - Integration Services
Guest Additions поддерживается для виртуальных машин всех популярных ОС: Windows, Linux, Mac OS X, FreeBSD, OpenBSD, Solaris. Полный список поддерживаемых ОС можно найти на сайте разработчика: https://www.virtualbox.org/manual/ch03.html#guestossupport.
Поставляется в виде образа .iso CD/DVD диска, который находится в установочной директории VirtualBox и называется VBoxGuestAdditions.iso.
Ну например в Windows 7 образ можно найти в C:Program FilesOracleVirtualBox, если Вы, конечно, не установили сам VirtualBox куда-то ещё.
Поэтому нужно просто подмонтировать образ этого диска в виртуальной машине и запустить процесс установки.
Функциональные возможности
Итак, почему же стоит устанавливать Guest Additions? Сейчас объясню. Guest Additions включает следующий функционал:
Интеграция указателя мыши. Больше не надо нажимать дополнительных кнопок чтобы “захватывать” (capture) и “освобождать” курсор на экране виртуальной машины.
Общие папки. Позволяет создавать общие папки для быстрого обмена файлами между хостом и гостевой виртуальной машиной.
Функция Drag and Drop. Позволяет переносить файлы с хоста на гостевую виртуальную машину и наоборот, захватывая контент курсором мыши.
В данном примере, мы перенесли файл text_file.txt с виртуальной машины с ОС Windows 7 на хост под управлением OS Linux Ubuntu при помощи функции Drag and Drop
Поддерживается начиная с VirtualBox 5.0. После установки Guest Additions, данный функционал необходимо включить в разделе Devices → Drag and Drop
Улучшенная поддержка видео. Становится доступным ресайзинг окна виртуальной машины. Автоматически настраивается разрешение. Включается поддержка 3D и 2D графики и ускоренная производительность видео.
Общий буфер обмена. Тут всё просто – теперь можно Copy/Paste как из, так и в виртуальную машину.
Включается также в разделе Devices → Clipboard
Временная синхронизация. Включает автоматическую синхронизацию времени между хостом виртуализации и виртуальной машиной. Это важно в случае, когда например нужно “приостановить” (pause) работу виртуальной машины на большой промежуток времени.
Одновременная работа с окнами разных ОС. Данный функционал лучше всего проиллюстрирует картинка ниже:
В данном примере – на хосте с OS Windows 7 в VirtualBox развёрнута виртуальная машина с OS Ubuntu Linux. Как видите, с помощью Guest Additions мы может одновременно работать с окнами этих ОС. На картинке – справа открыт Internet Explorer в Windows, а слева Mozzila Firefox в Ubuntu.
Автоматические логины - позволяет настроить автоматический вход в виртуальную машину с помощью специальной подсистемы. Нужно только забить в ней реквизиты для доступа – имя учётной записи, пароль и домен.
В общем, если собираетесь работать с виртуальной машиной долго, то устанавливать Guest Additions – нужно! Это значительно облегчит работу. Тем более, что установка не займёт много времени. Кстати об установке.
Установка Windows
Установка Guest Additions для виртуальных машин с ОС Windows довольно тривиальна. В панели управления виртуальной машиной выбираем Устройства (Devices) → Подключить образ диска Дополнений гостевой ОС (Insert Guest Additions CD image)
После этого система определит, что был установлен установочный диск, осталось только нажать Run и следовать стандартной процедуре установки. После установки система должна перезагрузиться, если этого не произошло, то сделайте это вручную.
Linux через GNOME
Установка на Linux с графическими интерфейсами типа GNOME также всё очень просто.
Для этого также выбираем Устройства (Devices) → Подключить образ диска Дополнений гостевой ОС (Insert Guest Additions CD image) в панели управления VirtualBox:
После этого система определит установочный диск и останется лишь нажать Run Software. После установки также требуется перезагрузить систему.
Linux через консоль
Гораздо интереснее дела обстоят с установкой на Linux без графических интерфейсов через консоль. Рассмотрим установку на примере CentOS 6. Начинаем с того, что также вставляем виртуальный диск.
После этого переходим в подмонтированный раздел: cd /mnt/cdrom/
И запускаем процесс установки следующей командой: ./VBoxLinuxAdditions.run
После этого делаем reboot.
Если всё прошло успешно, что появится новый модуль vboxguest. Проверить можно командой: lsmod | grep vboxguest:
Бесконечные споры вокруг искусственного интеллекта приводят к путанице. Существует много терминов, которые кажутся похожими, но это не так. Мы постараемся разобраться и противопоставить искусственный интеллект (ИИ или artificial intelligence, AI), машинное обучение (machine learning, ML), глубокое обучение (deep learning) и нейронные сети (neural networks), чтобы их разграничить.
Кратко говоря, мы рассмотрим, как все эти концепции связаны друг с другом и что делает их различными. Мы также разберем роль ИИ в каждом из этих понятий.
ИИ, машинное обучение, глубокое обучение и нейронные сети: как они связаны?
Лучший способ понять, как эти понятия связаны между собой, — использовать аналогию с матрешкой, что означает, что эти концепции являются компонентами друг друга.
Проще говоря, машинное обучение — это подслой искусственного интеллекта. Нейронные сети — это подслой машинного обучения. А алгоритмы глубокого обучения являются развитием концепции нейронных сетей.
Что отличает нейронные сети от глубокого обучения, так это то, что одно является более сложным компонентом другого.
Рассмотрим некоторые ключевые различия, чтобы лучше понять, как работают эти компоненты ИИ.
Чем глубокое обучение отличается от нейронных сетей?
Мы уже говорили о том, что нейронные сети и глубокое обучение не являются полностью независимыми концепциями. Когда мы говорим о глубоком обучении, мы имеем в виду “глубину” слоев и узлов в нейронной сети. Таким образом, нейронная сеть, состоящая из более чем трех слоев (включая входной и выходной), считается алгоритмом глубокого обучения.
Еще один ключевой фактор заключается в том, что большинство глубоких нейронных сетей являются прямыми, то есть данные перемещаются исключительно от входа к выходу. Модели также могут обучаться с помощью обратного распространения ошибки, что позволяет им двигаться в подходящем направлении от выхода к входу.
Эта модель позволяет специалистам по данным вычислять и приписывать ошибку, связанную с каждым нейроном сети, что позволяет им корректировать узлы в алгоритме для достижения желаемого результата.
Вот еще несколько различий между глубоким обучением и нейронными сетями:
Сеть глубокого обучения имеет много различных слоев, что делает её более сложной, чем нейронная сеть.
Система глубокого обучения выполняет задачи более эффективно и результативно, в то время как нейронная сеть выполняет задачи немного менее эффективно.
Основные компоненты единицы глубокого обучения — это обширный источник питания, GPU и большой объем оперативной памяти. В то время как основные компоненты нейронной сети — это нейроны, скорость обучения, связи, функции распространения и веса.
Из-за своей сложности сети глубокого обучения требуют значительного времени для обучения, тогда как нейронные сети требуют меньшего времени на обучение.
Глубокое обучение против машинного обучения: чем они отличаются?
Прежде чем узнать о различиях между глубоким обучением и машинным обучением, важно понять, что алгоритмы глубокого обучения и машинного обучения не являются противоположными концепциями. Вместо этого алгоритмы глубокого обучения фактически являются алгоритмами машинного обучения.
Следовательно, лучше рассматривать то, что делает глубокое обучение уникальным в рамках машинного обучения, вместо противопоставления глубокого обучения и машинного обучения. В широком смысле, особенности, которые делают глубокое обучение уникальным, включают структуру алгоритма нейронной сети, меньшую необходимость в человеческом вмешательстве и более обширные требования к данным. Давайте рассмотрим их по отдельности:
Во-первых, традиционные алгоритмы машинного обучения имеют относительно простую структуру, включая линейную регрессию или модель решающего дерева. В то время как модели глубокого обучения основаны на искусственной нейронной сети. Эти нейронные сети имеют много слоев и (как и человеческий мозг) сложны и переплетены через узлы (аналог нейронов человека).
Во-вторых, модели глубокого обучения требуют гораздо меньше человеческого вмешательства, чем их обычные аналоги в машинном обучении. Например, ИИ для автономного автомобиля будет иметь возможность распознавать дорожные знаки без ручного вмешательства инженера-программиста, также известного как извлечение признаков.
Наконец, глубокое обучение требует значительно больше данных, чем стандартные алгоритмы машинного обучения. Машинное обучение часто работает с тысячами точек данных, тогда как глубокое обучение может работать с миллионами. Из-за своей сложной многослойной структуры системы глубокого обучения нуждаются в большом наборе данных, чтобы уменьшить или устранить колебания и делать качественные интерпретации.
Как ИИ вписывается в эти концепции?
Перед тем как ответить на этот вопрос, давайте вспомним, что такое искусственный интеллект.
Искусственный интеллект — это способность компьютерной системы имитировать человеческие когнитивные функции, такие как обучение и решение проблем. С помощью ИИ компьютерная система использует математику и логику, чтобы имитировать рассуждения человека, учиться на новой информации и принимать решения.
Это область, изучаемая специалистами по данным на протяжении многих лет, и они продолжают расширять свои возможности с каждым новым технологическим достижением в области аппаратного и программного обеспечения.
Итак, быстрый ответ на наш первоначальный вопрос заключается в том, что ИИ охватывает все, что связано с машинным обучением, нейронными сетями и глубоким обучением. Но чтобы быть более конкретными, мы разберем это по отдельности.
ИИ против машинного обучения
Хотя ИИ и машинное обучение тесно связаны, они не являются одним и тем же. Машинное обучение считается подмножеством ИИ. Это аналогичное недопонимание, как и в случае с различием между глубоким обучением и машинным обучением.
Машинное обучение — это общий термин, обозначающий, когда компьютеры учатся на данных. Это перекресток компьютерных наук и статистики, где используются алгоритмы для выполнения конкретной задачи без явного программирования; вместо этого они распознают паттерны в данных и делают прогнозы, когда появляются новые данные.
В общем, процесс обучения этих алгоритмов может быть либо контролируемым, либо неконтролируемым, в зависимости от данных, используемых для обучения алгоритмов.
ИИ против искусственных нейронных сетей
Как уже упоминалось, ИИ относится к машинам, которые могут имитировать когнитивные навыки человека. Нейронные сети, с другой стороны, представляют собой сеть искусственных нейронов или узлов. Они отдаленно вдохновлены биологическими нейронными сетями, которые составляют человеческий мозг.
Системы нейронных сетей функционируют аналогично цепи нейронов у человека, которые принимают и обрабатывают информацию. Нейронные сети основаны на алгоритмах, найденных в нашем мозге, которые помогают их работе.
Нейронная сеть интерпретирует числовые паттерны, которые могут принимать форму векторов. Нейронные сети используются для перевода этих векторов. Основная функция нейронной сети — классификация и категоризация данных на основе сходства.
Наибольшее преимущество нейронной сети в том, что она может легко адаптироваться к изменяющимся паттернам выходных данных. Кроме того, вам не нужно корректировать её каждый раз на основе предоставляемого ввода, что может быть достигнуто с помощью контролируемого или неконтролируемого обучения.
ИИ против глубокого обучения
Искусственный интеллект — это концепция создания инновационных, умных машин. Глубокое обучение является подмножеством машинного обучения, которое использует огромные объемы данных и сложные алгоритмы для обучения модели.
Глубокое обучение описывает алгоритмы, которые анализируют данные с логической структурой, подобной тому, как человек делает выводы из исследования данных и проб и ошибок. Обратите внимание, что это может происходить как через контролируемое, так и через неконтролируемое обучение.
Для достижения этого приложения глубокого обучения используют слоистую структуру алгоритмов, называемую искусственной нейронной сетью (ANN). Дизайн такой ANN вдохновлен биологической нейронной сетью человеческого мозга, что приводит к процессу обучения, который намного более способен, чем у стандартных моделей машинного обучения.
Точность глубокого обучения может увеличиваться с увеличением объема данных
Модели глубокого обучения обычно более точны, поскольку объем данных для обучения увеличивается, хотя стандартные модели машинного обучения, такие как SVM / Naive Bayes / Classified Model, перестают улучшаться после достижения точки насыщения. Модели глубокого обучения масштабируются лучше с увеличением доступной информации.
Основные выводы
В этой статье мы разобрали концепции, связанные с ИИ. Мы увидели различия между ИИ и машинным обучением, глубоким обучением и нейронными сетями.
Наша первоначальная аналогия по-прежнему актуальна: не следует рассматривать эти концепции как отдельные элементы, а скорее как матрешку, где ИИ является большой куклой, а машинное обучение, нейронные сети и глубокое обучение — это последующие меньшие куклы.
Другой вывод заключается в том, что важно развеять путаницу вокруг нейронных сетей и глубокого обучения, а также машинного обучения и глубокого обучения. Необходимо помнить, что глубокое обучение — это просто система нейронных сетей с более чем тремя слоями, и алгоритмы глубокого обучения фактически являются алгоритмами машинного обучения.
ИИ и его многочисленные подполе остаются актуальными, и чем быстрее мы адаптируемся к этим изменениям, тем быстрее сможем в полной мере использовать их возможности и применить их в мире ИТ и решений для обслуживания и прогнозной аналитики. Так что, пожалуйста, больше никаких страшилок. Специалисты по данным уже выяснили, что сценарии с Скайнетом, Терминаторами и апокалипсисом Матрицы не произойдут в ближайшее время!
Часто задаваемые вопросы
В чем разница между искусственным интеллектом, машинным обучением, глубоким обучением и нейронными сетями?
Машинное обучение — это подполе искусственного интеллекта. Глубокое обучение — это подполе машинного обучения, а нейронные сети составляют основу алгоритмов глубокого обучения. Количество слоев узлов, или глубина, нейронных сетей отличает одну нейронную сеть от алгоритма глубокого обучения, который должен иметь более трех слоев.
Является ли ИИ тем же самым, что и нейронные сети?
Нет, не является. Это широко распространенное недоразумение, поскольку основное отличие между ИИ и нейронными сетями заключается в том, что ИИ или искусственный интеллект — это целая область компьютерных наук, которая изучает и создает интеллектуальные машины, обладающие своим интеллектом. В то время как нейронная сеть относится к системе искусственных узлов, которые составляют нейронные сети, отчасти вдохновленные мозгом животных.
Являются ли ИИ и глубокое обучение одним и тем же?
Нет, не являются. Глубокое обучение — это подмножество машинного обучения. Обычно, когда люди используют термин глубокое обучение, они имеют в виду глубокие искусственные нейронные сети.
Глубокие искусственные нейронные сети — это набор алгоритмов, которые установили новые рекорды точности для многих значительных задач, таких как распознавание изображений, распознавание звука, системы рекомендаций, обработка естественного языка и т.д.
Являются ли машинное обучение и ИИ одним и тем же?
Нет, не являются. Искусственный интеллект — это область компьютерных наук, которая исследует методы предоставления машинам возможности выполнять задачи, требующие человеческого интеллекта.
Машинное обучение — это техника ИИ, которая предоставляет компьютерам доступ к огромным наборам данных и обучает их учиться на этих данных. Программное обеспечение машинного обучения находит паттерны в существующих данных и применяет эти паттерны к новым данным, чтобы принимать умные решения.