Лёха ведет дневник

Представляю вашему вниманию Hub Defence!

Игра в жанре Tower Defence о том, как Валера Ковальский хаб развивал на протяжении 325 серий.

31 уровень разной сложности. В качестве уровней – дата-центры.

Ваша задача – удовлетворить потребности пользователей в инференсе. У каждого типа пользователей свои задачи и, как следствие, свои потребности в TTFT и объёмах GPU.

Персонажи игры:

Валера Ковальский – главный герой, который всеми силами пытается удержать хаб на плаву (иногда – буквально), а также поддерживает высокий SLI (если стабильность достигнет 0% – вы проиграете).

Павел Рыков aka Zloi – всегда готов помочь в работе над Хабом и вернуть к жизни вышедшие из строя стойки.

Алексей Жданов – делает такое количество повторений в жиме лёжа, что пользователи забывают, зачем пришли и просто любуются.

Глеб Кудрявцев – готов извлечь инвестиции в любом городе, чтобы подсобить вам деньгами на новые GPU, стойки и их развитие.

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

За эту же валюту можно трижды сбросить лимиты в реальном Хабе! Опция доступна для каждого игрока после привязки игрового процесса к аккаунту Хаба.

И, конечно же, в игре есть пасхалка. Если вы её найдёте – делайте скриншот. Присылайте его в комментарии под этим постом. Первый приславший получит месяц подписки на NeuralDeep!

В Hub Defence есть текстовый онбординг. Прочитайте его, пожалуйста, чтобы не упустить существующие механики. Без них играть может быть чуть сложнее задуманного. Если вдруг пропустили – всегда можно посмотреть гайд прямо с игрового поля.

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

Играть лучше всего на ПК или планшете. Мобильная версия тоже есть, хоть и гораздо менее удобная на мой взгляд. Это PWA-приложение, так что можно установить его себе на устройство.

В отдельном посте расскажу историю создания этого мини-проекта.

@kdoronin_blog

Дарим подписку на hub

Условия простые, напишите ваш кейс в комментариях под этим постом. Расскажите, как именно вы используете neuraldeep.ru.
До 10 сентября пришлите кейс, после 15 числа мы с Пашей, Артемом и Лешей на стриме выберем победителей.

Пришлите мне в личное сообщение вашу почту с хаба, дождитесь стрима и победители и получат на 1.5 месяца PRO-подписку или эквивалент на PAYG кошелек.

Все кейсы победителей будут опубликованы отдельным постом(максимум 10 победителей)
Так же самые крутые кейсы разберем на стриме!

Не забываем тут пройти капчу

https://t.me/neuraldeepchat

Первый выпуск начинается со спора самих ведущих

ИИ —начало конца творческих профессий
ИИ — начало новой эпохи творчества

Обсуждаем это вместе с художником Покрасом Лампасом и Денисом Димитровым, CTO Kandinsky и управляющим директором по исследованию данных Сбера. Начинаем с простого эксперимента: показываем изображения и видео и пытаемся определить, где работа человека, а где — результат генерации.

Даже эксперты, которые каждый день работают с такими технологиями, ошибались чаще, чем ожидали.

А ещё Покрас впервые рассказывает, как обучил модель на собственных буквах и проверил, сможет ли она воспроизвести его авторский почерк.

Эпизод уже ждёт на YouTube и в VK🔗

↗️ red_mad_robot

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

Начало истории можно почитать в этом посте

Все выложил на гитхаб - забирай, тестируй на себе

Сперва дисклеймер: там нет кода.
Вообще нет. Это папка с текстовыми файлами.

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

Сверху на этой папке лежит GTD - смысл, цели на три года, области жизни, проекты, следующие действия.

Снизу сидит ИИ-агент и все это ведет.

Почему агент, а не просто заметки?

Потому что система умирает не от нехватки инструментов.
Она умирает от того, что ее надо вести и постоянно держать в актуальном состоянии.
Разбирать инбокс.
Переносить сделанное.
Замечать проекты, которые тихо сдохли месяц назад, но все еще числятся живыми.

Это работа. Скучная. И она всегда проигрывает срочному.
Вот ее я и отдал агенту. Себе оставил решения.

