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

Октябрь отметился интересным сдвигом: компании перестали фокусироваться на том, насколько умной может быть модель, и переключились на вопрос, что она может делать самостоятельно. Computer Use от Google, SDK и другие агентные инструменты от OpenAI и Anthropic — индустрия наконец решила, что пора переходить от умных ответов к автономным действиям. Не обошлось и без новой порции корпоративных драм, куда теперь без них.

А ещё вышли Sora 2 и Veo 3.1, две новые версии Claude 4.5, Мира Мурати показала первые продукты своего стартапа, а Китай продолжил выпускать опенсорс быстрее, чем все остальные вместе взятые. Но не будем вываливать всё сразу. Начнем с релизов, а драмы и открытия традиционно оставим на десерт.

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

Коллектив ученых из Московского физико-технического института предложил два новых метода для решения этой задачи, основанных на анализе функции правдоподобия с использованием техники бутстрэпа.  Работа опубликована в журнале Computational Mathematics and Mathematical Physics.

Самые интересные новости финансов и технологий в России и мире за неделю: российским операторам запретили рассылать смс-коды для Telegram, Аяза Шабутдинова посадили на 7 лет, первый штраф за рекламу в Инстаграме, рекордная капитализация Nvidia на $5 трлн, реорганизация OpenAI в коммерческую компанию, а также предзаказ домашнего робота Neo за $20к.

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

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

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

На сдачу от пятерочки покупаем ПК на Ryzen AI 9 HX 370 c ОЗУ от 64Гб, устанавливаем LM Studio, скачиваем модель qwen3-coder-30b, в mcp.json указываем путь до нашего mcp-server и вуаля: можно попросить ИИ поискать информацию в интернете или среди pdf, docx, xlsx, pptx файлов в локальной папке.
А как написать этот инструмент развязывающий руки ИИ, мы сейчас с вами и узнаем...

Само слово «дипфейк» (deepfake) впервые появилось в 2017 году на платформе Reddit. Однако технологическая основа была заложена еще в 2014 году с изобретением генеративно-состязательных сетей (GANs) Яном Гудфеллоу. 

Сначала дипфейки использовались для создания юмористического контента, но их потенциал для мошенничества, дезинформации и кибератак запустил ответную волну инноваций. Началась настоящая гонка по разработке технологий распознавания дипфейков. Об этом и не только — в нашем материале.

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

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

Если просто скопировать-вставить ответ в телелегу, то потеряется разметка, картинки и длинное сообщение разобьется на части.

Решение: я беру любой markdown => pdf конвертер, например

https://youscriptor.com/markdown-converter

Markdown - это родной формат ChatGpt/DeepSeek, под ответом я нажимаю кнопочку копировать.

Привет, я Дима. Больше пяти лет я проработал продактом в инфлюенс-техе — той самой сфере, где бренды охотятся за блогерами, договариваются о нативках, а потом недели тратят на согласование сторис с логотипом под углом 45°.

Когда я начинал, всё строилось на людях. Мы вручную искали микрокреаторов в соц.сетях, писали им в директ, собирали Excel-таблицы с охватами. UGC (user generated content) был честным, сырым, живым. Бренды хотели «человечности».

Потом пришли платформы автоматизации — Influence, HypeFactory, LabelUp. Они научились находить блогеров по метрикам: ER, гео, возраст, тональность. Контент стал потоковым. Кампании — предсказуемыми. Всё шло к тому, чтобы заменить хаос системой. Но человеческий фактор оставался: блогеры срывали сроки, писали тексты с ошибками, теряли файл на телефоне.

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

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

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

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

В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.

Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.

Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».

Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.

Привет! Я — Лёша, принципал дизайнер, решаю бизнес-задачи с помощью дизайна уже больше 15-ти лет. Это моя первая статья из небольшой, но насыщенной серии, и она полностью посвящена дизайн-процессам и взрослому, результативному подходу к работе. Я постараюсь рассказать все очень кратко, насколько это возможно чтобы не потерять суть, но емко. Сделаю это так, чтобы все процессы стали понятны даже новичку.

Думаю большинство читателей уже знакомы с известной системой «Double diamond» (двойной ромб), разработанной Британским Советом по дизайну еще в далеком 2005-м году. Называть его в русском варианте «Двойной алмаз» некорректно. Алмаз многогранен, а суть подхода именно в двух, при необходимости бесконечно повторяющихся этапах дивергенции и конвергенции внутри каждого ромба.

Если говорить простыми словами, то суть заключается в том, что сначала мы расширяем наш поиск во все возможные стороны, и только потом приступаем к поиску решений, объединяя все полученные знания, при этом сужая фокус внимания. Мы делаем какие-то выводы из полученных данных и оставляем только самое важное из того что мы смогли выяснить. У каждого ромба в этой системе есть два этапа (расширение и последующее объединение):

Пятьдесят лет он создавал искусственный интеллект. Теперь говорит, что машины могут уничтожить человечество. Безработица, кибератаки, подтасовка выборов, вирусы, роботы-убийцы — далеко не полный список, что нас ждет. Что делать людям в таком мире? Учиться на сантехника. Пока... пока не появятся гуманоиды.

Всё больше выходит больших MoE моделей с малым числом активных параметров. У MoE совсем другой сценарий нагрузки и использования ресурсов нежели у Dense моделей, достаточно немного VRAM. Большие MoE модели устроит 1 GPU и много обычной RAM. О том, как устроены MoE и как ускорить работу одним параметром не меняя железо.

Сегодня многие AI-сервисы требуют наличия иностранной банковской карты или работы через зарубежные платёжные системы. Это создаёт сложности для разработчиков из стран с региональными ограничениями.

В этой статье я покажу, как подключить нейросеть (инференс GPT 5 и LLaMA) в n8n без использования иностранной карты, и разберу работу с ней на простом примере.

Вчера вечером я впервые после детства взяла в руки рассказ «Я, робот» Эндо Биндера, опубликованный в январе 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 спешит на помощь! Скормил лист — вроде неплохо, вот оно счастье! Ан нет, опять «эмпирический опыт». Давайте посмотрим, что получилось, и с какими «когнитивными искажениями» пришлось столкнуться.

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

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

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