Дайджест за 29 октября 2026

Встроили LLM в корпоративную отчётность: архитектура и решения

ИИ и агенты · Habr · 9/10

Команда YADRO разработала сервис автоматической генерации ежедневных отчётов об IT-активах компании, в котором LLM используется только для написания аналитических комментариев, а все вычисления остаются за кодом. Архитектура решения основана на разделении ответственности: Python-скрипт считает метрики и передаёт модели только сжатый набор ключевых чисел со специальными метками вместо цифр, что физически исключает возможность искажения показателей нейросетью. Для интеграции множественных источников данных (Naumen.ITAM, ClickHouse, 1C, Jira, NetBox) внедрили Trino — распределённый SQL-движок, позволяющий объединять историю и текущее состояние, а также склеивать данные между системами в едином федеративном запросе. Сервис работает по расписанию через Airflow, использует Dify как платформу для работы с моделями, а доступ управляется через корпоративный Keycloak и интегрирован с Mattermost. Разработка велась с самого начала как поддержка управляемой деградации: если модель недоступна, отчёт выходит в срок с корректными цифрами, но без текстовых выводов. Сервис оказался в несколько раз быстрее по времени сборки чем традиционные дашборды Superset при сохранении качества данных.

Выводы автора:

• Все вычисления и подстановка цифр должны осуществляться кодом, а LLM взаимодействует только с метками и отвечает за текстовый анализ — это исключает искажение данных моделью
• Использование Trino для федеративных запросов к множеству источников данных позволяет объединить текущие и исторические данные, а также связать таблицы между системами без переписывания отчётов
• Архитектура с управляемой деградацией гарантирует, что недоступность LLM или платформы не влияет на выпуск отчётов с корректными метриками

Модель физически не может исказить показатель: числа через неё не проходят.

Оригиналы:Код считает, модель описывает: встроили LLM в отчётность · Визуализация данных

Локальный кодинг-агент на RTX 4070 Ti: 125 токенов/сек

ИИ и агенты · Habr · 8/10

Автор описывает, как запустить полноценный кодинг-агент на видеокарте RTX 4070 Ti SUPER (16 ГБ) с производительностью 125 токенов в секунду, что ранее считалось недостижимым. Главное достижение — использование моделей Tiel-Coder-35B и Cyber-Tiel-Coder-35B с технологиями MTP (предсказание нескольких токенов за раз, +20% скорости), MoE-архитектурой (+200–450% скорости), Sharp Template (+59% оптимизации) и квантованием Q2_K_XL. Автор рекомендует лёгкого кодинг-агента Pi вместо тяжёлых (Codex, Claude Code), разбивает большие задачи на этапы планирования и реализации через plan.md, использует SKILL subtask4llm-pi для разделения сложных задач на подзадачи и применяет файл AGENTS.md с жёсткими правилами кода (ограничение размера файла, unit-тесты, декомпозиция). Результат — синергия нескольких методов позволяет получить качественный рабочий процесс кодинга на локальной видеокарте без использования облачных сервисов. В обновлении указано, что Qwen 3.8 Flash Next 125B в квантовании IQ3_S на той же видеокарте даёт ~60 токенов/сек с качеством, сопоставимым с GPT-4 Luna.

Выводы автора:

• Комбинация MTP, MoE архитектуры, квантования и Sharp Template позволяет достичь 125 токенов/сек на локальной видеокарте 16ГБ, что ранее было недостижимо.
• Использование лёгкого агента Pi, разбиение задач на фазы и создание AGENTS.md компенсирует потерю качества квантованных моделей через жёсткие рамки кодирования.
• Локальное управление кодинг-агентом обеспечивает полный контроль над исходниками и позволяет использовать цензурные версии моделей для белого хакинга.

На локальной видюхе мы не платим за каждый токен, поэтому безболезненно переживём пару лишних итераций, когда модель увидит свои ошибки и исправит их.

Оригиналы:125 токенов в секунду на RTX 4070 Ti SUPER: как я заставил локальную LLM работать полноценным кодинг-агентом

Meta's Muse достиг 10M пользователей: Amazon и банки диктуют условия

ИИ и агенты · Linas from Linas's Newsletter · 8/10

Материал анализирует стремительный рост AI-агента Meta Muse, который за шесть недель привлёк 10 миллионов пользователей в США и Канаде, став первым массовым агентом для покупок. Однако Amazon заблокировал Muse, а крупные банки вроде JPMorgan закрыли доступ таких агентов к аккаунтам клиентов. Meta на квартальном отчёте Q3 2026 признала, что следующий этап развития агентской коммерции будет происходить на условиях, которые диктуют крупные торговцы и банки. Автор разбирает раскрытые Meta показатели Muse и те, что компания скрыла, объясняет, почему Meta будет взимать комиссию с торговцев, а не с покупателей, и почему отрицательный свободный денежный поток вынуждает компанию монетизировать агента раньше. Это противоположная стратегия той, что выбрала OpenAI. Ключевой вопрос — сможет ли Meta стать брокером агентской коммерции на новых условиях.