Что он реально делает:

/gtd-inbox - гоняет каждый пункт по воронке: это вообще действие? одно или проект? может, делегировать? Приносит готовую рекомендацию, мне остается сказать «ок». Инбокс в ноль;

/gtd-morning - показывает, что горит, и помогает выбрать ОДИН фокус дня. Один. Не двенадцать, как мне хочется;

/gtd-evening - отмечает сделанное и синхронизирует статус везде: шаг в проекте, запись в лог, закрытое ожидание. Отдельно вылавливает галочки, которые я наотмечал с телефона не там, где надо (а я наотмечаю);

/gtd-review - раз в неделю сканирует систему на гниль: протухшие дедлайны, проекты без следующего шага, кого я забыл пнуть;

/gtd-alignment - раз в месяц сверяет, куда ушли часы, против того, что я называю целями. Цитирует мои же формулировки и спрашивает, почему приоритет №1 получил ноль внимания.

Сейчас в системе 10 областей, 50+ активных проектов, 100+ открытых действия, 300+ заметок.
И оно не разваливается - вот это для меня главный результат.

Агент не превращает тебя в другого человека.
Он убирает трение. Делать дела все равно надо самому

Так вот, выложил на гитхаб весь скелет - структуру, дашборд, все скиллы, конвенции и список грабель, чтобы ты свое время не тратил.

https://github.com/ZhdanovAlexey/obsidian-gtd-agent

Обезличено, MIT, делай что хочешь.

Разворачивается минут за десять: открыть папку в Обсидиане, поставить два плагина, запустить агента.

Свои цели придется вписать руками.

Не впишешь - месячная сверка будет поддакивать вместо разбора - You're absolutely right .. иф ю ноу вот ай мин.

Ставь 🐳, если тема откликается.

Расскажу про другие инструменты этой системы, которые упрощают мою жизнь.

@alexs_journal

Channel photo updated

Принял VibeCode эстафету Рината от Паши.

Попросил Claude Code проанализировать все репозитории на диске и GitHub. Результат на скриншоте, а тут — выводы.

Три этапа моего "программирования":

Этап 1: Руками
20 коммитов за полгода. Copy paste со StackOverflow.
Бот-напоминалка, который писался неделю.
Парсер CSV, от которого хотелось плакать

Этап 2: Cursor
319 коммитов. Ctrl+K изменил всё.
Забытые поделки, боты, интеграции.
То, что раньше занимало неделю теперь день-два

Этап 3: Claude Code
442 коммита меньше, чем за 5 месяцев.
От идеи до рабочего прототипа за 4 часа.

И вот что важно. Я не программист (когда-то в прошлой жизни лупил на 1С). И покодить мне удается только на выходных или в конце рабочего дня.

Раньше любая идея ... это, а давайте поставим в бэклог, через два спринта посмотрим.
Сейчас: открыл терминал, описал задачу, через 4 часа показываешь команде работающий прототип. Без единого тикета в Jira.

У каждого продакта есть блокнот/заметка/notion со списком было бы круто сделать.
Раньше это кладбище идей. Сейчас это роадмап на ближайший вечер.

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

Открой Cursor или Claude Code. Опиши что хочешь. Получи прототип и радуйся.

Дашборд на скриншоте, естественно, генерка)

Передаю эстафету: Владу, Тёме, Саше

@alexs_journal

Как я больше 1000 раз пожал штангу

Перед стартом я ради интереса спросил у Claude Opus реально ли пожать штангу в полвеса на 1000 повторений за один подход.
ИИ выдал, что это находится за пределами известных человеческих возможностей.

Что ж, Claude, подержи мой протеиновый коктейль.

Цифры с соревнований:

Номинация: 1/2 Народный жим (вес штанги = 50% веса тела).
Мои параметры: Масса тела 71.2 кг. Штанга - 37.5 кг.
Результат: 1010 повторений (Мировой рекорд. Федерация НАП)
Время в подходе: 57 минут с копейками (почти час под нагрузкой)

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

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

Респект тренеру Антону Старостину. Я хоть и не супер послушный подопечный, но у тебя получилось подвести меня к старту.

