Когда мы слышим искусственный интеллект, в памяти всплывают не учебники, а сцены из фантастики. В книгах и фильмах ИИ всегда был больше, чем просто программа. В «2001: Космическая одиссея» HAL 9000 рассуждал и принимал решения, Терминатор показал пугающий образ восстания машин, у Азимова роботы жили по трём законам робототехники и спорили с людьми о морали.

Долгое время это оставалось лишь мечтой и художественным образом. Но начиная с 1950-х исследователи на полном серьёзе пытались воплотить эти фантазии в жизнь. И путь оказался не прямой, а похожий на синусоиду: взлёты, падения, зимы и новые возрождения.

Амбиции и вера в будущее 1950-е

1950-е годы — момент рождения искусственного интеллекта как дисциплины. Алан Тьюринг предлагает простой, но мощный критерий: если в диалоге машина неотличима от человека, то она обладает интеллектом.

В 1956 году проходит Дартмутская конференция. Джон Маккарти вводит термин Artificial Intelligence, а Аллен Ньюэлл и Герберт Саймон демонстрируют программу, доказывающую математические теоремы. Впервые появляется ощущение, что создание разумных машин — не вопрос фантастики, а инженерная задача ближайших десятилетий.

Первые результаты и рост оптимизма 1960-е

1960-е показывают: компьютеры могут больше, чем от них ожидали. Программы решают уравнения, строят доказательства, разговаривают на английском. ELIZA, первый чат-бот, симулирует психотерапевта, а робот Shakey умеет воспринимать пространство и планировать действия.

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

Первая зима 1970-х

Реальность быстро возвращает исследователей к земле. В начале 1970-х становится ясно — задачи развития искусственного интеллекта оказались куда сложнее, чем казалось. Великобритания после жёсткого отчёта Лайтхилла сворачивает большинство проектов, в США также падает уровень поддержки. Нейросети объявлены тупиковой ветвью — слишком ограниченные для реального применения. Наступает первая зима ИИ.

Практическое направление: экспертные системы

Но в тени разочарования рождается другое направление. Экспертные системы — это не универсальный интеллект, а формализация знаний узких специалистов. DENDRAL помогает химикам анализировать молекулы, MYCIN диагностирует инфекции крови, XCON экономит корпорациям десятки миллионов долларов, автоматически конфигурируя сложное оборудование. В 1980-е бизнес впервые ощущает реальную ценность ИИ. Возникает миллиардный рынок экспертных систем.

Вторая зима 1980-х

Проблема в том, что экспертные системы плохо масштабировались. Каждую базу знаний приходилось наполнять и обновлять вручную. Стоимость внедрения росла, а результат не всегда соответствовал ожиданиям. К концу 1980-х рынок рушится. DARPA сворачивает программы, сотни компаний закрываются. Вторая зима ИИ подрывает доверие к технологии.

Возвращение интереса — начало 2000-х

1990-е и начало 2000-х дают новые инструменты: байесовские сети, статистические методы, первые шаги в области больших данных. В 1997 году IBM Deep Blue обыгрывает Гарри Каспарова. Это важный символ: пусть узко, но компьютер способен победить лучшего человека.

2000-е закрепляют тренд. ИИ становится встроенной частью интернет-сервисов: фильтры спама, поисковые алгоритмы, рекомендательные системы. DARPA проводит первые соревнования для беспилотных автомобилей. В 2011 году IBM Watson выигрывает шоу Jeopardy!, а в iPhone появляется Siri.

Прорыв глубокого обучения 2012

2012 год становится поворотным — сверточные нейросети вырываются вперёд на конкурсе ImageNet. За этим следуют победы AlphaGo над чемпионом мира в го (2016), которые ознаменовали собой прорыв в области искусственного интеллекта, доказав, что системы ИИ способны решать сложные задачи в областях, где человеческая интуиция считалась преобладающей.

Так же в этом году был взрывной рост качества распознавания речи и машинного перевода.

2017 год приносит архитектуру Transformer — основу для будущих языковых моделей. ИИ начинает переходить от узких задач к более универсальным возможностям.

Эра генеративного ИИ