Выводы автора:

• Meta Muse стал первым AI-агентом с массовой аудиторией (10M пользователей за 6 недель), но его развитие зависит от условий, которые ставят Amazon и банки
• Meta планирует монетизировать через комиссии с торговцев, а не потребителей, чтобы справиться с отрицательным свободным денежным потоком
• Будущее агентской коммерции будет строиться по правилам, установленным крупными платформами и финансовыми институтами, а не технологическими компаниями

Следующая фаза агентской коммерции будет работать на условиях, которые устанавливают торговцы и банки

Оригиналы:Meta Muse AI Agent — информация из оригинальной публикации

Как Uber построил шлюз для ИИ-агентов доступа к инструментам

ИИ и агенты · ByteByteGo · 8/10

Материал разбирает архитектуру MCP Gateway — платформы, которую Uber создала для унификации доступа ИИ-агентов к корпоративным инструментам и API. Проблема состояла в том, что базовые LLM не могут работать с внутренними системами без доступа к специфичным для компании данным и операциям; решение — создание инструментов (tools) как структурированных обёрток над API. Uber столкнулась с масштабируемостью: разные команды разрабатывали собственные MCP-интеграции, в ландшафте сосуществовали HTTP, gRPC и TChannel, поиск нужных инструментов был затруднён. MCP Gateway состоит из двух компонентов: MCP Registry (control plane) — каталог серверов и инструментов; и Proxy Gateway (data plane) — обработчик реальных запросов.

Обнаружение инструментов автоматизировано через AutoCrawler — распределённую систему, которая сканирует существующие API-определения (IDL) и native MCP-серверы, генерирует определения инструментов с помощью LLM и регистрирует их. Новые инструменты стартуют в отключённом состоянии, требуя явного одобрения владельцем сервиса.

При обработке запроса gateway конвертирует MCP-запрос в формат целевого сервиса (JSON→Protobuf, например), выполняет операцию и возвращает результат в MCP-формате. Система поддерживает контроль доступа на уровне инструментов через встроенную систему авторизации, может редактировать чувствительные данные в ответах и работает с внешними сервисами (Jira, Google) через обмен токенов.

Выводы автора:

• MCP Gateway решает проблему фрагментированного инструментария в масштабах корпорации, позволяя разным ИИ-агентам единообразно обращаться к API различных форматов и команд.
• AutoCrawler автоматизирует регистрацию инструментов путём сканирования существующих API-определений и генерации MCP-интерфейсов, исключая необходимость ручной интеграции для каждого сервиса.
• Архитектура разделяет управление (реестр с явным одобрением) и выполнение (прокси-шлюз), обеспечивая гибкий контроль доступа и безопасность на уровне отдельных инструментов.

Вы не можете ожидать от неё ответов, основанных на особенностях внутреннего устройства вашей системы — для этого нужны инструменты.

Оригиналы:Как Uber построил шлюз для ИИ-агентов — полная статья · Uber Engineering Blog

Как 2,5 года я разрабатывал ненужный софт для сравнения изображений

Разработка и архитектура · Habr · 7/10

Автор рассказывает о многолетнем опыте создания программы BlinkTable (Improve-ImgSLI) — инструмента для сравнения изображений бок о бок с лупой и редактированием видео. Проект начался в середине 2024 года с простого желания автоматизировать сравнение апскейлов, но превратился в многолетнее хобби с использованием ИИ-агентов для разработки. На первом этапе (вторая половина 2024) автор работал через копипасту кода из браузерных чатов ChatGPT 3.5 и Gemini, писал промпты на уровне «общения с ребёнком» и медленно добавлял функции вроде заморозки луп и мультиязычности. Второй этап (середина 2025) принёс революцию с инструментами Cursor и Codex, где сам ИИ проверял код — добавились новые режимы интерполяции, улучшен дизайн благодаря форку китайского разработчика, применён паттерн MVP для решения проблемы гонки состояний. Третий этап (2026) включил Redux для воспроизводимости операций, перенос отрисовки на GPU, добавление тестов и неудачную попытку миграции на Rust с помощью Claude Opus. На протяжении всего пути автор сталкивался с проблемами архитектуры, лимитами токенов LLM, необходимостью переделок и осознанием того, что специализированные инструменты ИИ требуют дополнительных навыков для эффективного использования.