Горжусь другом Мишей (прошли с ним всю подготовку вместе) — для него это были первые соревнования, и он выложился именно так, как планировал. Дебют удался!

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

@alexs_journal

↗️ Мы захватили этот канал

Раньше канал назывался red_mad_dev.

Теперь это _rnd — публичный блог практики R&D red_mad_robot.

Это рабочая площадка для инженеров и ресёрчеров. Здесь будут наши мысли, эксперименты, короткие и длинные технические разборы, ссылки на научные статьи и git-репозитории.

Про что будем писать:
• какие гипотезы тестируем и какие результаты получаем
• какие архитектурные решения принимаем и почему
• где ошибаемся и что это меняет
• как исследования превращаются в прикладной AI
• что происходит в индустрии и что об этом думаем

Если вам интересны reasoning-архитектуры, RAG-системы, агентные пайплайны, LLM-инфраструктура и реальный продакшн AI — вы в правильном месте.

Поехали ⚡️

Open AI, Google и Anthropic тратят миллиарды долларов на закупку видеокарт, строят дата-центры размером с города и сжигают тераватты энергии, чтобы обучить модели нового поколения.

Всё ради того, чтобы я в Пт вечером закинул селфи и спросил:

«Слушай, а если я бабахну прическу средней длины, мне норм будет?»

Какая в итоге норм?

@alexs_journal

[Часть2] Как я строил AI-аналитика для данных о третичных продажах

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

Tools: как агент работает с данными
run_sql — основной инструмент

Принимает произвольный SELECT-запрос, прогоняет через guardrails (об этом ниже), выполняет в ClickHouse, возвращает результат в виде таблицы.
Если запрос упал с ошибкой — агент видит текст ошибки и может исправить SQL и попробовать снова.

get_reference_values — инструмент разведки данных.
Прежде чем строить сложный запрос, агент может спросить:
«Какие значения есть в столбце subcategory для category = 'Мясная гастрономия'?»

Технически tool делает

SELECT DISTINCT field 
FROM ai.sellout_sales 
WHERE ... 
ORDER BY field 
LIMIT 50 

и возвращает список значений.

Но вызвать его можно только для 20 разрешённых полей (whitelist: category, subcategory, group_name, brand, producer, client, region, city и другие справочные поля).
Это защита — нельзя разведать, например, конкретные store_addr или ean.

Зачем это нужно? Пример: пользователь спрашивает «продажи в Дикси по творогу».
Агент вызывает

get_reference_values(
     field='subcategory',
     filter_clause="category = 'Молочная гастрономия'"
)

видит в ответе Творожная группа (а не Творог), и строит SQL с правильным фильтром. Без этого шага LLM с высокой вероятностью напишет subcategory = 'Творог' и получит 0 строк.

Системный промпт: 300 строк контекста для LLM
Промпт агента — это не просто «ты аналитик, пиши SQL»
Это 300 строк структурированных инструкций, разбитых на блоки:

- Роль и workflow из 5 шагов:
классификация запроса → уточнение у пользователя → разведка данных → SQL-запросы → анализ и выводы.

Если пользователь написал «привет» вместо аналитического вопроса — агент вежливо объясняет возможности и предлагает 5 конкретных примеров запросов.

- Полная схема таблицы — все 53 поля с типами и семантикой.
Агент знает, что salesvalueVAT — это выручка с НДС (и что именно её нужно использовать, потому что salesvalue для ряда сетей равен нулю).
Знает, что reg_price_report содержит много нулей и для расчёта средней цены нужна формула средневзвешенной: sum(salesvalueVAT) / nullIf(sum(sales_weight_kg), 0).

- Справочники и маппинги — точные значения client по каждой сети с учётом регистра ('Пятёрочка' vs 'МАГНИТ' vs 'Ашан'),
маппинг пользовательских терминов на поля ("творог" → subcategory = 'Творожная группа'),
иерархии (chain -> client -> store_code_uni).

