AI и ML

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

Начал с клода, как с самой популярной тулы. Кэш там не работает сам по себе, нужно руками вешать cache_control: ephemeral на кусок промпта (тулы, системный промпт, длинный документ, что угодно стабильное). Ничего не закэшируется, если явно не попросишь. При этом ценой все прозрачно: запись на 5 минут стоит 1.25 от обычной цены, запись на час — уже 2x, а вот чтение из кэша дешевле раз в 10. Если один и тот же кусок дергается хотя бы пару раз за окно, уже в плюсе.

Но! Где-то в марте anthropic тихо поменял дефолтный TTL с часа на пять минут, без нормального анонса, просто взяли и поменяли поведение по умолчанию для тех, кто не указал TTL явно. У меня был пайплайн, заточенный под часовое окно, и я не сразу понял, почему счет подрос процентов на 15, пока не полез в changelog. Так что если у вас что-то крутится на клоде на автомате уже давно, стоит перепроверить, какой TTL у вас реально стоит сейчас, а не какой вы когда-то настраивали.

С openai все проще, и в хорошем смысле. Там кэш вообще не настраивается руками, он просто есть у любого промпта от 1024 токенов: система сама ищет совпадающий префикс с шагом в 128 токенов, и если находит, режет цену пополам. Ничего в коде трогать не надо. Из минусов, контроля тоже никакого, попал в кэш или нет, узнаешь только постфактум по usage в ответе. И живет это недолго: 5-10 минут простоя, максимум час, потом стирается железно.

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

Современный смартфон представляет собой доступную COTS‑платформу с набором встроенных датчиков: камерой, GNSS‑приемником, 6-DoF IMU, барометром и микрофонами. По отдельности эти сенсоры ограничены, однако их совместное использование в распределенной сети потенциально позволяет создавать новые подходы к обнаружению низколетящих БПЛА.

Это не задача создания «смартфонного радара», а инженерная задача на стыке краудсорсинга, Edge Computing, машинного обучения и обработки сигналов.

Как превратить множество пользовательских устройств в единую распределенную апертуру? Попробуем рассмотреть возможную архитектуру такой системы.

Компания Anthropic представила Claude Opus 5: свой новый ИИ уровня Claude Mythos 5/Fable 5, но в два раза дешевле. По традиции самое интересное прячется в системной карте, где разработчики рассказали о том, как проходило тестирование модели и какие инциденты случались.

Агент проходит все проверки и сносит то, что трогать было нельзя. Промпт это не лечит — лечит среда вокруг модели. В ноябре я начал собирать такую среду и называл её просто фабрикой разработки. Меньше чем за год из неё выросло почти десять конвейеров, а у занятия, оказывается, есть название: harness engineering. Рассказываю, как оно росло, и показываю схему и скелет в github.

Дисклеймер: текущие LLM‑возможности позволяют детектировать «жирный» слоп. Но оценка может быть субъективной, и возможны ошибки, никогда не доверяйте оценке слепо: это обоюдоострый меч. Оценить точно не всегда могут сами люди, кроме совсем очевидных примеров, и даже там среднестатистический житель планеты напряжётся. Этот метод — инструмент, призванный экономить время, необходимое для диагностики человеком. Именно эту плоскость и будет раскрывать статья.

Нам всем уже надоели новости об очередных «достижениях» LLM. Но, несмотря на поток надоедливых новостей, LLM представляют собой одно из ключевых направлений современных технологий (пусть и несколько переоцененное), и здесь иногда происходят некоторые открытия, которые становятся значимыми вехами...

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

Считаю, что русскоязычный читатель должен иметь возможность ознакомиться с этим текстом. Это полный перевод на русский язык свежей, от 6 июля 2026г. статьи на сайте Anthropic

Google опубликовала выпуск AI & Economy ATLAS — исследование о том, как люди используют ИИ в работе и повседневной жизни. ИИ уже присутствует в широком спектре профессий, но чаще помогает с отдельными задачами, чем заменяет их целиком. Разбираемся, почему так и разбираем особенно интересные моменты отчета.

В начале июля я объявил весь код своего проекта легаси. Не модуль — всё: код, архитектуру, документацию. Месяц до этого проект — джоб‑маркетплейс для синих воротничков: мобильное приложение, web, AI‑ассистент — делала команда. Люди сильные, каждый уже работал с LLM‑агентами; не было другого — методологии работы с агентами. Агент пишет код быстрее человека — и энтропию порождает быстрее: все ветки в main, решения только в чате, документация врёт, персональные данные оседают в access‑логах. Каждый исполнитель локально прав, система в целом не работает. Код, который страшно трогать, появился у нас раньше, чем первый работающий флоу. Я остановил всё и начал заново — один.

В этой статье хочу рассказать как я разрабатывал агента, который принимает запросы из телеги и создает страницы на WordPress + Elementor, не путает проекты, не трогает прод и не собирает каждый раз дизайн рандомно.

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

Но по факту все, конечно же, оказалось сложнее.

