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

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

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

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

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

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 вышли из лабораторий и стали доступны широкому кругу людей. Уже несколько лет нейросети являются одной из самых популярных тем для обсуждения в арт-сообществе, вызывая волну споров, страхов и мифов.

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

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