- Подсказки для сложных запросов — паттерны SQL для типовых аналитических задач: сегментация через ntile(),
тренды через lagInFrame(),
pivot-матрицы через условную агрегацию (sumIf/avgIf),
расчёт индексов цен YoY с CTE.
И явные предупреждения: linearRegression в ClickHouse не существует - не выдумывай.

По сути, промпт — это сжатая документация по данным и по паттернам ClickHouse SQL, которую аналитик-человек держит в голове после месяцев работы с этой базой.

SQL Guardrails: безопасность на уровне валидации

Давать LLM возможность писать произвольный SQL — мощно, но опасно. Каждый запрос проходит через validate_select_sql() до обращения к базе:

- Разрешён только SELECT или WITH ... SELECT.
- Запрещены множественные statements (защита от SELECT 1; DROP TABLE).
- Denylist опасных ключевых слов: INSERT, UPDATE, DELETE, DROP, ALTER, CREATE.
- Автоматическое добавление SETTINGS max_execution_time=45 — защита от тяжёлых запросов к 552 млн строк.
- Отдельный read-only пользователь ClickHouse (agent) с правами только на SELECT по ai.*.

Невалидный SQL блокируется, а агент получает сообщение SQL_VALIDATION_ERROR: ... с инструкцией исправить запрос.
Тот же механизм работает для SQL_EXECUTION_ERROR — если ClickHouse вернул ошибку (несуществующий столбец, синтаксическая ошибка), агент видит текст и пробует переписать запрос.

Если интересно — могу поделиться системным промптом к агенту.

@alexs_journal

[Часть1] Как я строил AI-аналитика для данных о третичных продажах

Проблема:
У крупного пищевого холдинга накоплена огромная база третичных продаж:
552 млн строк, 53 столбца, 21 месяц данных.

Это sellout из розничных сетей - «Пятёрочка», «МАГНИТ», «ДИКСИ», «ЛЕНТА» и ещё с десяток - с детализацией до конкретного магазина, SKU, цены, промо-активности, типа упаковки и даже признака «халяль»

Аналитики регулярно задают похожие, но каждый раз чуть отличающиеся вопросы:
«Покажи топ-30 варёно-копчёных колбас в Пятёрочке по Москве»,
«Какие творожные продукты растут в продажах?»,
«Где точки роста сырой мясной продукции в Тверской области?»,
«Сформируй матрицу индекса цен по сетям и категориям за год».

Есть ряд типовых задач: от простых top-N выборок до сегментации магазинов и выявления негативных трендов с их причинами.

Каждый такой запрос - это цикл:
понять контекст, написать SQL, проверить фильтры (где Пятёрочка с буквой ё, где МАГНИТ капсом, где Творожная группа вместо Творог), прогнать, оформить выводы.

Обычный пользователь (не познавший SQL кунг фу) не сможет самостоятельно сделать запрос и получить вменяемый результат.

Задача:
дать бизнес-пользователю инструмент, где он пишет вопрос на русском языке и получает готовый аналитический ответ с цифрами и выводами.

Ключевой инфраструктурный контекст:
Локальная модель gpt-oss-120b поднята на сервере у Валеры в подвале (да, это жирно для такой задачи, но для скорости решил на большой модельке, потом буду оптимизировать для работы на более мелкой)
Данные о продажах - коммерческая тайна, и отправлять 550 млн строк третичных продаж в облачные API категорически нельзя.
Вся цепочка: LLM, ClickHouse, Telegram-бот (для тестирования выбрал фронтом) живёт на одной площадке, ничего не уходит наружу.

С точки зрения кода это означает, что мы используем OpenAIChatCompletionsModel из OpenAI Agents SDK, но подключаем его к локальному эндпоинту через AsyncOpenAI(base_url=..., api_key=...)
SDK абстрагирует протокол - ему всё равно, что на другом конце не OpenAI, а наш собственный инференс-сервер.
Модель работает с temperature=0 для детерминированности аналитических ответов.

Почему не «один вызов LLM —> один SQL»
Первая архитектура была наивной: вопрос → LLM генерирует один SQL → выполняем → отдаём результат.
Быстро стало ясно, что это не работает на реальных задачах.

