Искусственный интеллект

Вчера вечером я впервые после детства взяла в руки рассказ «Я, робот» Эндо Биндера, опубликованный в январе 1939 года в журнале Amazing Stories.Именно Эндо Биндера (псевдоним братьев Эрла и Отто Биндеров) — а не Айзека Азимова. Это тот самый рассказ, чьё название Азимов «позаимствовал» одиннадцать лет спустя для своего знаменитого сборника 1950 года, причём сам Азимов протестовал против этого решения издателя, понимая, что название уже занято. А фильм 2004 года с Уиллом Смитом сняли по мотивам азимовского цикла о Трёх законах роботехники, так что связь с оригинальным рассказом Биндера только в названии.

Когда искусственный интеллект только‑только пришёл в нашу компанию, я почувствовал себя стариком не потому, что не знал как им пользоваться, а потому, что поймал себя на мысли: «Это всё фигня и долго этот хайп не продержится». Наверное таким же образом мыслили люди когда на смену лошадям пришли автомобили. Увы, увольнения случились быстро для тех, кто решил пойти по пути саботажа.

Я решил дать ИИ ещё один шанс. И через пару месяцев стало совершенно очевидно, что никуда искусственный интеллект не денется. Он не забирает работу, он меняет наше мышление. Главное же, что я понял — проблема не в технологиях. Главная проблема в корпоративной культуре отрицания ИИ.

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

Подобные тексты прекрасно льстят читателю, подтверждают его опыт, поддерживают иллюзию стабильности и позволяют чувствовать себя последним оплотом «чистого инженерного разума». Тем временем, пока мы спорим, существует ли ИИ, — он уже работает на тех, кто перестал спорить.

Сегодня я расскажу как пережил этот переход и что понял о людях, которые против ИИ. Если вам кажется, что ИИ — это хайп, то просто прочтите дальше.

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI, для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит.

Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции.

Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль.

Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости.

Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.

В череде серых офисных будней возникла насущная проблема. Есть сканы договоров, содержащие адреса пунктов (заправок) в табличной форме. Необходимо занести названия и адреса в базу, добавив геоданные. Можно сделать вручную, но это не наш метод. На дворе XXI век, автоматизация, да и простую лень никто не отменял. Бесплатные OCR распознаватели справляются плохо, особенно с таблицами, платные — не пробовал, жаба  бухгалтер не позволяет. Что же делать? И тут Qwen спешит на помощь! Скормил лист — вроде неплохо, вот оно счастье! Ан нет, опять «эмпирический опыт». Давайте посмотрим, что получилось, и с какими «когнитивными искажениями» пришлось столкнуться.

Часто ИИ-агенты не справляются даже с самыми простыми прикладными задачами: не могут забронировать отель на нужную дату или сделать коммит в нужную ветку в гите. В чем же дело и почему столь умные системы не работают там, где человеу понадобится всего пара минут?

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

В этом обзоре мы разберём, как агенты учатся думать над задачами и почему будущее ИИ лежит в умении строить правильную структуру размышлений.

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

Для AI-инженеров это системная проблема. Возьмём автоматизацию документооборота: нужно классифицировать договоры, извлекать реквизиты, проверять стандарты. Но модель работает как лотерея — результат не поддаётся логике или меняется при повторном запуске с одинаковыми данными. Как встроить такой результат в бизнес-процесс?

Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Его активно продвигает Ринат Абдуллин в материалах по работе с LLM. Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы. Это не панацея, но SGR серьёзно снижает количество ошибок, делает процесс прозрачнее, а также позволяет тестировать отдельные компоненты рассуждений.

Собрал production ML-сервер на двух RTX 2060 из хлама за ₽0. PyTorch + CUDA 11.8 + Stable Diffusion генерируют 512x512 за 38 секунд. YOLOv8 работает параллельно на второй GPU. Вот полный гайд: от BIOS настроек до первого теста. Никакого облака, только локальное железо.

Сегодня анализ “что если” превращается из экселевской игрушки в реальный управленческий инструмент, который можно автоматизировать.

В этой статье мы заглянем в прошлое what-if, сравним с настоящим и попробуем представить, каким он станет в ближайшем будущем.

Сейчас подобный анализ в большинстве компаний – это огромный ручной труд и Excel. Мнение, что вопрос решит интеграция ИИ – всего лишь иллюзия, которая исчезает, когда начинаешь работать с большими выборками данных, хранилищами, с крупными справочниками на сотни и тысячи позиций. И, самое главное, – когда начинаешь считать.

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

В предыдущей части мы начали рассказывать вам, как прошёл бизнес-день форума GIS DAYS. Сегодня мы завершим обзор и представим не менее интересные выступления, прошедшие 3 октября в московском кинотеатре «Октябрь». 