Чтобы это начало работать нормально, пришлось сделать отдельный навык - очередь задач, SQLite, CLI-проверки, правила для телеги, валидаторы, перенос бета в прод и отдельный компилятор на Python.

Так что расскажу все по порядку, возможно, кому то пригодится.

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

Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Моя прошлая статья была посвящена тому, как с помощью локального класса и глобального API мы с командой «приручили» большую языковую модель для работы с пересортицей. И, как это часто бывает, с прототипа все только началось.

Я много лет занимаюсь развитием финтех-продуктов, а сейчас руковожу продуктами биллинговой платформы в Selectel.

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

Ниже — о том, почему привычный GUI может уступить место ИИ-агентам и как это решает вечную дилемму продуктового дизайна.

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

При этом такая память о пользователе обычно не является встроенным свойством самой языковой модели. В прикладных продуктах её чаще добавляют как отдельный слой вокруг LLM: например, через RAG с долговременным хранилищем фактов (векторные или графовые базы памяти, профили пользователя, журналы событий) или агентные схемы — например, локальную файловую систему в духе Obsidian в сочетании с вызовом инструментов.

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

Для русского языка до сих пор не хватало бенчмарка, который проверяет именно такие аспекты долгосрочной памяти в многосессионных диалогах. Поэтому мы сделали RUMBA — Russian User Memory Benchmark: русскоязычный бенчмарк для анализа способности диалоговых систем работать с долгосрочной памятью пользователя в реалистичных разговорных сценариях.

Недавно занимался задачей, которую в медтехе обсуждают часто, а до рабочего прототипа доходят не все: нужно было научить модель смотреть на рентген грудной клетки и выдавать вероятности по нескольким патологиям сразу. Не сегментация, не генерация отчёта — именно мультилейбл‑классификация, чтобы на выходе было что‑то вроде «плевральный выпот 87%, пневмоторакс 12%».

Полный fine‑tune большой сети на арендованной GPU мне не хотелось: дорого, долго, и есть риск переобучиться на паре десятков тысяч снимков. Поэтому пошёл по пути linear probing — взял тяжёлый предобученный энкодер, заморозил его и обучил только небольшую голову. В итоге macro AUC на валидации вышел 0.9025, обучение уложилось в десяток эпох.

Ниже — как устроен пайплайн, где накосячил с путями к датасету, и почему отказался от горизонтального отражения.

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

На практике это выглядит так: например, вы просите агента проанализировать 300 визитов пользователей на сайте. Агент открывает первый плеер, видит десять записей и тут же выдает рекомендации по улучшению конверсии. Выводы сделаны на 3% данных, но звучат убедительно.

Началось всё с подборки промтов cursor-vibe-prompts, которую я таскал из проекта в проект копипастой, и в какой-то момент меня настолько утомила эта рутинная процедура копирования из одного окошка в другое, что захотелось чуть упростить себе задачу и вместо копипасты оформить эту историю в формате скилов и вызывать по необходимости.

Так на свет и появился репозиторий rpa-skills, изначально в нём была сборная солянка директорий скилов, которые содержали в себе просто SKILL.md с оригинальными промтами внутри. Но выглядело и юзалось это решение как-то не очень удобно, да и масштабировать захотелось, так что я решился пойти на немыслемое, почитать документацию о том, как правильно собирать скилы и маркетплейсы, о чём и расскажу сегодня вам.

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

Как перестать доверять LLM-судье на слово и построить безопасную двухконтурную систему оценки?

Внутри статьи:

Архитектурный паттерн сдерживания: почему у классической нормализации должно быть право вето.

CI-инварианты: как ловить галлюцинации моделей с помощью враждебных фикстур в grounded-judge-gate.

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

RAG уже стал стандартным способом научить LLM работать с собственными документами без дорогостоящего дообучения. Но за кажущейся простотой скрывается множество практических вопросов: как разбить документы на чанки, где хранить эмбеддинги, как организовать быстрый семантический поиск и какую модель использовать на каждом этапе.

В статье соберем полностью локальную RAG-систему на Go, PostgreSQL и Ollama без облачных API и сторонних сервисов. Разберем весь путь — от индексации документов до получения ответа LLM на основе найденного контекста.

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

Введение

Кажется, что нейросети могут все. Мы видим результат их работы в системах распознавания лиц, видеоаналитике. Нас поражает умение нейросетей рисовать изображения, распознавать и синтезировать голос, а большие языковые модели уже давно проходят тест Тьюринга и ведут беседу как живые люди. Но, как показал мой эксперимент, в задачах кредитного скоринга они нисколько не лучше классических ML-моделей. В этой статье я расскажу, как решающее дерево, случайный лес, бустинг и даже многослойная нейросеть упираются в один и тот же потолок на данных кредитного скоринга.

Ход эксперимента

В качестве датасета были взяты данные кредитного скоринга с https://www.kaggle.com/competitions/GiveMeSomeCredit. Сначала мы обучили решающее дерево, с кросс-валидацией.  График зависимости roc-auc от количества элементов выборки (Ореол вокруг кривой – это дисперсия (разброс) при кроссвалидации):

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