2020-е открывает GPT-3 с 175 млрд параметров. В 2022 году выходит ChatGPT — и за два месяца им пользуются уже 100 млн человек. Параллельно взлетают DALL-E, Stable Diffusion, MidJourney. Машины начинают не только классифицировать, но и создавать — текст, изображение, музыку.

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

История ИИ — это американские горки. Хайп → зима → хайп → зима → и снова хайп. Но с каждым циклом технологии оставляли после себя всё больше практической пользы. Экспертные системы стали первой формой настоящего прикладного ИИ. А сейчас мы живём в эпоху, когда ИИ — это рабочий инструмент, который жрёт одни профессии и создаёт другие.

Поэтому мы будем использовать...

PropertyDescriptor из пакета java.beans позволяет получить метод set для поля и безопасно вызывать его, не ломая рефлексию.

Почему лучше использовать PropertyDescriptor?

Не нарушает инкапсуляцию использует публичный сеттер вместо вмешательства в приватные поля.

Совместимо с модульной системой Java – не требует setAccessible(true), который ограничен в новых версиях.

Безопасно для будущих обновлений – код продолжит работать даже после изменений в рефлексии.

1. Жесткая привязка к Jakarta EE/JSR-250: Эти аннотации являются частью пакета jakarta.annotation , что связывает ваш код с конкретным API. Это не всегда плохо, но может ограничить гибкость, если вы хотите использовать другие фреймворки или стратегии управления жизненным циклом.
2. Ограниченная гибкость: Эти аннотации работают только для методов и не предоставляют возможности для обработки более сложных сценариев, таких как условная инициализация или асинхронная настройка.
3. Сложности при тестировании: Методы, помеченные @PostConstruct и @PreDestroy , сложнее мокать или тестировать изолированно, особенно при работе со сложными зависимостями.
4. Современные альтернативы: Spring Boot 3+ и экосистема Spring предлагают более мощные и гибкие способы управления жизненным циклом, что делает эти аннотации устаревшими.

Современные альтернативы в Spring Boot 3+

Вот несколько современных подходов, которые могут заменить @PostConstruct и @PreDestroy в ваших приложениях на Spring Boot:

Использование интерфейсов InitializingBean и DisposableBean

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

Плюсы:
- Нет зависимости от javax.annotation или jakarta.annotation.
- Прямая интеграция с управлением жизненным циклом Spring.

Минусы:
- Жестко связывает ваш бин с интерфейсами Spring.

Использование методов инициализации и уничтожения в @Bean

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

Плюсы:
- Отделяет методы жизненного цикла от класса бина.
- Подходит для работы со сторонними библиотеками, где нельзя изменить исходный код.

Минусы:
- Требует явной конфигурации в определении @Bean.

Использование SmartLifecycle для продвинутого управления жизненным циклом

Для более сложных сценариев, таких как поэтапный запуск или завершение работы, можно реализовать интерфейс SmartLifecycle.

Плюсы:
- Предоставляет детальный контроль над этапами запуска и завершения.
- Поддерживает упорядоченную инициализацию и завершение.

Минусы:
- Более сложен в реализации по сравнению с другими решениями.

Использование @EventListener для событий жизненного цикла контекста

Вы можете слушать события ContextRefreshedEvent и ContextClosedEvent для выполнения инициализации и очистки. А также @EventListener(ApplicationReadyEvent.class) или @EventListener(ApplicationPreparedEvent.class) для задач, которые необходимо запустить в момент старта приложения.

Плюсы:
- Отделяет логику жизненного цикла от самого бина.
- Подходит для глобальной инициализации и очистки.

Минусы:
- Применяется ко всему контексту, а не к отдельным бинам, то есть мы создаем @Component для отдельных задач - запуска инициализации БД, например.
- В случае, когда в приложении существует несколько контекстов, обработчик событий может реагировать на события из всех контекстов. Если для приложения важно реагировать только на события основного, родительского контекста, то события можно отфильтровать проверкой @EventListener(condition = "event.applicationContext.parent == null")

Какой подход выбрать?

Лучший подход зависит от вашего конкретного сценария:

- Для простой инициализации и очистки подойдут методы @Bean или InitializingBean|DisposableBean.
- Для продвинутого управления жизненным циклом используйте SmartLifecycle.
- Для логики, основанной на событиях жизненого цикла приложения выбирайте @EventListener