Выводы автора:

• ИИ-агенты существенно ускоряют разработку даже для сложных проектов, но качество кода зависит от навыков промпт-инжиниринга и архитектурного планирования
• Лимиты контекстного окна LLM были критической проблемой, пока не появились инструменты с миллионом токенов (Gemini 1.5 Pro)
• Крупная рефакторизация проекта (переход на Redux, перенос рендеринга на GPU) требует не только ИИ, но и понимания системного проектирования, иначе превращается в работу по исправлению ошибок вместо новых возможностей

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

Оригиналы:Как я 2,5 года никому не нужный софт вайбкодил

Самая старая программа GUI, запускаемая на Windows 11 без эмуляции

Разработка и архитектура · Habr · 7/10

Статья исследует, какая самая древняя программа с графическим интерфейсом до сих пор запускается на Windows 11 без каких-либо модификаций и эмуляции. Автор начал с поиска 16-битных программ, но обнаружил, что современная 64-битная Windows не поддерживает NTVDM, поэтому пришлось искать среди приложений эпохи Windows NT. Первоначально найденной программой была FREECELL.EXE от 22 февраля 1993 года, которая исправно работает на Windows 11 спустя 33 года и 8 месяцев. При более глубоком поиске выяснилось, что ранние версии Windows NT 1991-1992 годов использовали несовместимый с современностью формат PE и другое соглашение о вызовах API (cdecl вместо stdcall), что приводило к краху программ. Самой старой программой, запускаемой без эмуляции, оказалась CDPLAYER.EXE от 16 ноября 1992 года из сборки 347, которая полагается на системную crtdll.dll, всё ещё поставляемую Windows 11 в SysWOW64. Программа работает и даже может воспроизводить звук с эмулированного CD-ROM. Помимо этого, через стороннюю эмуляцию (otvdm) удаётся запустить REVERSI.EXE из Windows 1.01 (1985 год).

Выводы автора:

• CDPLAYER.EXE от ноября 1992 года является самой старой программой GUI, работающей на Windows 11 без эмуляции, благодаря использованию системной crtdll.dll.
• Обратная совместимость Windows ограничена несовместимостью формата PE и конвенций вызовов API в версиях до середины 1992 года.
• Через эмуляторы типа otvdm можно запустить ещё более древние программы, включая REVERSI.EXE из Windows 1.01 1985 года.

На момент написания поста этой программе 33 года и 8 месяцев. Она почти моя ровесница, и это впечатляет.

Оригиналы:Какая самая старая программа с GUI запускается на Windows 11 без эмуляции

Энергоэффективная система видеонаблюдения для морской акватории на ИИ

Разработка и архитектура · Habr · 7/10

Автор описывает разработку и установку автономной системы визуального контроля морской акватории для предприятия по разведению рыбы на Дальнем Востоке. Вместо дорогостоящих РЛС с биспектральными камерами он выбрал решение на основе Home Assistant с ускорителем Hailo-8 M.2 (26 TOPS) на мини-ПК N150 для классификации объектов (катеры, люди). Система включает три камеры: две для охраны оборудования, одну биспектральную (тепловизор + поворотная) для контроля акватории. Энергоснабжение обеспечивают четыре солнечные панели (4×240 Вт) с LiFePO₄-аккумулятором 12 В/300 А·ч в режиме двух отдельных контроллеров для надёжности. Оборудование размещено в двух всепогодных ящиках с терморегуляцией (термокабель, вентиляторы, датчики DS18B20). Тревожные сигналы и информация о работе системы передаются через корпоративный мессенджер Matrix с локальными моделями ИИ и GSM-антенну. На установке в условиях скальной местности (75 м высоты, 20 м/с ветра) применены молниеотвод, заземление и защита УЗИП. При текущей нагрузке ~50–100 Вт батареи хватает на 1,5 суток без солнца; в солнечный день панели дают 700–800 Вт к часу дня. Система автоматически управляет режимами работы в зависимости от заряда.

Выводы автора:

• Для охраны морских угодий можно построить энергоэффективное решение на базе Home Assistant и локального ИИ вместо дорогостоящих коммерческих РЛС-систем.
• Критичной частью проекта остаётся энергобюджет: при текущих 50–100 Вт нагрузки запас автономности минимален (1,5 суток), требуется балансировка между функциональностью и потреблением.

Необходимо найти экономически оправданное и технически эффективное решение, а ещё постараться не обанкротить дядю.

Оригиналы:Делаем энергоэффективную систему визуального контроля морской акватории