В 2022 году случился «нейросетевой бум» – генеративные модели вроде Midjourney вышли из лабораторий и стали доступны широкому кругу людей. Уже несколько лет нейросети являются одной из самых популярных тем для обсуждения в арт-сообществе, вызывая волну споров, страхов и мифов.

В этой статье я хочу разобраться во всем этом и разложить по полочкам – отделить мифы от реальности, обсудить популярные аргументы сторонников ИИ, например, сравнение с фотографией, обсудить возможность охраны промпта авторским правом, а также проанализировать ситуацию с обучением моделей и «добросовестным использованием».

Я старалась углубиться в проблему и разобрать позиции всех сторон, чтобы статья вышла объективной насколько это возможно ^^

Создать полностью автоматический Telegram-канал, который не просто парсит новости, а анализирует их с точки зрения практической пользы для малого и среднего бизнеса (МСБ). Наш AI-ассистент будет отсеивать "инфошум" и генерировать ежедневную сводку с конкретными идеями, инструментами и инфоповодами.

Инструменты:

Привет, Хабр! Меня зовут Настя Голубничая, я деврел в МТС Web Services, а еще в этом году лидирую трек «Программирование роботов» в МТС True Tech Champ. Полуфинал продлится до понедельника, сейчас участники удаленно подключаются к реальным роботам и проходят лабиринты. Каждую неделю мы проводим для них встречи с экспертами, отвечаем на вопросы, помогаем разобраться в управлении машинами — и в целом всегда держимся на связи. Кажется, нам удалось провести работу над ошибками прошлого года и на этот раз мы предусмотрели все. Или все-таки нет?

Вот именно из-за последнего вопроса мне не нужны никакие страшилки, чтобы не суметь ночью заснуть. Достаточно представить, что одно из опасений осуществляется, — и мы с командой разработки будем до утра генерить идеи, как это все пофиксить и какую соломку (и где именно) подстелить. К счастью, сейчас все боли уже закрыты, но тревога в памяти еще жива. И сегодня, раз уж повод такой подвернулся, я хочу рассказать, какие страхи мучили нашу команду накануне третьего сезона True Tech Champ и как мы боролись с таинственным ужасом и тенями прошлого. Итак, в черном-черном городе черной-черной ночью мы готовили чемпионат…

Краткий обзор двух десятков AI-инструментов, которые можно использовать для написания кода (a.k.a вайб-кодинга).

Мои курсы: Разработка LLM с нуля | Алгоритмы Машинного обучения с нуля

Салют! Я Дима Юдин, технический лидер по развитию искусственного интеллекта. Знаете вот эти леденящие душу разговоры на кухне у кулера о сверхразумной машине и пророчестве Илона Маска: «AGI будет уже через пару лет, и всем хана»? 

Лично мне ближе Ян ЛеКун, который говорит, что «в ближайшие годы AGI не будет». Собственно, статья как раз о том, почему прогнозы Илона, на мой взгляд, похожи на трейлеры к фантастике, а ЛеКуна — на голос разума в шумном баре. Поделюсь мнением, к чему на самом деле стоит готовиться разработчикам, дата-сайентистам, ML-инженерам, CEO и другим любителям LLM.

Глупо отрицать, что нейросети ускорили работу профессионалов.

Дизайнеры рисуют картинки за 5-10 минут вместо 2-х часов, редакторы за день собирают воронку постов, а благодаря вайбкодингу непрофессиональные разработчики кое-как, но могут собрать прототип будущего продукта.

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

LLM встраивают в продакшн-системы, но подходят к ним как к обычным библиотекам — подключил API и забыл. Проблема в том, что языковая модель выполняет инструкции из пользовательского ввода, генерирует код, обращается к базам данных. Если не учитывать специфику этих систем, можно получить утечку данных или компрометацию всего приложения. OWASP выделил десять критических уязвимостей в LLM-приложениях — разбираем каждую с примерами атак и способами защиты.

Разрабатывая AI-консультантов и ассистентов на базе RAG-архитектуры, работающих с корпоративными базами знаний на русском языке, мы столкнулись с вопросом: какие открытые эмбеддинг-модели дают лучший баланс качества семантического поиска на русском и скорости работы. Особенно это актуально, когда запросы и документы русскоязычные, но внутри часто попадаются фрагменты кода/SQL и англоязычной терминологии.

Мы прогнали 9 open-source эмбеддинг-моделей через несколько тестов, включающих проверки:

AI‑поиск по патентам в Perplexity: смысл вместо ключевых слов. Оценка патентного поверенного: применимость, ограничения, риски.

Автор: Шерстнев Павел

Что если модель могла бы проектировать саму себя? Подбирать архитектуру, параметры, операторы — без эксперта, без ручного тюнинга и десятков итераций? Эволюционные алгоритмы позволяют это сделать. Я собрал их в рабочую технологию — Thefittest — open-source проект, где эволюция используется для построения и оптимизации моделей машинного обучения.