Если вы когда-нибудь разрабатывали мессенджер, то наверняка сталкивались с задачей выбора фотографий и видео для отправки. На первый взгляд кажется, что Apple предоставляет всё необходимое: UIImagePickerController, PHPickerViewController. Но стоит только копнуть чуть глубже, и оказывается, что стандартные компоненты не покрывают и половины того, что нужно в реальном продукте.
Как машины могут учиться так же эффективно, как люди и животные? Как машины могут научиться рассуждать и планировать? Как машины могут изучать представления восприятий и планов действий на нескольких уровнях абстракции, что позволит им рассуждать, предсказывать и планировать на различных временных горизонтах? В этой позиционной статье предлагается архитектура и парадигмы обучения для построения автономных интеллектуальных агентов. Она объединяет такие концепции, как конфигурируемая предсказательная модель мира, поведение, движимое внутренней мотивацией, и иерархические архитектуры совместного вложения, обучаемые с помощью самоконтролируемого обучения.
Этот документ не является технической или научной статьей в традиционном смысле, а представляет собой позиционную работу, выражающую мое видение пути к интеллектуальным машинам, которые учатся больше похожим на животных и людей образом, способны рассуждать и планировать, и чье поведение определяется внутренними целями, а не жестко запрограммированными инструкциями, внешним контролем или внешними вознаграждениями. Многие идеи, описанные в этой статье (почти все из них), были сформулированы многими авторами в различных контекстах и в различной форме. Настоящая работа не претендует на приоритет в какой-либо из них, но представляет собой предложение о том, как собрать их в единое целое. В частности, в работе выявляются предстоящие трудности. Также перечисляется ряд направлений, которые, вероятно, будут успешными или неуспешными.
Текст написан с минимальным использованием жаргона и с использованием минимальных предварительных математических знаний, чтобы быть понятным читателям с самым разным образованием, включая нейробиологию, когнитивистику и философию, а также машинное обучение, робототехнику и другие инженерные дисциплины. Я надеюсь, что этот материал поможет лучше понять контекст некоторых исследований в области ИИ, чья значимость иногда неочевидна.
В начале 2021 года я взялся написать игру для компьютера, которому тогда было уже 40 лет — речь о его благородии Commodore 64. Релиз игры Cab Hustle наконец состоялся осенью 2022 года, после того, как я в течение нескольких месяцев эпизодически добивался по ней некоторого прогресса. В начале 2023 года я также выпустил версию этой игры для ПК.
OpenAI 5 месяцев строили продукт без единой строчки ручного кода — миллион строк, 1500 PR, 7 инженеров. Разбираю их подход «harness engineering» и что из этого можно применить уже сейчас: как организовать AGENTS.md, почему скучные технологии побеждают, и зачем нужна архитектура с первого дня.
Сегодня ядром данной статьи будет MCP — как мост между бекендом‑оберткой с LLM и внешними источниками, но при этом я также затрону смежные темы, чтобы картина была полной и не требовалось дополнительно гуглить.
Я постараюсь не давать устоявшиеся термины в контексте MCP, а также в процессе буду пояснять некоторые «базовые» термины, которые все как бы понимают — но нередко нет, чтобы мы все улавливали один и тот же контекст статьи.
У меня никогда не было состояния «идей нет». Идей — хоть отбавляй. Проблема всегда была в другом: когда я сажусь и начинаю специально их придумывать, мозг часто выдаёт ровно то, что от него ожидают: безопасное, предсказуемое, «правильное». А вот когда я задаю себе вопрос, формулирую задачу и отпускаю, — идеи становятся заметно сильнее: неожиданнее, сложнее, ближе к тому, что цепляет игрока.
Со временем я перестал воспринимать это как мистику и начал относиться к креативности как к настройке режима работы мозга. Не «вдохновение пришло/не пришло», а «какой режим сейчас включён, и как его переключить».
С 1960-х годов в архивы по всему миру начали поступать на хранение цифровые документы. Изначально небольшая, их доля среди собраний возрастала каждое десятилетие. Цифровые фонды при этом бросают вызов одной из главных функций архива: сохранять поступившее в неизменном виде. Неизменяемость для цифрового документа означает смерть, ведь уже через несколько десятков лет может не найтись ни одной машины, которая способна его открыть.
О том, как архивисты и программисты десятилетиями искали выход из этой ситуации, и как цифра меняет основы архивного дела рассказывает германский архивист Кристиан Кайтель. С его разрешения (и благословения издательства) мы публикуем отрывок из его книги «Двенадцать путей в архив. Контуры открытого и прикладного архивоведения».
Keitel C. Zwölf Wege ins Archiv. Umrisse einer offenen und praktischen Archivwissenschaft. Stuttgart: Franz-Steiner-Verlag, 2018. S. 188-202. Перевел Никита Ломакин (телеграм-канал Архивный гик), редактировала Анастасия Тарасова.
ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится.
Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача.
Мне это надоело и я полез разбираться.
Cегодня редко встретишь разработчика, который хоть раз бы не слышал о Rust. После долгого хайпа и зародившегося мема RIIR (rewrite it in Rust — перепиши это на Rust) ажиотаж вокруг языка как будто бы поутих. Но оказалось, все и вправду по‑тихому переписывается на Rust (если мой дебют не утонет в минусах, постараюсь написать статью‑исследование на тему, где уже Rust надежно поселился в системе).
Первое, что меня впечатлило — это статья, что вся инфраструктура Cursor написана на Rust в целях экстремальной производительности, и язык с этой задачей, как видно, прекрасно справляется. Второе, что и сподвигло не только читать о Rust, но и начать на нем писать, — это, конечно же, дефицит комлектующих. «640 КБ на самом деле хватит всем» и интерес пал на братьев наших меньших — микроконтроллеров. Вот где действительно можно прочувствовать всю необходимость оптимизации.
Конечно, знакомство с Rust, как и у всех, началось с классики — Rust book для новичков и Embedded Rust для желающих окунуться в разработку встроенных систем. В Rust Book новичкам предлагается написать простую программу Guessing Game — приложение, которое загадывает число, а «игрок» должен попытаться его угадать.
Но просто читать не так интересно как набивать свои собственные шишки, поэтому, вооружившись книгами, документацией, все еще живым StackOverflow и Gemini в качестве ментора, я решила объединить эти два мира и сделать Guessing Game на STM32.
Далее хочу предложить небольшой гайд (или просто объяснение кода) из того, в чем удалось разобраться.
Продолжаю серию статей про вайб кодинг для чайников (это я). Сегодня про главную боль: почему всё, что генерирует ИИ в плане веб-дизайна, выглядит одинаково пластиково, и что с этим делать на практике.
Хотелось бы свалить на конкретную модель и сказать - "надо просто выбрать вот эту и всё будет тип топ". Но на самом деле - это проблема подхода: по умолчанию ИИ пишет и оптимизирует код подходом "работает и не ломается", а не "выглядит как лучшие примеры с Awwwards". У него нет контекста вашего бренда, нет визуального фидбека на результат, нет источника вдохновения. Он берёт самый частотный паттерн из обучающей выборки, и вы получаете среднее арифметическое всех шаблонов интернета (стоит признать - иногда и так нормально). Давайте это починим в этой статье.
Синхронизация атрибутов элемента с DOM-свойствами
Очевидно, что нашему компоненту потребуются атрибуты, через которые пользователь сможет контролировать его поведение. Наш компонент должен вести себя как стандартный элемент ввода типа «input», поэтому обязательно должен поддерживать такие атрибуты как disabled и required – и это самый минимум. Поэтому важно разобраться (ну или вспомнить) что такое «content vs IDL attributes», и как с этим работать.
Документация по веб-компонентам мало говорит об атрибутах, разве что рекомендует использовать attributeChangedCallback() для наблюдения за ними, но этого недостаточно. Хотя это полезное API, нам оно не подходит, потому что оно уведомляет нас о уже совершенном действии (изменении атрибута), а нам нужно контролировать этот процесс, то есть – синхронизировать атрибуты и свойства с нормализацией значений.
Так как наш компонент наследует базовый класс HTMLElement, а в нем уже реализовано большое количество разных методов, то мы можем переопределить некоторые из них чтобы получить нужный нам результат. Для начала определим наши свойства в виде пар get/set и значения в приватном поле:
Краткий итог нашего изучения рынка и создания собственного бота (почему это так - читайте ниже):
Промпт-бот (500 ₽ фриланс + 50 000 ₽/месяц API):
Используйте, если нужно простое FAQ-покрытие, вся база знаний умещается в короткий промпт, нет регуляторного риска и вы понимаете, что принимаете риск галлюцинаций и нарушений ограничений. Хорошо для демонстрации возможностей. Не подходит для финансовых услуг, медицины, юридических вопросов или любой области, где неверный ответ бота имеет последствия.
SaaS-платформа (3 000–100 000+ ₽/месяц):
Используйте, если главным образом нужно FAQ-отклонение и маршрутизация обращений, каталог продуктов стабилен и прост, есть команда поддержки, которая хочет единый inbox, и вы хотите запуститься за несколько дней. Aimylogic и BotHelp достаточно хороши для своего предназначения. Российские платформы решают вопрос 152-ФЗ лучше западных аналогов.
Open-source-фреймворк (Rasa/Botpress, $0 ПО + инфра + программисты):
Rasa даёт полный контроль с локальным NLU и управлением диалогом. Требует Python-инженера и реальных обучающих данных. Корпоративное лицензирование начинается от $35 000/год. Подходит для ML-тяжёлых сценариев, где нужен полный контроль. Требует постоянной поддержки, которую SaaS берёт на себя.
Кастомный гибрид (инвестиции в код + ~5 000 ₽/месяц API):
Используйте, если нужны управляемые многошаговые квалификационные потоки, данные о продуктах синхронизированы с существующей системой, есть требования к локализации данных или соответствию 152-ФЗ, нестандартная интеграция с каналами или предсказуемость затрат на долгий срок. Не проект выходного дня, но при масштабировании экономика очевидна. По данным рынка, полная разработка «под ключ» в России стоит 70 000–1 000 000 ₽ единоразово (медиана 227 000 ₽ по исследованию Aimylogic).
Вообще, я большой любитель экзотических гаджетов и разной диковинки. Порой мониторю барахолки в поисках чего-то такого, что не продавалось в условной «Евросети», а если гаджет попадается нерабочий, то стараюсь его восстановить. Особый кайф мне приносит ремонт материнских плат — объём дофамина от чувства того, что ты только что восстановил устройство, на котором поставили крест более 10 лет назад, просто невероятный!
Недавно мне в руки попал уникальный смартфон-игровая консоль JXD S5800, который при внешней целостности не подавал никаких признаков жизни. После короткой диагностики виновник нашелся быстро. В этой статье расскажу не только о ремонте и о том, причем здесь Samsung, но и детально разберу аппаратную платформу типичного смартфона тех лет. Если интересно — жду под катом.
🏆 1 место на хакатоне без работающего кода? Легко!
Мы заняли 3 место с рабочим сервисом. Победители показали картинки и получили премию Мэра. Мы проверили их GitHub: там пусто.
Внутри расследование:
Ссылки на код победителей (alert() вместо API).
Разбор метрик (SMAPE 79%).
Как связи решают всё.
Читайте, как выигрывают не технологии, а подрядчики. 👇
Всем привет! Я пытаюсь реализовать свою систему анализа металлов и сплавов. Занимаюсь своим проектом уже год. В составе системы уже около 15 модулей. И хочу представить один из них. Если кому-то интересно или есть изображения, которые нужно измерить, верифицировать с другими системами я только - за.
Немного теории из мира металловедения, который чем-то схож с миром биологии. Главное различие мира металлов, пластиков и других материалов, что это неживая материя.
Определение чугуна
Чугун представляет собой сплав железа с углеродом, где содержание углерода превышает 2,14% (обычно от 2,5% до 4,5%). Благодаря своей жидкотекучести, малой усадке и относительно низкой стоимости, чугун является одним из основных конструкционных материалов в машиностроении, энергетике и строительстве.
При анализе чугуны разделяют по состоянию углерода и форме графитовых включений, что определяет их физико-механические свойства:
В этой статье мы рассмотрим создание микросервиса обработки изображений на golang с использованием технологии gRPC. Цель статьи - показать как может выглядеть такой сервис и что он может в себя включать.
Пошаговое руководство по развёртыванию блога с нуля: Strapi CMS (админка и API) и Nuxt.js (фронтенд) на VPS Ubuntu. В итоге — работающий блог за Nginx с возможностью включить SSL по отдельной инструкции.
Я не разработчик, но теперь у меня есть своё приложение в App Store, которое помогло мне больше ходить и в прошлом месяце я прошёл 500 000 шагов. В этой статье рассказываю как я к этому пришёл и какие инструменты помогли ускорить путь.
Почему ваша Java-система буксует там, где должна летать? Мы привыкли доверять магии JVM, но в мире Java 21 и Native Image правила игры изменились. От микро-оптимизаций байт-кода до радикальной смены парадигмы с Scoped Values – разбираем 11 “золотых правил”, которые заставят JIT петь, а ваш бинарник – стартовать за миллисекунды. Никакой “воды”, только хардкор, регистры процессора и “голоса” компиляторов внутри вашего кода.
Работая с кодом, я не раз ловил азарт: а как этот метод можно ускорить ещё? Какую гайку подкрутить, чтобы JVM не просто работала, а буквально летела? Что изменить в архитектуре, чтобы Native Image стал ещё компактнее, а холодный старт – ещё быстрее?
Испытав этот азарт оптимизации не раз, я хочу поделиться им с вами. Я собрал квинтэссенцию своего опыта в конкретный чек-лист.
Это не просто советы по стилю кода. Это “10+1 Золотых правил оптимизации Java 21+”.
Это те рычаги, которые заставляют JIT-компилятор петь, а GraalVM – генерировать бинарники с хирургической точностью.
Приготовьтесь! Мы начинаем оптимизировать!
REST API на Symfony писать удобно, но есть одна скучная особенность: контроллеры быстро начинают обрастать повторяющимся кодом. Парсинг запроса, валидация, однотипная JSON‑обёртка, try/catch с преобразованием исключений в HTTP‑ответы. Всё это несложно, но со временем размазывается по десяткам эндпоинтов и отвлекает от основной задачи.
Ниже - способ привести все в порядок с помощью небольшого бандла, который я использую в своих проектах.