ESG в России переходит на стандартизированные данные вместо деклараций

Финтех и финансы · Б.О: Не банки · 8/10

Материал рассказывает о трансформации подхода к раскрытию ESG-показателей в России: вместо добровольных описаний компании переходят на стандартизированный машиночитаемый формат XBRL. После 2022 года нефинансовое раскрытие сократилось, но повестка изменила форму, став более прикладной и данными-ориентированной. Банк России внедряет единую таксономию XBRL для эмитентов первого и второго уровней листинга — в 2025 году это добровольно, с 2026-го обязательно. Стандартизация позволяет сопоставлять компании по ESG-показателям, отслеживать динамику и выявлять аномалии в раскрытии, создавая базу для отраслевых бенчмарков. Банки и инвесторы получают практический инструмент: на первом уровне — скрининг полноты данных, на втором — корректировка финансовых прогнозов (расходы на модернизацию, риски штрафов), на третьем — привязка кредитных условий к ESG-показателям. Примеры уже есть: энергохолдинг «РусГидро» отдельно раскрыл показатели по таксономии Банка России в отчете за 2025 год. Компаниям рекомендуется определить владельцев показателей и проверить методики расчета, банкам — формировать отраслевые ориентиры и искать связи между нефинансовыми данными и кредитным качеством.

Выводы автора:

• ESG в России не исчезла, а трансформировалась из деклараций в стандартизированные структурированные данные формата XBRL, которые можно сравнивать и анализировать.
• Обязательное применение единой таксономии XBRL начнется с отчетности за 2026 год для эмитентов первого и второго уровней листинга, создавая инфраструктуру для объективной оценки ESG-рисков.
• Банки и инвесторы получат практический инструмент для скрининга, корректировки финансовых предпосылок и создания кредитных продуктов, привязанных к конкретным показателям устойчивого развития.

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

Оригиналы:Устойчивое развитие на языке метаданных

CRM-системы банков: эволюция от баз данных к ИИ-агентам

Финтех и финансы · Б.О: Банки · 7/10

Статья рассматривает эволюцию систем управления взаимоотношениями с клиентами (CRM) в российских банках, которые внедряются уже два десятилетия. Современные CRM должны управлять несколькими категориями клиентов (физлицами, МСБ, корпорациями, партнёрами) и требуют высокого уровня автоматизации для персонализированных предложений. Традиционные клиентские базы эволюционировали в единые реестры, обогащаемые данными из внешних источников и содержащие досье контрагентов и потенциальных клиентов. Ключевым трендом 2025 года стала интеграция генеративных ИИ: нейросети теперь занимают первую линию коммуникаций, регистрируют обращения, маршрутизируют звонки, описывают операции и создают стенограммы конференц-звонков. ИИ-помощники избавляют менеджеров по продажам от 70% рутинных операций (регистрация лидов, подготовка писем). Пример системы Digital Q CRM демонстрирует, как low-code-платформы позволяют создавать на требование банка AI-агентов и мультиагентов для управления их работой. Система интегрируется с каналами дистанционного банковского обслуживания и автоматизированными банковскими системами. Критическое внимание уделяется безопасности: постоянный мониторинг уязвимостей через реестры CVE и БДУ ФСТЭК России, регламентированный цикл исправлений в зависимости от критичности.

Выводы автора:

• ИИ в CRM-системах перемещает первую линию коммуникаций с клиентами полностью на нейросети, которые регистрируют обращения, маршрутизируют звонки и создают стенограммы операций.
• Интеграция ИИ в CRM высвобождает менеджеров от 70% рутинных операций, позволяя им сосредоточиться на стратегических задачах.
• Модульная архитектура на low-code-платформах и системная работа с публичными базами уязвимостей становятся обязательными стандартами для банков при выборе CRM-решений.

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

Оригиналы:CRM на упрощение: Системы управления взаимоотношениями с клиентами в банках России

Почему автоматизация e-commerce сложнее энтерпрайза: реальность маркетплейсов

Продукт и карьера · Habr · 8/10

Автор, разработчик ИИ-агентов, делится наблюдениями о том, как работают крупные fashion-бренды на российских маркетплейсах (Wildberries, Ozon, Lamoda) и почему там до сих пор живут в Экселе. Компании стоят перед парадоксом: у них квоты на оборот вместо стандартной комиссии, что заставляет продавать в убыток для достижения целевого объёма. Выкупаемость одежды составляет лишь 30–60%, цены персонализированы как в такси, а менеджеры физически не успевают отследить по 10+ тысяч артикулов. 60–70% времени менеджеры тратят просто на сбор и агрегацию данных из разных источников, а не на принятие решений. Внешние системы аналитики и BI малоэффективны: они либо спамят тысячами бесполезных алертов, либо не показывают причин проблем. Ключевая проблема — системы не понимают бизнес-контекста: что для одного товара стратегия ликвидации со снижением цены, для другого нужно просто заменить фото или дождаться поставки размера. Автор приводит пример, когда агент вместо повсеместного снижения цены на 10% предложил снизить её только на шести артикулах, где реально было дешевле у конкурентов, а остальным — заменить главное фото, что разморозило склад за два дня без потери прибыли.