Проблема в данных.
53 столбца с неочевидной семантикой.
Пятиуровневая товарная иерархия: category -> subcategory -> group_name -> subgroup.
Пользователь скажет «творог», а в данных это subcategory = 'Творожная группа', не 'Творог'.
Скажет «в Пятёрочке», а в столбце client значение 'Пятёрочка' с буквой ё, не 'ПЯТЕРОЧКА'.
Скажет «варёные колбасы», это group_name, не subcategory и не category.
Один неправильный фильтр и запрос возвращает 0 строк, пользователь получает пустой ответ.

А есть и более сложные задачи: «Обозначь точки роста продаж сырой мясной продукции в Тверской области, исключая сезонность».

Тут нужно:

1. Сначала разведать, какие значения есть в данных — какие group_name внутри мясной продукции, что именно в данных соответствует Тверской области.
2. Построить основной запрос с агрегацией по месяцам.
3. Рассчитать тренд роста через lagInFrame() — потому что в ClickHouse нет linearRegression.
4. Отфильтровать сезонные всплески.

Один LLM-вызов с одним SQL этого не потянет.

Архитектура: Agent Loop на OpenAI Agents SDK
Ядро - Agent из OpenAI Agents SDK с agent loop и tool calling (можно и на SGR agent core сделать легко):

Telegram User
    │
    ▼
TelegramBotApp ─── typing indicator
    │
    ▼
AnalyticsAgentService
    │  Runner.run(agent, input, context, max_turns=25)
    ▼
Agent Loop (LLM ⇄ Tools, до 25 итераций)
    │
    ├── run_sql         → SQL-запрос к ClickHouse
    ├── get_reference_values → разведка значений полей
    │
    └── финальный аналитический ответ → Telegram

🔵 Продолжение следует

@alexs_journal

Надя запилила крутой сервис Telegram Wrapped

Без регистрации и СМС — вставляешь ссылку на канал и получаешь статистику за год.

Мой "Теховый дневник продуктщика" получился таким)

@alexs_journal

Немного мыслей про генеративный UI

Мир стоит на пороге смены парадигмы интерфейсов.
Эпоха «прямого манипулирования» (нажал кнопку —> получил результат) уходит.
Ей на смену приходит подход с выявлением намерений пользователя (intent-based outcome specification).

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

Вот 4 сдвига, которые уже происходят:

❤️ От статики к генерации интерфейса на лету
Концепция «статичный макет для среднего пользователя» умирает. На сцену выходит Liquid Design.
Элементы интерфейса становятся «жидкими»: они реагируют на контекст, контент и соседние блоки.

❤️Смерть CRUD-приложений
Традиционные приложения — это, по сути, красивые фасады для баз данных с зашитой бизнес-логикой.
Эра Agentic Experience меняет архитектуру: логика мигрирует в автономные системы (агенты), которые взаимодействуют с данными напрямую.

❤️ Проблема Latency
Когда модель «думает», обычный спиннер убивает UX.
Вводится паттерн Stream of Thought — визуализация мышления модели. Пользователь должен видеть логику: «Планирую —> Обращаюсь к инструменту X —> Анализирую».
Это снижает воспринимаемую задержку и строит то самое calibrated trust (калиброванное доверие), без которого юзеры уходят.

❤️Гибридные интерфейсы (Multimodal)
Чистый LUI (Language User Interface) — не панацея.
«Большинство продуктов не выигрывают от антропоморфизации», — говорят в Perplexity.
Будущее за гибридом: диалоговый ввод + графический (структурированный) вывод.


Все эти концепции (Intent-based UI, Zero UI) звучат революционно в white papers.
Но когда ты начинаешь внедрять это в реальный продукт, ты сталкиваешься с кучей граблей.

У нас в red_mad_robot стрим по Fluid/Liquid UX/UI выбран одним из 5ти ключевых направлений, над которыми мы работаем.

Знаю, что друзья по цеху тоже работают над переосмыслением UX в это интересное время.
Вот тут Даша из одного зелёного банка рассказывает про то, с чем столкнулась при проектировании решения.

Из полезного поизучать на тему — The HAX Toolkit Project от Microsoft
(HAX == The Human-AI eXperience)

@alexs_journal