Выводы автора:

• Крупные бренды на маркетплейсах работают по иной логике, чем традиционный бизнес: квоты на оборот заставляют иногда продавать в убыток, а система должна видеть всю картину маржи и стратегии, не только юнит-экономику отдельного товара.
• Менеджеры проводят 60–70% времени на сбор и обработку данных из разных систем вместо анализа и принятия решений, потому что API маркетплейсов отдают неполные данные и нет единого источника истины.
• Существующие системы мониторинга и BI не работают на масштабе 10+ тысяч товаров: они либо спамят алертами (которые отключают), либо не показывают причин, оставляя менеджеру вручную искать проблему в каждой карточке.

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

Оригиналы:Я пришёл автоматизировать маркетплейсы из кровавого энтерпрайза, и вот что меня сильно удивило

Как монетизировать жалобы клиентов: 8 типов конфликтов и способы доход

Продукт и карьера · Habr · 8/10

Статья топ-менеджера НОРБИТ разбирает, как жалобы и конфликты с клиентами можно превратить в дополнительные источники дохода, если правильно их интерпретировать и коммуницировать. Автор выделяет восемь типов жалоб, начиная с завышенных ожиданий по уровню сервиса (решение: предложить премиум-пакет с более высокой стоимостью, например вместо 50k рублей — 80k за VIP-обслуживание). Вторая жалоба касается недопонимания сложности работы: простая переделка интерфейса может занять 3 часа и стоить 13 500 рублей, что нужно объяснять заранее. Третий тип — когда разработчик реализует более сложное решение, чем ожидал клиент, и требует дополнительную оплату; здесь критично заранее согласовать масштаб и цену с руководством клиента. Четвертая проблема касается информационной безопасности: заказчики часто ожидают, что система должна быть неуязвима, но эти работы часто не входят в исходный контракт, открывая возможности для допродаж пентестов, сканирования уязвимостей или обучения. Пятый тип — когда клиент передумал нужна ему система, часто из-за смены руководителя, и здесь важно держать проект под операционным контролем. Ключевой принцип: не ждите конфликта, чтобы начать продавать, уточняйте требования, масштабы и ответственность сторон в самом начале проекта.

Выводы автора:

• Жалобы клиентов — это возможность дополнительной монетизации через предложение апгрейдов сервиса, пентестов и специализированных услуг, но только если их предложить до конфликта и в правильный момент.
• Кажущиеся простыми задачи часто требуют больше работы (согласование, тестирование, документирование), и заказчики готовы платить, если им заранее объяснить стоимость и время.
• Темы, не вошедшие в контракт (особенно информационная безопасность), нужно обговаривать в начале проекта, пока стороны хорошо относятся друг к другу, чтобы избежать претензий потом.

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

Оригиналы:Как жалобы заказчика станут источником ваших новых доходов

От идеи к релизу: история создания карточной игры про стартапы

Продукт и карьера · Habr · 7/10

Автор рассказывает о своём пути разработки цифровой адаптации настольной карточной игры про стартапы (Shhh, IT!) — от первоначального успеха на локальных тусовках в 2017 году до финального релиза через Steam Direct. Проект пережил множество изменений: концепт трансформировался из карточной настолки в айдл-игру, менялась художественная стилистика, уходили ключевые члены команды. За месяц до первого релиза издателя приобрели конкуренты и все проекты поставили на паузу, что автор воспринял как спасение — игра в том виде не была готова. Несколько лет спустя, обнаружив старый код, автор решил выпустить игру самостоятельно через Steam Direct без поиска издателя. Две недели ушли на восстановление и запуск кода, ещё две — на финальную подготовку. В статье подробно описаны правила игры: 2–6 игроков нанимают разработчиков разных уровней, выпускают релизы, занимаются R&D и аутсорсом, пытаясь набрать 20 хайпа и обогнать конкурентов. Игровая механика построена на одновременном тайном планировании и последовательном разворачивании действий, с системой цен за место в очереди, штрафами на выходных и влиянием рыночных трендов.

Выводы автора:

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

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

Оригиналы:Просто сделать игру недостаточно · Логические игры