История — из разговора Latent Space с Ахмадом Аль-Дахле: с января он CTO Airbnb, до этого руководил генеративным ИИ в Meta и выпускал Llama. Задача у него сформулирована как «сделать Airbnb AI-native компанией», и цифры он называет внушительные: 60% кода пишет ИИ, фич и улучшений за год вышло почти на 80% больше, средний инженер выпускает в 1,6 раза больше пул-реквестов. Цифры самой компании, снаружи не проверить. Я читал это с одним вопросом: что отсюда переедет в компанию на сто человек, а что останется игрушкой корпорации с капитализацией 93 миллиарда долларов.

Главную экономию дало не то, что добавили, а то, что убрали

По словам Аль-Дахле, самый большой выигрыш в скорости разработки дала не генерация кода. Раньше продукт в Airbnb шёл по конвейеру: требования, затем дизайн в Figma, затем инженеры, затем тесты, и на каждом стыке работа передавалась из рук в руки. Теперь продукт, дизайн и разработка садятся сразу за прототип. Документ требований как промежуточный артефакт исчез; CTO формулирует это так: компания ушла от избыточного производства артефактов к тому, что код и прототип — и есть артефакт, над которым рассуждают.

Технологии здесь ноль. Это отказ от одного типа документа и от передачи работы между отделами. Компания на сто человек может сделать то же самое в понедельник: следующая доработка в 1С или в CRM начинается не с ТЗ на четыре страницы, а с кликабельного прототипа, который свой разработчик или подрядчик собирает за день — с ИИ это сейчас именно день. У нас в проектах сильнее всего тормозит не разработка, а согласование ТЗ, которое к моменту сдачи уже не совпадает с тем, что хотел заказчик. Аль-Дахле говорит об этом же шире: компании, устроенные вокруг выпуска фич, в эпоху ИИ будут буксовать, устроенные вокруг целей и результатов — справятся.

Шесть недель вместо восьми месяцев — это память компании, а не модель

Everest — внутренний граф организационного контекста Airbnb, построенный на LLM и векторном поиске по всей кодовой базе. Команда доставки продуктов отработала интеграцию с партнёром, её опыт лёг в Everest, и команда трансферов шла по готовой колее. Второй эффект, который Аль-Дахле ценит не меньше: универсалы начали работать в узкоспециальных частях кода, куда раньше пускали только профильных инженеров.

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

Половину тикетов закрывает ИИ, и важнее — какую половину не отдают

Поддержка стала первым местом, где Airbnb выпустила ИИ наружу, к клиентам, и Аль-Дахле называет её самой трудной задачей для внедрения: цена ошибки высокая. Сейчас около половины обращений закрывается без человека, в отчёте за второй квартал — почти 45%. Условий два. До продакшена агента прогоняют на батарее синтетических данных: сначала строят модель и агента, потом генерируют тесты, и только потом выпускают. И второе — цитата, которую я бы повесил над столом руководителя поддержки:

Пока мы решаем 50% тикетов, мы очень осознанно выбираем те тикеты, которые пока не отдаём агентам.

Вопросы безопасности и всё, где последствия ошибки необратимы, туда не пускают намеренно. Половина — это граница, которую провели люди, а не потолок модели.

Здесь масштабируется всё целиком. В компании на сто человек поддержка — три-пять человек в чате и на телефоне, и у них те же два вопроса: на чём проверять бота до запуска и что ему запрещено. Обычно делают наоборот: запускают на всё и потом по жалобам отрезают. У Airbnb список запретов появляется до запуска, и подозреваю, что именно поэтому их цифра растёт, а не откатывается после первого скандала.

Десять дообученных моделей — не для вас. Правило «объясни, что построил» — для всех

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

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

А первым я бы скопировал вещь, которая вообще не про технологии. Аль-Дахле беспокоится, что джуниоры с ИИ не нарабатывают ремесло и суждение, которое у сеньоров пришло через годы эксплуатации систем и собственных ошибок. Поэтому правило: каждый инженер обязан объяснить, что он построил, даже если пул-реквест сгенерировала модель. В малой компании это правило нужнее, чем в Airbnb. Там ошибку поймают ревью и слой тестов, у вас её поймает бухгалтер через месяц. Не можешь рассказать, почему скрипт делает то, что делает, — скрипт в прод не идёт.

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

Шаг на неделю: попросите руководителя поддержки выгрузить обращения за сентябрь и разложить на три стопки — что ИИ закроет уже сейчас по готовым ответам; что закроет, если дать ему доступ к базе знаний и заказам; что ему нельзя отдавать ни при каких условиях. Доля первой стопки — ваш честный аналог «45% Airbnb». Третья стопка — документ, который должен появиться раньше бота.

Модель, которая работает как if/else

TypeSafe основал Диого Алмейда, ушедший из OpenAI, в 2024 году. В октябре компания, по данным TechCrunch, привлекла около $870 млн при оценке $7,5 млрд. Jev вышла 15 сентября и не пишет текст вообще. Ей дают «состояние» — переписку, транскрипт, карточку сделки — и типизированные вопросы, а она возвращает ответ из допустимых вариантов с вероятностью: выбор одного из списка (до 255 вариантов), оценку по шкале или «да/нет». Сам Алмейда формулирует так: ИИ должен быть похож на базу данных, а не на коллегу.

Цена — $0,042 за миллион входных токенов, выход бесплатный. Лучшую метафору я нашёл у Джона Линдквиста: это не промпт, а if/else. Где в программе стоит условие или switch, туда и ставится такая модель. За 16 дней после Jev вышли пять похожих — Clef от Cloudflare, pplx-decider от Perplexity, Strands Decider от AWS, Laya и GLiDE, — а OpenAI запустила свой Decisions API.

Что на самом деле добавили в 1.14

На витрине — картинки и скриншоты на входе, новый тип ответа Box (рамка вокруг объекта плюс уверенность) и контекст до 262 тысяч токенов. В документации всё скромнее. Картинки и длинный контекст включаются флагом с названием Danger Zone, версия 1.14 доступна только как preview, и TypeSafe сама пишет, что неровностей для продакшена «слишком много». Длинный контекст, по их же словам, медленнее и менее точен.

Box возвращает ровно одну рамку и не умеет ответить «объекта нет». У одного из тестировщиков отсутствующий на фото велосипед всё равно получил рамку — с уверенностью 0,03. TypeSafe советует сначала спросить «есть ли объект», и только потом просить рамку.

У Мейера на товарных фото модель узнавала свой заголовок с медианой уверенности 0,76 и уверенно отвергала чужие. На новостных снимках, где везде люди за мониторами, медиана упала до 0,33 — это почти угадайка. А mesh-систему из роутера и модуля модель назвала просто роутером.

Почему я не понёс бы это на кухню ресторана

У нас в проектах видеоаналитики для ресторанов детектор стоит на месте, рядом с камерами, и смотрит несколько потоков сразу. Jev 1.14 упирается в каждую из причин, по которым мы так делаем.

• Одна рамка на вопрос. «Сколько тарелок на раздаче» — не к ней, и обзоры прямо называют счёт слабым местом таких моделей.
• Задержка. Треть секунды на кадр плюс сеть — нормально для фото раз в минуту, но не для видеопотока.
• Данные. Кадры с поварами и гостями уходят в американское API. Для российской сети это прежде всего вопрос 152-ФЗ, оплата тут вторична.

Где картинки уже пригодятся: проверка фото как документа. «На фото чека есть QR-код?», «Ценник на выкладке на месте?», «На скриншоте из 1С документ проведён?». Одна фотография, один вопрос, ответ да или нет. Картинка 1024×576 — около 1 600 токенов, то есть примерно семь тысячных цента за проверку.

И для России важнее другое. У Clef от Cloudflare веса открыты под Apache 2.0 и есть визуальный энкодер, GLiDE и Laya тоже открыты, Laya отвечает примерно за 33 мс на видеокарте T4. Подход можно поднять на своём сервере и не отправлять кадры за границу. Я бы смотрел в эту сторону, а не на API TypeSafe.

Звонкам менеджеров это подарок

Чек-лист разговора — это готовый набор вопросов да/нет. Менеджер выяснил бюджет? Назвал следующий шаг? Клиент упомянул конкурента? Каждый пункт — отдельный вопрос, интерес клиента — оценка от 1 до 5, следующий этап воронки — выбор из списка. Транскрипт звонка — состояние. Вместо пересказа звонка, который потом всё равно кто-то читает, в CRM ложится строка с вероятностями по каждому пункту.

По моим прикидкам, транскрипт десятиминутного звонка — несколько тысяч токенов, и десять тысяч звонков в месяц уложатся в доллар-два по прайсу TypeSafe. Оговорка одна, и она важная: основной язык обучения у Jev английский, для остальных качество, по словам самой компании, «неравное». Русские звонки надо мерить на своих данных. Тот же приём закрывает разбор входящих заявок: «продажи, сервис, бухгалтерия или спам» — это классический выбор из списка.

Порог важнее модели

Самая полезная цифра, которую я нашёл, — в разборе decision-моделей на Хабре. При пороге уверенности 0,9 Jev брала на себя 70 % решений с точностью 95,9 %. Оставшиеся 30 % уходят дальше — к обычной LLM или к живому РОПу. Это и есть рабочая схема: быстрая модель закрывает уверенные случаи, спорные идут к дорогой модели или человеку.

Бенчмарки вендоров при этом спорят друг с другом. Clef обходит Jev на банковской классификации на 14,5 пункта и проигрывает 8,6 на задаче «вызывать ли инструмент прямо сейчас». Средний балл ничего не говорит — смотреть надо на строку, похожую на вашу задачу, а лучше на свои данные.

Что сделать на этой неделе

Возьмите 200 случаев, где правильный ответ уже известен: звонки, которые оценил РОП, или заявки, которые разнесли руками. Прогоните их через decision-модель — открытую у себя или Jev, если данные не чувствительные. Посчитайте, при каком пороге точность не ниже человеческой и какую долю модель закрывает сама. Если выходит 60–70 % при точности выше 95 %, у вас первый автоматизированный кусок отдела продаж почти бесплатно. Если меньше — вы сэкономили месяц пилота.

Сам Jev на русских транскриптах я ещё не гонял. Как прогоню — выложу цифры.

Я эту сцену вижу регулярно. Собственник открывает страницу тарифов, умножает в уме, получает сумму меньше зарплаты одного оператора и спрашивает: «Модель стоит копейки, почему внедрение стоит столько?» Мой ответ: токены — это электричество. Без него цех не работает, но смету цеха определяет не счёт за ток, а станки и люди у станков.

Одно обращение к внешней системе — и счёт за модель почти удвоился

Даже сам счёт за токены на прайсе и в жизни разный. Addepto продолжает пример: если в каждом диалоге модель один раз обращается к внешней системе — проверить заказ, уточнить статус доставки, — это добавляет примерно тысячу входных и пятьсот выходных токенов. На 50 000 диалогов это ещё $100 и $250, итого $800 вместо $450.

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

Из пяти статей расходов провайдеру модели достаётся одна

Addepto раскладывает стоимость владения на пять корзин. Токены. Платформа: поиск по документам, индексы, хранилище, мониторинг. Настройка: промпты, база знаний, наборы примеров для проверки качества. Эксплуатация: выкладка, инциденты, безопасность, дежурства. И переезд, про который забывают почти все: выходит новая модель, промпты перенастраивают, интеграции правят, качество проверяют заново, и на время перехода оно может просесть.

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

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

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

Свой сервер — не экономия, а другой тип счёта

Обычная реакция на цифры за токены: «Поставим модель у себя и будем платить только за электричество». Addepto показывает, почему это редко сходится. Сервер с GPU за условные $3 000 в месяц при полезной загрузке 20% обходится в пересчёте на выполненную работу примерно в $15 000, при загрузке 80% — около $3 750. Тот же сервер, та же цена, разница в четыре раза, потому что простой тоже оплачен. Отказоустойчивость — вторая реплика — удваивает мощность ещё до разговора о пиках.

Универсального порога «от стольки-то миллионов токенов выгоднее своё» авторы не дают и прямо пишут, что его нет. В России главный аргумент за свой сервер обычно не деньги, а данные — 152-ФЗ, договоры с заказчиками, служба безопасности. Причина нормальная, только считать это надо как плату за контроль над данными, а не записывать в экономию.

Считайте не токен, а одно обращение, которое не пришлось переделывать

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

Как посчитать у себя за один день. Берёте один процесс, где модель уже работает: разбор входящих заявок, ответы в поддержке, сортировка писем. Собираете числитель:

Знаменатель — число обращений, прошедших без вмешательства человека. Если из тысячи заявок триста переделывал менеджер, делите на семьсот, а стоимость этих трёхсот сидит в числителе и тянет его вверх сильнее всего. Результат сравните с тем, во что обходится то же обращение руками. По моим прикидкам, строка «токены» после такого подсчёта обычно оказывается в самом низу таблицы, а «проверка людьми» — в самом верху; точные доли у каждого свои. Цифры у Addepto иллюстративные, они это сами пишут; тарифы на сегодня я не сверял.

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

Я читал статью сооснователя Артёма Гамбицкого на Хабре как подсказку собственнику дистрибутора или сервисной компании, у которого нет ни одного разработчика. У него почти наверняка происходит то же самое, только без песочницы: кто-то в закупках собрал бота в Telegram, логист попросил нейросеть написать скрипт, который перекладывает выгрузку из 1С в таблицу. Сисадмин об этом не знает, потому что его не спрашивали.

Запрет убирает код из поля зрения, а не из компании

Гамбицкий описывает старт без прикрас: вайбкодинг начался стихийно, проекты жили «на ноутбуках и сомнительных виртуалках, о которых знал только их автор». Разработка такие запросы не брала и, по его словам, правильно делала: инструмент для экономии времени одного отдела проигрывает в приоритизации любой задаче, влияющей на выручку. Потребность никуда не девалась, а путь от идеи до прототипа через бэклог занимал недели против пары часов у продакта с агентом.

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

В компании без разработчиков роль бэклога играет фраза «нет ресурса». Отделу нужна сверка остатков или форма заявки на склад, ресурса нет, человек идёт к нейросети и за вечер получает что-то работающее. Запретить это можно только на бумаге: код живёт в личном аккаунте, запускается с личного ноутбука, и запрет просто убирает его из поля зрения.

Flowwow выбрала дать процессу рельсы. Дальше важно, какие страхи у них подтвердились, а какие нет.

Боялись, что уронят прод, а кончились лимиты, о которых никто не думал

Команда ждала, что вайбкодеры будут ронять прод. Не роняли. Проблемы пришли из другого места: к концу августа 165 процессов-сборщиков держали две трети занятой памяти, просто ожидая работы; сборки у всех разом упали, когда упёрлись в квоту ключей ядра Linux, 200 на пользователя; при плановом обновлении сеть повисла на сотнях docker-интерфейсов. Это инженерные детали, они не переносятся. Переносится наблюдение: то, чего боишься в самодельной автоматизации, обычно не то, что ломается на самом деле.

Переносится и их модель угроз, по-моему самая полезная мысль текста. Злоумышленника в ней почти нет. Есть честный коллега, который хочет сделать хорошо, и нейросеть, которая галлюцинирует, выполняет удаление не в той папке или идёт читать файл с паролями, «чтобы было удобнее». В переводе на дистрибутора: логист не собирается сливать базу клиентов. Но скрипт, собранный за вечер, может держать пароль от 1С открытым текстом, лежать на домашнем ноутбуке и писать в рабочую базу напрямую, потому что агенту так было проще. Это иллюстрация, руками такой скрипт я не видел; но ровно такое поведение агента Flowwow и описывает.

Главный результат у Flowwow не технический, и именно он переносится

Гамбицкий называет главным изменением не песочницу, а то, что компания «ушла от хаоса на личных ноутбуках и безымянных виртуалках к управляемой системе»: проекты собраны в контуре компании, доступы выдаются системно, «а не по памяти». Код всех проектов ежедневно зеркалируется в отдельный приватный репозиторий, данные — в хранилище компании. Уйдёт автор вместе с аккаунтом — его детище останется.

С корпоративными данными жёстче: по умолчанию доступа нет вообще. Если приложению нужно, под проект через отдел ИБ создаётся отдельная учётная запись с правами строго на чтение конкретного списка таблиц. Не «доступ к базе», а «вот эти таблицы, только читать».

Эти правила — где лежит код, что с ним при увольнении автора, к каким данным и как он прикасается — не требуют инженеров. Они требуют одного распоряжения и админа, который его исполнит.

А вот что не переносится. Песочница Flowwow — это отдельная виртуалка за 20 тысяч рублей в месяц, собственный сервис деплоя, четыре слоя защиты (инструкции агенту, блокирующие хуки, серверные ограничения, регулярная ИИ-проверка кода на уязвимости) и бот поддержки, который каждый вечер дообучается на закрытых тредах. Это построили инженеры IT-компании для IT-компании. У дистрибутора с восемью менеджерами и приходящим сисадмином такого не будет, и строить не надо.

Вайбкодинг не отменил инженерию. Он перенёс её из кода вайбкодера в платформу, на которой этот код живёт.

Платформы у вас не будет, значит, инженерия переедет в правила.

Реестр из пяти колонок вместо песочницы за двадцать тысяч в месяц

Что бы я сделал на месте собственника компании на 50–300 человек без своих разработчиков. Это моя схема, а не практика Flowwow: они решали другую задачу.

Реестр. Пять колонок: что это, кто автор, какие данные трогает и в какую сторону (читает или пишет), где лежит, кто второй человек, который умеет это запустить. Не запретить, а записать.

Доступ. Самоделки в 1С, CRM и банк-клиент только читают; писать — через человека или согласованную интеграцию. Отдельная учётка под каждую, не личный логин сотрудника. Это прямой перенос правила Flowwow про чтение конкретных таблиц.

Место. Код и файлы лежат в папке компании или корпоративном репозитории, а не в личном Google-аккаунте. Flowwow для этого зеркалирует репозитории каждый день; вам хватит правила «нет в реестре и в папке — не работает».

Ответственность. У руководителя отдела, не у сотрудника, который это собрал. Иначе после его увольнения никто не вспомнит, откуда берутся цифры в утреннем отчёте.

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

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

Клиент — международный вендор POS-систем для ресторанов, британское подразделение. Холодные звонки делает один SDR, на старте — около трёх лидов в неделю. Мы делали техническую часть: данные, сбор, матчинг; коммуникацию с клиентом вело агентство-партнёр.

«Нам нужны лиды как можно более бесплатно и как можно больше»

Так задачу поставили на первом звонке 7 июля. Арифметика у клиента простая: в Британии около 100 тысяч ресторанов, отток не меньше 10 % в год — порядка 10 тысяч открытий ежегодно. Digital-маркетинг «работает плохо и дорого», поэтому открытия хотели ловить из данных. И нужна была не «таблица ресторанов», а поводы для разговора: у одиночных заведений — сам факт открытия, у сетей — «вчера что-то случилось, о чём можно поговорить».

Первая версия приложения собиралась в июле вокруг реестров: Companies House (около 73 тысяч контактов), реестр пищевых инспекций FSA, вакансии, заявки на перепланировку, скоринг 0–100. Под ней лежала гипотеза: новое юрлицо плюс свежая регистрация в FSA равно новое заведение.

Что реестры называли «открытием»

О результатах звонков мы не знали ничего: за всю историю отдела ни один исход не был зафиксирован. Поэтому смотрели на сами лиды — и увидели те 47 стационарных из 60.

Дальше хуже. Примерно половина «предоткрытий» структурно не открытия. Стандарт FSA требует, чтобы смена оператора выглядела в реестре как новое заведение. Покупка ресторана оформляется через свежее юрлицо и по документам неотличима от запуска с нуля. Около 60 % регистраций в Companies House никогда не становятся бизнесом — данные ONS. Свежий номер компании у точки с 79 отзывами на картах — новый владелец, а не новый ресторан.

16 августа мы переразметили 516 заведений из «ждёт инспекции» в «смена рук»: у всех было больше 100 отзывов на Google Maps. И поставили эксперимент.

Четыре прогона 20 августа, каждое число измерено

Прогон 1, только Companies House, 100 заведений. На картах нашлись 66, телефонов 57, мобильных 14, медиана отзывов 79, статус «скоро открытие» — ни у одного. Правдоподобно новых — 8 из 100.

Прогон 2, Companies House плюс FSA, снова 100. Нашлись 88, но у 51 из них больше 50 отзывов. Реально новых — 22 из 100. Склейка реестров улучшает находимость, а не свежесть.

Прогон 3, карты первыми. Сетка по 12 городам, 180 запросов «что рядом» в Google Places — 3 185 мест. Фильтр «не больше 5 отзывов» оставил 569 свежих кандидатов. Телефонов 203, мобильных 97 — 48 % против примерно 20 % у реестров. Из 490 кандидатов, сверенных с базой, совпали 53: 89 % найденного в базе не было. Около $0,006 за кандидата.

Прогон 4, директора → LinkedIn. По 150 директорам правильный профиль нашёлся у одного, по 60 компаниям имя совпало у двух. У человека, который на прошлой неделе зарегистрировал кафе, в LinkedIn ничего нет.

Отдельно проверили 247 номеров: подтверждённых 75 (30 %), нигде не опубликованных 118 (47 %), принадлежащих другому бизнесу 52 (21 %), невалидных 2. Номер кофейни висел в сети как телефон таксопарка, номер кафе — как служба бебиситтинга. Apify за все прогоны — $2,78.

Что в итоге получил продавец

Базы разные, цифры в одну не складываются: прогоны 1–2 — выборки по 100 реестровых записей, прогон 3 — всё, что карты показали в 12 городах.

Шорт-лист на передачу — 167 заведений: 84 с мобильным, 59 с подтверждённым номером, 71 с нулём отзывов, 3 со статусом «скоро открытие». 2 сентября SDR дозвонился по нему и забронировал первое демо; второй контакт — кофейня при церкви, не совсем целевой профиль, но живой разговор. Планка у клиента трезвая: «даже если 1 из 50 — это дополнительная встреча». Договорились на 50 лидов в неделю, мобильные первыми; по сетям — триггеры вместо контактов. Регулярный проход по 40 городам — около 600 запросов раз в месяц, меньше $10 на Apify.

Клиент подтвердил выводы «со стороны трубки»: по спискам из Companies House «никто не отвечал», а «по картам точнее». Эффект в деньгах клиент не раскрывает; конверсию «167 → демо» как метрику считать рано.

Где мы потеряли полтора месяца

1. Гипотезу надо было измерять на 100 записях в первую неделю, а не строить вокруг неё ночные сборы. Прогон на 100 строк стоит центы и показывает всё. Теперь любая «сигнальная» база проходит через вопрос «сколько из этих 100 — то, что мы ищем».

2. Тип телефона — фильтр, а не поле в таблице. Стационарный в неоткрытом помещении звонит в пустую комнату, и «не ответили» — физика, а не плохие данные. Мобильные теперь идут первыми, стационарные — только после открытия.

3. Обогащение по сетям делали, не спросив продавца, что у него уже есть. Оказалось — своя таблица техдиректоров и COO с мобильными и оплаченный Lusha, а наши списки давали телефон одной точки вместо человека в центральном офисе. Ветку закрыли. И объём он просил другой: «не 3 000, а 50 в неделю» — основная работа у него сети, где до встречи уходит до восьми звонков. Делал бы иначе: первый час проекта — интервью с тем, кто звонит, а не с тем, кто ставит задачу.

4. Чужой номер хуже отсутствия номера. 21 % — это продавец звонит в таксопарк и решает, что база мусор. Теперь верификация до передачи, «другой бизнес» не отдаём. Из той же серии: нормализатор принял стамбульский +90 212 за британский 0212 — полдня на разбор.

Что можно перенести к себе

Если вы продаёте в HoReCa, ритейл или сервисные точки в России, схема переносится почти целиком — меняются источники.

• Повод вместо списка. Новая карточка на 2ГИС или Яндекс Картах с нулём отзывов говорит про открытие больше, чем свежая запись в ЕГРЮЛ. Реестр — для подтверждения, что это новое юрлицо, а не филиал.
• Число отзывов — грубый, но рабочий фильтр свежести. Порог подбирайте на своих 100 записях.
• Делите телефоны по типу до передачи продавцу и проверяйте, чей это номер.
• Пока исходы звонков не фиксируются, о качестве базы вы узнаёте последним.
• Спросите продавца, сколько лидов он реально обработает в неделю и что у него уже есть. Половина обогащения может оказаться лишней.

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

Я читал это как материал про озвучку статей, а слышал телефонный разговор. Из таких кусков состоит всё, что голосовой агент говорит клиенту: название компании, сумма, дата отгрузки, номер заказа. На демо вендора голос читает что-нибудь про кофе и звучит отлично. В бою он будет читать вашу CRM.

В боте текст для озвучки пишет модель, и редактора между ними нет

Главный совет источника — чинить не настройки, а текст до синтеза. Ударение ставится знаком: у Яндекса плюс перед гласной («зам+ок»), у большинства остальных — символ Unicode U+0301. Числа пишутся словами, потому что «к 15 марта» модель читает как «к пятнадцать марта», а «в 2026 г.» — с голым «г» на конце. Латиницу автор советует транслитерировать: «эй-пи-ай вернул двести о-кей». Для аудиоверсии статьи это двадцать минут работы редактора с текстом в руках.

В голосовом боте человека с текстом в руках нет. Фразу «Иван Семёнович, заказ 48-Т на один миллион двести пятьдесят тысяч с НДС отгрузим к пятнадцатому марта» собирает языковая модель прямо в разговоре, из полей CRM, и отдаёт синтезу как есть. То есть «подготовить текст» превращается из ручной правки в слой кода между моделью и синтезом: склонение чисел и дат, словарь ударений под ваши фамилии, улицы и названия номенклатуры, транслитерация артикулов с латиницей. На демо этот слой не показывают, а именно он решает, услышит клиент «Ёлочку» или «Елочку». Адресов в статье нет, это моё наблюдение: улица с нестандартным ударением ломается так же, как «замок».

«Модель читает символы, а не мысли автора».

Самый живой голос в трубке работает против вас

Самая выразительная модель в тесте, ElevenLabs v3, прочитала те же 289 знаков за 34 секунды против 23 у OpenAI tts-1, а файл генерировала около двадцати секунд против пяти. Для подкаста это плюс: паузы и человеческий темп. В телефонной трубке лишние одиннадцать секунд на абзац — это клиент, который заговорил поверх бота. Про перебивания в статье ни слова, это из наших проектов с голосовыми агентами: чем длиннее и актёрнее реплика, тем чаще её перебивают, и тем важнее, чтобы агент умел замолчать на полуслове и услышать, что ему сказали.

Для бота главная цифра из того же материала другая — время до первого звука. Cartesia Sonic 3.5 отдаёт его примерно за 82 миллисекунды, Deepgram Aura-2 — меньше чем за 90. Автор пишет, что для статьи эти цифры бессмысленны, а для голосового бота это разница между «работает» и неловкой паузой посреди разговора. Оговорюсь: прогон в статье шёл файлом через интерфейс, не потоком, так что двадцать секунд у ElevenLabs — не задержка в звонке, а намёк, что выразительность и скорость тянут в разные стороны; под скорость у них есть Flash и Turbo, звучат проще.

По деньгам, по моим прикидкам из того же прогона: tts-1 — около 2 ₽ за минуту речи бота, v3 — около 13,5 ₽. Цены посредника на 8 сентября, порядок, а не ваш бюджет.

Из России в рублях — SpeechKit, остальное через посредников или на своём железе

Google требует аккаунт в Cloud и зарубежную карту. OpenAI и ElevenLabs — через посредников вроде BotHub, и здесь оговорка: источник и есть статья BotHub с реферальной ссылкой, так что «попробуйте у нас» делите на два. Цифрам прогона при этом верю: списания совпали с их же прайсом.

Yandex SpeechKit с 2026 года живёт внутри Yandex AI Studio: 1 342 ₽ за миллион символов в первой версии API или 0,1626 ₽ за запрос в третьей, причём запрос длиннее 250 символов считается кратно. Всё в рублях, с НДС и закрывающими документами. Для бота тариф «за запрос» ложится естественно: реплика в разговоре почти всегда короче 250 знаков, выходит примерно 16 копеек за фразу — это моя арифметика. Свой голос компании, Brand Voice, там от 101 666 ₽ в месяц за хостинг. Потрогать без регистрации нельзя, автор на этом и застрял.

Если персональные данные клиентов наружу отдавать нельзя — открытые модели на своём железе. Fish Audio S2 Pro звучит лучше всех среди открытых, но коммерческое использование по её лицензии платное; CosyVoice 2 берут за низкую задержку в потоке, то есть как раз под бота. Ни одну из них в боевом звонке я не гонял, цитирую статью. SaluteSpeech от Сбера в сравнении не участвовал, и на этих же фразах я его не проверял.

Проверка за день: двадцать фраз из CRM и секундомер

Источник советует не выбирать голос по образцу с лендинга, а прогнать свой абзац. Для бота я бы сделал так.

Попросите руководителя поддержки или РОПа выгрузить двадцать реальных реплик, которые бот будет произносить: пять с именами клиентов и названиями компаний (с ё и парой иностранных фамилий), пять с суммами с НДС и датами в косвенном падеже, пять с адресами и артикулами, где есть латиница, пять с номерами заказов и телефонов. Прогоните через два-три движка, слушайте только точки ловушек и считайте ошибки на двадцать фраз. Найденное чините в тексте, а не в настройках — скорость и высота тона ударение не исправят.

Потом позвоните на демо-номер каждого вендора с мобильного и дважды перебейте бота на полуслове. Если после своего вопроса успеваете про себя сказать «раз-и» до первого звука ответа — для продаж это долго; порог мой, не из статьи. И третий вопрос вендору, самый неудобный: кто через полгода будет пополнять словарь ударений под нашу номенклатуру.

Ганеш сейчас руководит Kepler, до этого работал в Palantir и Citadel и трижды строил функцию «инженер внутри клиента» — forward deployed engineer, FDE; через его ротацию Project Frontline в Palantir прошло около 250 человек. История с Phoenix в его тексте для Latent Space не про плохую модель данных. Она про то, что никто со стороны продукта не стоял в здании банка, пока система работала на настоящих данных.

Спецификация была, не было никого внутри здания

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

Эту сцену я узнаю без перевода. У нас вместо Cassandra — 1С, а вместо пустой отметки времени — контрагент, заведённый тремя карточками, или остатки, которые «на самом деле» лежат в Excel у кладовщика. В проектах с ИИ и автоматизацией языковая модель ломается последней. Раньше неё ломаются справочники и неписаное правило, чьей цифре верят, когда 1С и CRM расходятся.

У Ганеша для этого слоя есть рамка: собирать существительные и глаголы компании. Существительные — то, что люди считают реальным, и одно понятие в одной фирме носит минимум четыре имени: продажи говорят «клиент», операционка — «заказчик», финансы проводят «плательщика», в коде это org_id, и на каждом стыке прячется перевод, который ломается, как только кто-то меняет определение. Глаголы — как сущности двигаются: что должно быть правдой, чтобы закрыть месяц, кто подписывает исключение в одиннадцать вечера и что происходит, когда он в отпуске.

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

Такое не выясняют на созвоне. Для этого надо сидеть рядом.

Год уговоров против одного вечера наблюдения

Самый полезный эпизод в тексте — маленький. В одном из прошлых стартапов Ганеша почти год не могли перевести клиента с CSV на Parquet, более компактный формат хранения. Блокировала одна инженер по качеству данных, и причина каждый раз звучала иначе: «Parquet хуже», «так не работает», «мне это непонятно».

Потом к ней отправили инженера просто посмотреть, как она работает. Она скачивала CSV из S3 на ноутбук с Windows, открывала двойным кликом и глазами просматривала строки. Это и была проверка качества данных. У Parquet тогда не было просмотрщика, то есть команда год предлагала забрать у человека единственный инструмент и ничего не дать взамен. Просмотрщик написали за вечер, через два дня она согласовала миграцию, обработка ускорилась примерно с семнадцати часов до двух.

Сопротивление внедрению почти никогда не про страх нового — оно про инструмент, который у человека отбирают. Пока вы не увидели, что именно он открывает двойным кликом перед тем, как подтвердить цифру, вы не знаете, что внедряете. По моим прикидкам, в компаниях на 50–300 человек такой «двойной клик» есть в каждом втором процессе — от сверки остатков до счёта, который бухгалтер глазами проверяет перед оплатой. Это ощущение от проектов, не цифра из исследования.

Скрипт на полдня прожил годы и получил имя автора

Вторая история неприятнее. Одному клиенту понадобилась задача по срокам хранения данных, и Ганеш за полдня набросал скрипт vinoo.groovy, которому полагалось не дожить до конца недели. Через год скрипт крутился у клиента почти на сто тысяч человек, с именем автора в названии; команда так и прозвала самого Ганеша. Дыру закрыли, починку в продукт не вернули и годами обслуживали костыль.

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

Подрядчик, который только закрыл дыру, оставил вам свой vinoo.groovy

Оговорка про маркетинг: Ганеш продаёт Kepler, платформу, где у каждой цифры есть происхождение, и рассуждение о «рве» заодно обосновывает его продукт; сам я Kepler не трогал. Развилка от этого не перестаёт быть правдой, и собственника она касается с другой стороны стола.

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

Я бы требовал от подрядчика двух вещей до разговора о моделях. Первая — письменный словарь существительных и глаголов вашего процесса: как одну сущность называют в 1С, в CRM и у бухгалтерии, где стоит проверка глазами и кто её делает. Вторая — список его костылей у вас с датой смерти каждого. У нас в проектах слово FDE никто не произносит, но работа та же: сначала сесть рядом с человеком, который сверяет глазами, и только потом обсуждать, чем это автоматизировать.

Шаг на неделю: попросите подрядчика или своего внутреннего внедренца собрать за день перечень временных обработок и ручных обходов, которые стоят у вас сейчас, с именем автора и датой, когда каждый должен умереть. Если список не появился за день, vinoo.groovy у вас уже есть, просто пока без имени.

Два числа задержки и одно первое место

Задержка зависит от того, какой пост Microsoft читать. Команда Microsoft AI пишет, что первые гипотезы появляются «чуть больше чем через 100 мс» после получения аудио, а слова встают в текст вдвое быстрее, чем у ближайшего конкурента. Блог Foundry осторожнее: «в большинстве случаев» слово видно через 320 мс после произнесения, у конкурентов — больше 500. Компания утверждает, что модель заняла первое место по точности на Artificial Analysis и по финальным, и по промежуточным транскриптам. Издания приводят 2,5% ошибок на финальном тексте, в самом посте Microsoft процентов нет. На публичной стриминговой таблице Artificial Analysis строки с этой моделью при подготовке заметки мы не нашли, TechTimes 2 октября отмечал то же. Пока это замер по методике рейтинга, а не независимая публикация.

Что внутри и чего нет

Статус — публичное превью без SLA, Microsoft сама не рекомендует его для продакшена. Подключение двумя способами: WebSocket, совместимый с Realtime API OpenAI, или Azure Speech SDK. Сессия до часа, звук PCM 16 или 24 кГц, определения конца реплики на сервере нет — когда закрывать фразу, решает клиент. Язык определяется автоматически; в таблице поддержки есть русский, украинский и казахский.

Главное ограничение: потоковая модель не различает говорящих и не ставит пословные таймкоды, в финальных результатах только смещение и длительность сегмента. Диаризацию и таймкоды Microsoft оставила пакетной MAI-Transcribe-2, которая стоит 0,10 $ за час — в пять раз дешевле. Модель отдаётся из трёх регионов Azure (Швеция, центр США, Азия), доступна в Microsoft Foundry, MAI Playground, через Vercel AI Gateway и OpenRouter; LiveKit — «скоро».

Вместе со стримингом вышли два синтезатора речи: MAI-Voice-2.1 за 22 $ за миллион символов и MAI-Voice-2.1-Flash за 15 $; по данным компании, Flash выдаёт 45 секунд речи со сквозной задержкой 150 мс. 23 языка, четыре русских голоса. Клонирование по 5–60 секундам записи открывают только после одобрения заявки и с подтверждённым согласием владельца голоса.

Чего Microsoft не сказала

Цену после конца 2026 года — 0,54 $ объявлены как вводный тариф. Срок выхода из превью. Точность отдельно по русскому — опубликованной нет. Размер модели и данные обучения не раскрыты, весов нет, только API.

Суфлёр менеджеру во время звонка: что меняется для отдела продаж

В проектах по разбору звонков, которые мы делаем для отделов продаж, расшифровка почти всегда идёт постфактум: запись легла в телефонию, ночью её прогнали, утром руководитель видит оценку. Стриминг открывает другой режим — суфлёр: клиент сказал «дорого», и через полсекунды у менеджера на экране лежит ответ из скрипта, а не разбор полётов через неделю. Саму модель я не гонял, и напрямую из России её не взять: Azure с 2022 года не продаёт новые подписки российским компаниям, через OpenRouter или Vercel технически можно, но гонять записи клиентских разговоров через зарубежный шлюз — это уже разговор с юристом про персональные данные. Из доступного потоковое распознавание есть у Yandex SpeechKit и SaluteSpeech, а Whisper локально хорош для разбора после звонка — в реальном времени его приходится костылить. Отсутствие диаризации в телефонии обходится просто: стороны обычно пишутся в разные каналы, и каждый канал идёт отдельным потоком. Действие на неделю: возьмите десять записей реальных звонков, прогоните через SpeechKit или SaluteSpeech и посмотрите, как движок читает ваши артикулы, названия и фамилии — если они разваливаются, суфлёр ставить рано, начните с разбора постфактум.

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

Решение умирает не в людях, а в шве между «договорились» и задачей

Георгий приводит три случая из своей команды, и ломаются они в разных местах. Звонок клиенту: ответственного назвали вслух, но никто не записал — имя держалось в памяти пятерых. Квартальный отчёт: трое написали по разделу, разделы нормальные, а целое — «будто три разных документа склеили скотчем», финальную сборку никто не считал своей. Распределение входящих заявок: вопрос обсуждали три планёрки подряд, ответственного называли, протокол вели, а на четвёртой встрече начинали с того же места.

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

Под это Георгий подводит эксперимент Дарли и Латане 1968 года: студенты через интерком слушали, как у «собеседника» начинается припадок. Когда участник думал, что слушает только он, на помощь шли 85%. При троих — 62%. При шестерых — 31%. Оговорюсь: это эксперимент про чужую беду, перенос на совещания — аналогия автора, не исследование планёрок.

ИИ-протокол закрывает два случая из трёх, и это признаёт сам вендор

Дальше путь к продукту. Онлайн-сервисы расшифровки нормально берут звонок, но встречу в переговорке у клиента надо писать на диктофон и заливать руками, а протокол всё равно переносить в задачи вручную. Умный диктофон Plaud — 14–15 тысяч рублей за штуку, файл в приложение руками, дайджест по коллегам руками, данные на зарубежных серверах. В итоге собрали своё, Аспро Встречи: запись → расшифровка с разделением говорящих → протокол, который правишь сам → задачи коллегам.

Маркетинг от факта отделяется просто. Сравнительная таблица, где свой продукт выигрывает по всем четырём строкам, — маркетинг; так устроена любая вендорская таблица, а сам продукт я не гонял. Факт — механика «транскрипт → решения → задачи в трекер», и от бренда она не зависит: её можно собрать на любом сервисе расшифровки и любой LLM, которая у вас уже есть. Ещё факт: по словам Георгия, первая внутренняя версия путала говорящих и «протокол просто пересказывал встречу вместо того, чтобы разбить решения на задачи». Ровно в этих двух местах ломаются все такие связки, из коробки от этого не застрахована ни одна модель.

Но ключевое для собственника место статьи — третий случай. Протокол вёлся, ответственный стоял, а в строке было «договорились улучшить распределение заявок». Это решение. Задачи в нём нет: непонятно, что делать в понедельник утром. ИИ тут не спасает, он послушно переносит пустоту в трекер — задача «улучшить распределение заявок», ответственный есть, срока нет, критерия закрытия нет. Я таких задач-призраков в чужих Bitrix24 видел достаточно: «проработать вопрос с логистикой», висит полгода, потому что непонятно, что считать закрытием.

Сдвиг у команды случился не от инструмента, а от правила: на встрече фиксировать цель, в конце раскладывать её на шаги. Вместо «улучшить распределение» — «заявка должна попадать к свободному менеджеру, а не к тому, кто первым увидел уведомление». Из такой цели шаги выпадают сами: настроить очередность в CRM, договориться с отделом продаж о новом порядке, предупредить постоянных клиентов о смене менеджера. У каждого шага есть естественный исполнитель и срок.

И второе правило, в статье одной строкой, а на деле главное: ответственного не назначают, а спрашивают «кто берёт?» и держат паузу, даже неловкую. По словам Георгия, в девяти случаях из десяти человек называет себя сам — и берёт задачу иначе, чем тот, на кого показали пальцем. ИИ-протокол этого не умеет в принципе: он назначает. Пауза остаётся ручной работой, автор, к его чести, так и пишет.

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

Трекер у вас уже есть — Bitrix24, amoCRM, Планфикс — и доступ к какой-нибудь модели тоже.

1. Следующую планёрку запишите: встроенной записью в сервисе звонков или диктофоном на телефоне. Расшифровку прогоните через GigaChat, YandexGPT или что у вас стоит, с одним требованием: «выпиши каждое решение; для каждого — действие в повелительном наклонении, фамилия, дата; если чего-то нет, поставь прочерк». Прочерки — карта дырок вашей планёрки; по моим прикидкам, в первый раз их будет больше половины.
2. Последние пять минут встречи — только на вопрос «кто берёт?» по каждому пункту с прочерком. Пауза — часть процедуры, не сбой.
3. В трекер задачи заносит один человек сразу после встречи — не ИИ и не «каждый своё». Десять минут, пока все не разошлись по чатам.
4. В пятницу откройте открытые задачи и найдите те, где глагол — «улучшить», «проработать», «обсудить». Это цели, не задачи: либо раскладываете на шаги, либо закрываете как мусор.

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

Я раньше считал, что вендоры её прячут. Теперь думаю иначе: её нет, потому что подписка — не мешок токенов. Это право занимать модель с какой-то интенсивностью, а сколько токенов при этом набежит, зависит от того, кто сидит за клавиатурой и что делает. Отсюда растёт всё остальное, включая разницу в 12 раз между двумя замерами за одни и те же деньги.

118 миллионов токенов за день, из них 97% — чтение одного и того же

В пользовательском логе Codex, который автор приводит, один запрос развернулся в 11 вызовов модели и 447 699 токенов. За день набежало 118,16 млн токенов и 71% недельной квоты Plus. Но 97,3% входных токенов пришлись на кэш: агент не прочитал 118 миллионов нового текста, он сто раз перечитал один и тот же репозиторий и свои же прошлые шаги.

Отсюда и разнобой в замерах. По подсчёту sites.diy, квота Codex за $20 в пересчёте на четыре недели стоила бы по API $536, квота Claude — $152. Best Value AI намерил 190 млн токенов в неделю у Plus с GPT-5.4 и 15,6 млн у Claude Pro с Opus 4.7 — 2,6 цента за миллион против 32 центов. Модели и нагрузки разные, цифры не сходятся — и оба замера измеряют не подписку, а поведение конкретного человека на ней.

Юристу с одним договором кэш помогает, аналитику с десятью выгрузками — нет

Кэш — это когда модель не перечитывает знакомый контекст по полной цене. Один документ и двадцать вопросов к нему подряд — каждый следующий дешевеет. Агент в репозитории держит в контексте инструкции, код и прошлые шаги — попаданий много. А десять разных выгрузок по очереди — каждый раз новый текст, переиспользовать нечего. Microsoft на данных Copilot даёт около 90% попаданий внутри одного шага агента и 55% между шагами: появились паузы — выгода тает.

В деньгах на примере из статьи: документ в 100 тысяч токенов, повторный вопрос к нему у Fable вдвое дешевле, чем у Astra, при одинаковой цене обычного входа — только за счёт ставки чтения кэша, $0,25 против $1 за миллион. Gemini дешевле обоих и с кэшем, и без; у Astra кэш живёт 30 минут, у Claude — 5.

Перенесу в контору на сто человек (иллюстрация, не кейс). Юрист, который загрузил договор поставки и задаёт к нему двадцать вопросов подряд, — самый дешёвый пользователь: один документ, много обращений, кэш работает на него. Аналитик, который по очереди разбирает десять актов сверки из 1С, — каждый документ новый, кэша нет, но и объём скромный. РОП с тремя письмами в день не упирается ни во что. Единственный, кто реально бьётся о недельный лимит, — разработчик с агентом в коде. OpenAI даёт ориентир: 5–45 сообщений Codex за пять часов на Plus против 100–900 на Pro 20x. У автора на Pro 20x за $200 одна сложная задача на Astra high съела почти всю недельную квоту. На Plus за $20 такой человек, по моим прикидкам, упрётся в стену за день.

И оговорка для тех, кто думает «купим Pro и подключим к Битриксу»: Anthropic прямо запрещает обслуживать пользователей своего приложения через персональную подписку. Дешёвый доступ есть, встроить его в сервис нельзя — это API и другие деньги. Оплата из России — отдельный разговор.

Gemini за $20 решил столько же задач, сколько Fable за $200, только втрое дольше

Из всего собранного автор больше всего доверяет Electricity Bench, и я с ним согласен. Там не считают токены, а дают агенту набор реальных задач и смотрят, сколько решено, за какое время и сколько лимита ушло. На наборе real-world issues v3 из 15 задач Gemini 3.8 Flash на подписке за $20 закрыл столько же, сколько Fable 5.1 за $200, но медианное время почти втрое больше. Astra близок к Fable по скорости, решил меньше.

«Сначала подбираю модель по качеству под задачу, и уже среди тех, что показывают хорошее качество, выбираю по скорости, расходу лимита и цене», — пишет автор.

Я бы добавил один вопрос: ждёт ли человек ответа. Для ночного разбора входящих заявок «втрое дольше» не стоит ничего. Для менеджера, который смотрит на крутящийся курсор, это минуты его зарплаты, помноженные на число запросов в день. У клиентов в дистрибуции и логистике я чаще вижу первый тип — пакетную обработку, где медленная модель за $20 выигрывает у быстрой за $200. Сам эти бенчи не гонял, цифры — из источника.

Вендоры уже щупают, что из подписки за $20 вынести в доплату

По данным за 2025 год, на доллар выручки OpenAI тратила $2,60, Anthropic — $2,16. Ars Technica описывала эксперимент, где Claude Code убирали из Pro для 2% новых регистраций, потом вернули. Fable на Pro оплачивается отдельными кредитами, на Max входит, но не больше 50% недельной квоты. Прогноз автора: базовые тарифы останутся, дорогие агентные сценарии переедут на кредиты и API. Для собственника это значит, что процесс, который держится на «$20 покрывают неограниченного агента», через год может стоить в разы дороже — и что прямо сейчас самый дешёвый момент понять, какая подписка кому нужна.

Шаг на неделю: список всех, кому компания платит или собирается платить за ИИ, и напротив каждого одна строка — работает он над одним документом или проектом или каждый раз над новым, и ждёт ли ответа в реальном времени. Тем, у кого агент в коде, поручите запустить npx ccusage@latest и принести две цифры: токены за неделю и сколько это стоило бы по API. Через неделю у вас карта: кому $20 с запасом, кому $100–200, а кому не подписка, а API.

Селфи загружается один раз, примерить можно даже скриншот

Механика по описанию OpenAI такая. Кнопка «Примерить» показывается на карточках одежды и аксессуаров; после нажатия ChatGPT просит сделать или загрузить селфи (TechCrunch пишет, что подойдёт и фото в полный рост) и генерирует изображение. Снимок сохраняется как референс для следующих примерок — сменить или удалить его можно в настройках: «Персонализация → Референсные фото». Примерить можно и вещь не из выдачи: достаточно загрузить в чат её фото, например скриншот с сайта магазина, и попросить показать, как она сядет.

Картинку делает модель ChatGPT Images 2.5, вышедшая 8 сентября. Компания утверждает, что та лучше сохраняет внешность человека с референсного фото, точнее следует правкам и генерирует до 50% быстрее предыдущей версии. При этом в справке OpenAI стоит прямая оговорка: изображение примерки может не совпадать ни с товаром, ни с внешностью пользователя и не гарантирует размер и посадку — перед покупкой компания советует смотреть замеры продавца и условия возврата.

Избранное работает через значок закладки на карточке: товар уходит в Favorites в библиотеке ChatGPT, там же можно создать папку. По данным TechCrunch, сохранённые товары лежат рядом с картинками примерок. Обе функции доступны в мобильном приложении и в веб-версии.

Выдача без рекламы, оплата — у магазина

Как товары попадают в выдачу, OpenAI описывает в справке по шопингу: результаты подбирает сам ChatGPT под запрос и контекст (включая память и пользовательские инструкции), это не реклама и на них не влияют партнёрства OpenAI; реклама показывается отдельно. Список продавцов по конкретному товару собирается из данных сторонних провайдеров и самих магазинов, а ранжируется по наличию, цене, качеству и тому, продаёт ли магазин вещь как производитель.

Про оплату в анонсе ни слова. Контекст: Instant Checkout — покупка внутри ChatGPT — запущена в сентябре 2025-го, а к марту 2026-го OpenAI, по данным TechCrunch, задвинула её на второй план: «первая версия не дала той гибкости, к которой мы стремимся». Источник The Information объяснял проще — люди не покупали через чат. В справке опция всё ещё упоминается «для некоторых товаров и продавцов», но линия теперь другая. В тот же день 1 октября OpenAI показала опыт Safeway в ChatGPT: корзина собирается в чате, а платить покупатель идёт на сайт сети. Примерочная ложится в ту же схему: ChatGPT — витрина, деньги у ритейлера.

Что OpenAI не раскрыла

Ни в релиз-нотах, ни в справке нет ограничений по тарифам — но и подтверждения, что примерка работает на бесплатном плане, тоже нет. TechCrunch называет запуск глобальным, список стран OpenAI не публикует. Не объяснено, у каких именно карточек появляется кнопка и кто решает, что товар «подходящий». Не сказано, используются ли референсные фото для обучения моделей и есть ли лимит на число примерок; цифр по точности нет. Ритейлеров-партнёров под примерку не названо, интерфейса для магазинов — тоже.

Фото в карточке становится сырьём для чужой примерочной

ChatGPT в России официально недоступен, а российских магазинов в его товарной выдаче я не встречал — специально не проверял, но и ждать трафика от этой кнопки нашим ритейлерам пока неоткуда. Что меняется уже сейчас — требования к фото: примерочная берёт вещь прямо с карточки или скриншота и переносит на человека, поэтому фото в полный рост на ровном фоне без плашек «−30%» из вопроса вкуса превращается в вопрос, обработает ли вашу карточку любая такая нейросеть, не обязательно от OpenAI. С возвратами иллюзий нет: OpenAI сама пишет, что картинка не гарантирует размер и посадку, и отправляет к замерам продавца — примерка снимает сомнение «идёт ли мне», а возвраты по размеру остаются вашей проблемой, и таблица замеров в сантиметрах в карточке теперь важнее лукбука. Действие на неделю: возьмите 20 карточек-бестселлеров и проверьте, есть ли в каждой замеры изделия в сантиметрах и хотя бы одно фото в полный рост на ровном фоне. Если доступ к ChatGPT есть — прогоните три-пять этих фото через «Примерить» со скриншота и посмотрите, что модель сделает с вашей картинкой.

Это замер автора с Хабра под ником donseo: четыре пары текстов (русский оригинал и английский перевод того же смысла), одиннадцать токенизаторов — GPT, Claude, Gemini, DeepSeek, Qwen, GLM, Kimi, Grok, GigaChat и YandexGPT — и пересчёт в рубли за тысячу символов. Сам я замер не повторял, цифры ниже — его.

Миллион токенов у каждой модели — разного размера

Собственник читает таблицу «рублей за миллион токенов» как прайс на топливо: литр — он и есть литр. Токен — не литр. Это кусок текста, на который модель режет вход, и у каждой модели свой нож.

На английском все ножи одинаковые: 5,0–5,1 символа на токен у десяти моделей из одиннадцати, словари учили на английском. На русском разброс пятикратный: от 1,03 символа на токен у Opus 5 до 5,11 у YandexGPT 5 Lite. У GPT-5.x, Gemini, Grok и GLM русский текст занимает на 18–23 % больше токенов, чем английский того же смысла. У DeepSeek — на 38 %, у Qwen — на 52 %, у Kimi — на 86 %. У Opus 5 — почти втрое, и даже на английском у него 3,25 символа на токен против пяти у остальных.

Прайс за миллион токенов — курс валюты, которую вы ещё не умеете конвертировать в свой язык. Автор формулирует жёстче:

«Сравнивать модели по цене за токен без поправки на язык нельзя».

Разрыв с GigaChat и YandexGPT по прайсу выглядит больше, чем в счёте

Это ломает привычный аргумент «российские модели дорогие». GigaChat 2 Max по цене за токен в 2,3 раза дороже GPT-5.5, а по цене за тысячу русских символов — в 1,9 раза: русский текст у него в токенах даже короче английского перевода. YandexGPT 5 Lite по прайсу вдвое дешевле GPT-5.5, а на русском тексте — в 2,6 раза. Kimi K3 тоже вдвое дешевле по прайсу, но на русском разница сжимается до 1,24.

Фрагмент таблицы автора по медианным входным ценам на 27.09.2026:

Множитель токенизатора от провайдера не зависит: сколько бы вы ни платили за токен, русский текст на Opus 5 съест их в 3,9 раза больше. А вот цена за токен от провайдера зависит сильно, автор это оговаривает: на ту же дату Opus 5 у самого дешёвого сервиса стоил 28,5 ₽ за миллион, по медиане — 549; GPT-5.5 — 14,25 ₽ и 552.

Боту поддержки хуже всех, парсеру договоров — терпимо

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

Поддержка и продажи в чатах — как раз «много пишет по-русски». Прикидка, не кейс: допустим, на каждый ответ бота уходит 15 тысяч символов входа — инструкция, выдержки из базы знаний, история диалога. По медианным ценам это 8 ₽ на Opus 5 и 2 ₽ на GPT-5.5. На десяти тысячах ответов в месяц — 80 тысяч рублей против 21, и это до выходных токенов, которые дороже и тоже русские.

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

Приём, который автор предлагает прямо: служебную часть промпта держать на английском. Системная инструкция и описания инструментов с JSON-схемами на английском токенизируются привычно, и для Opus 5 так можно срезать входные токены системной части почти втрое; текст клиента и ответ остаются русскими. У нас в проектах системная часть с правилами и инструментами нередко весит больше самого вопроса. Автор оговаривается, и я с ним: проверьте, не просело ли качество русских ответов.

Побочная находка, которая мне кажется важнее основной, если бюджет у вас считается по кабинету агрегатора. У одного из шлюзов для claude-sonnet-5 и claude-opus-4-8 поле prompt_tokens совпало с подсчётом токенизатора OpenAI до единицы на всех восьми текстах. Либо шлюз пересчитывает токены чужим токенизатором, либо запросы уходят не в ту модель, что указана; снаружи не проверить, и автор убрал эти две модели из таблицы. Расход токенов из кабинета посредника — пока не данные модели, сверить стоит хотя бы раз с открытым токенизатором или с кабинетом разработчика.

Про ограничения: текстов у автора мало, четыре пары примерно по 2 500 символов прозы, коэффициенты на ваших данных сдвинутся на единицы процентов, а GigaChat 2 Max посчитан по токенизатору открытой GigaChat 3. Порядок моделей при этом во всех жанрах один и тот же.

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

Попросите того, кто отвечает за ИИ, штатного или подрядчика, взять десять реальных диалогов поддержки или пять типовых документов и посчитать стоимость тысячи символов для двух-трёх моделей-кандидатов по тарифу вашего провайдера. У OpenAI, GigaChat 3 и YandexGPT 5 Lite токенизаторы открыты, у Anthropic есть бесплатный эндпоинт подсчёта токенов. По оценке автора, вся работа — полчаса. Если вместо этого вам принесут «рублей за миллион токенов» — верните обратно.

Самое полезное в этом кейсе — не цифры сами по себе, а простой вывод: локальная LLM ещё не готова к бизнес-сценарию только потому, что один раз ответила в консоли. Модель может стартовать, API может открываться, а до нормального пользовательского сценария между ними ещё целая куча инженерной работы: память, очереди, streaming, tool calling, мониторинг и поведение под нагрузкой.

Автор статьи как раз это и показывает на живом пилоте: за два дня нужно было поднять две локальные LLM на NVIDIA DGX Spark, отдельную ASR-модель на мини-ПК с AMD GPU и подключить всё к платформе ИскраБота в корпоративном контуре. Заказчик обезличен, результаты — только для этого пилота, и это важная оговорка, а не формальность.

Что именно они подняли

В контуре уже была мультиагентная платформа, и к ней подключили три сервиса: - основную LLM для сложных запросов; - более быструю LLM для служебных и простых задач; - ASR для распознавания аудио и видео.

На двух Spark использовали Qwen3.8-27B-FP8 как основную модель и Qwen3.6-35B-A3B-NVFP4 как fast-модель. Для распознавания речи взяли Qwen3-ASR-1.7B на Radeon 8060S в WSL2. Для LLM выбрали vLLM, чтобы работать через OpenAI-совместимый endpoint /v1/chat/completions, а не писать отдельную интеграцию под каждый runtime.

И вот важный момент: совместимый API ещё не значит совместимое поведение. Особенно когда речь про streaming и tool calling — там «почти работает» быстро превращается в «ломает сценарий».

«модель запустилась» и «AI-функция работает» — это совершенно разные уровни готовности

Где обычно ломается локальное развёртывание

Автор очень правильно раскладывает проблему: модель — это не только веса. Нужны runtime, драйверы, совместимость железа, формат квантизации, chat template, healthcheck, перезапуск, логирование и нормальный API. В их случае Spark — ARM64 на Grace Blackwell с общей памятью CPU/GPU, а ASR-контур — вообще другой стек: AMD + ROCm + WSL2. То есть одинаковая фраза «запустить на GPU» скрывает два разных мира.

Самое важное наблюдение для бизнеса тут простое: большой контекст и высокая скорость почти всегда требуют компромиссов по памяти и параллелизму. В статье прямо видно, что окно 256K пришлось оплачивать параллелизмом: на каждой модели оставили только одну одновременно исполняемую последовательность. Сервер вроде бы выдержал, но очередь тут же стала частью продукта.

Что это значит для бизнеса в России

Для нас это хороший ориентир по приземлению AI-проектов. Если вы хотите локальный контур, то вопрос не в том, «можно ли поднять модель», а в том, какой у вас реальный критический путь: сколько токенов в контексте, сколько пользователей одновременно, где будет очередь, и что важнее — скорость первого токена или стабильность ответа.

По российской практике я бы смотрел на это так: если нужен быстрый старт и не хочется сразу лезть в сложный self-hosted стек, можно пробовать облачные или локально доступные варианты вроде GigaChat / YandexGPT, а для чувствительных контуров — локальные модели и свой runtime. Но если у вас агентная схема с инструментами, историями и длинным контекстом, то без архитектуры бюджета контекста проект быстро упирается в память и задержки.

Отдельно — про данные и 152-ФЗ. В статье этого нет, но в реальных внедрениях именно здесь часто и упираются: локальный inference ещё не значит, что вы автоматически закрыли все вопросы по хранению, доступам и журналированию.

Что я бы проверил у себя на этой неделе

Сам автор честно пишет, что часть вещей ещё не дотянута до production-ready. И это правильная позиция. Я бы на месте собственника попросил команду не «показать демо», а ответить на три вопроса: - сколько токенов реально уходит в системный промпт, инструменты и историю; - что будет, если одновременно придут два длинных запроса; - где у нас очередь, а где реальная скорость модели.

Если руками не гоняли длинный контекст и агентные tool calls, я бы не считал проект готовым. Пока я бы не считал такой стек готовым к боевой нагрузке без собственного прогона длинного контекста и tool calls.

И да, одно действие на неделю: возьмите любой свой AI-сценарий и замерьте не «токены в секунду», а полный путь пользователя — от запроса до полезного ответа. Очень часто там и всплывает настоящая цена локального AI.

У клиента был магазин в Москве, интернет-магазин на InSales и RetailCRM, за которую платили примерно 200 тыс. ₽ в год. При этом на сайте реально продавалось только 89 SKU из 521 своего товара в наличии — 17 %. Остальное витрина показывала как доступное, но в корзину оно не ложилось.

С кем мы работали и что у них болело

Публично это можно называть так: бренд одежды middle-up, 6 лет на рынке, средний чек 40–50 тыс. ₽, около 4 000 клиентов, магазин в Москве + интернет-магазин на InSales + RetailCRM.

Запрос звучал без дипломатии. «Поддержка RetailCRM — это ад на земле», «используем как чатик в телеграме», «проверить не могу, что вы там навайпкодили». И главный смысл был простой: система должна работать на бизнес, а не стоять отдельной дорогой статьёй расходов.

Что было сломано до нас

Мы смотрели не по словам, а по API RetailCRM, МойСклад, InSales и ApiShip.

Самая неприятная часть была в складах. InSales смотрел на сумму остатков по всем складам, поэтому на витрине товар как будто был. А корзина резервировала только с приоритетного склада. Там часто стоял ноль. Отсюда и абсурд: товар виден, но купить нельзя.

Плюс шла двойная запись заказов: один и тот же заказ попадал в МойСклад двумя потоками — из InSales и из RetailCRM, с разницей в 15 секунд. В последних 1 000 заказах мы нашли 69 подтверждённых пар дублей.

Что мы сделали сначала, а что пришлось переделать

Сначала я сам ошибся в одной гипотезе: по аудиту казалось, что Ламоду и ВБ надо отключать от сайта. На звонке клиент объяснила, что это витрина допассортимента, и товар выкупается со склада маркетплейса за день. Этот пункт мы из плана убрали. Хороший пример, почему нельзя лечить склад по скриншоту.

Дальше пошли по порядку:

1. Разобрали схему складов и маппинг между МойСклад и InSales.
2. Зафиксировали, что сайт должен продавать со всех складов, а не только с приоритетного.
3. Перестроили логику так, чтобы RetailCRM была мастером заказов и клиентов, а МойСклад — мастером остатков.
4. Отключили лишнюю загрузку заказов в МойСклад, чтобы не плодить дубли.
5. Склеивание дублей оставили штатными методами CRM, но сразу сказали честно: это не лечит причину, если двойная запись останется.
6. Отдельно добивали доставку: включили вывод веса и габаритов, проставили значения по умолчанию, залили данные в 1 775 вариантов и настроили тарифы по умолчанию для интеграций.

С доставкой было особенно много возни. Механизм в CRM вроде бы уже существовал, но не работал из-за нехватки данных. То есть задача оказалась не «построить с нуля», а «донастроить и не сломать то, что уже живое».

Что изменилось после внедрения

По доставке у нас есть уже подтверждённые тесты:

• 03.08.2026 — автозаявка в СДЭК для курьера, трек 10302327199, сумма 642,50 ₽;
• 03.08.2026 — автозаявка в СДЭК до ПВЗ, трек 10302397901, сумма 667,50 ₽.

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

По складам и дублям итоговые цифры в документах у нас не зафиксированы в виде красивого «было/стало». Я это специально не буду додумывать. Но уже на этапе аудита было видно, что проблема не в «плохой CRM», а в том, что витрина, склад и заказы жили разными жизнями.

Где мы споткнулись

Первое. Код ПВЗ не удалось добить автоматом с первого захода. Пробовали пять подходов: триггеры RetailCRM, HTTP-запрос из CRM в саму CRM, статусные триггеры, «ПВЗ по умолчанию» в модулях СДЭК и ApiShip. В итоге рабочий внешний скрипт мы написали, но потом сняли по решению клиента — запускать его на ноутбуке было ненадёжно, а сервера под это не было. Я бы в следующий раз сразу закладывал нормальный серверный контур, а не надеялся на «ну у меня же ноут всегда включён».

Второе. СДЭК без региона иногда считал не тот адрес. Без региона он видел не Москву, а деревню Москва в Тверской области. В одном из расчётов это давало 2 467 ₽ вместо 642 ₽. Очень бытовая ошибка, но на ней легко сжечь и время, и нервы.

Третье. Мы недооценили, как сильно у клиента уже был испорчен опыт с InSales. После истории с сайтом и интеграциями у них было ощущение, что «всё опять будет стоить дорого и непонятно». Поэтому пришлось не просто чинить, а ещё и очень прозрачно показывать критерии приёмки. Иначе доверие бы не собралось.

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

Что можно перенести к себе

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

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

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

Что произошло

В выпуске Greg Isenberg разговаривает с Ras Mic про GPT-6 Astra. По словам участников выпуска, модель может стоить дороже за задачу, но за счёт меньшего числа шагов итоговая ценность на доллар у неё остаётся высокой. Ещё они отдельно хвалят два сценария: аудит производительности и аудит безопасности для live app.

Аудит производительности перевёл одно из приложений Ras с 800 мс до 20–30 мс.

Аудит безопасности его live payments app нашёл реальные риски в production.

Дальше идёт уже совсем прикладная часть. Greg показывает девять промптов для Astra: часть — для соло-операторов, часть — для управления компанией. Там и агент, который разбирает счета через чат поддержки, и агент, который ищет недооценённые объявления в городе, и еженедельная панель оператора, которая читает документы, Stripe-экспорт и звонки, после чего предлагает три действия с максимальным leverage.

Самый показательный кусок — hardware-проект Ras. Он хотел сделать колонку с agent внутри. Astra помогла пройти путь от идеи до списка комплектующих, раскладки в Blender, схемы проводки, loader code для репозитория и pull request. По их словам, всё заняло около 30 минут, а заказ комплектующих вышел на $561 до налога.

Что здесь неочевидно

Первое: ценность тут не в «умности» модели, а в том, сколько промежуточной ручной работы она съедает. Для бизнеса это важнее, чем очередной красивый ответ в чате. Если агент умеет собрать черновик решения, список деталей, код и PR, у команды резко меняется скорость проверки гипотез.

Второе: они фактически показывают переход от vibe coding к vibe manufacturing. Идея простая — AI начинает помогать не только с софтом, но и с физическими продуктами. Для России это особенно интересно там, где есть свои железки, киоски, терминалы, устройства для логистики, ритейла, безопасности. У нас таких задач хватает, и часто они тонут не в инженерии, а в согласованиях и рутине.

Третье: в выпуске много про агентные сценарии вокруг операционки. Это не про «заменить людей», а про то, чтобы убрать из процесса куски, где люди неделями собирают данные из CRM, телефонии, почты и таблиц. У нас в проектах именно на этом обычно и появляется первый ощутимый эффект.

Что это значит для бизнеса в России

Если смотреть трезво, сам GPT-6 Astra как продукт может быть недоступен или неудобен из РФ, и это уже отдельный вопрос. Но логика применения понятна и без него: аудит производительности, аудит безопасности, еженедельный операционный агент, поиск узких мест в продажах и поддержке.

Для локального стека я бы смотрел в сторону GigaChat, YandexGPT или self-hosted моделей — не потому что они «лучше», а потому что их проще встроить в российскую инфраструктуру, где есть 1С, amoCRM, Bitrix24, телефония и свои ограничения по данным. Если в процессе всплывает персоналка или платежи, 152-ФЗ и контуры хранения данных уже не декоративная тема, а обычная часть проекта.

Честная пометка

Саму Astra я пока не тестировал на живом кейсе. Когда проверю на практике, отдельно напишу, где она реально помогает, а где это просто красивая демка. Но направление мне понятно: не «поговорить с AI», а собрать из него кусок операционного конвейера.

Что бы я сделал на этой неделе

Я бы взял один живой процесс в компании — например, разбор входящих лидов, отчёт по продажам или аудит сайта/приложения — и попросил модель не просто ответить, а выдать: - список рисков; - список узких мест; - 3 действия с максимальным эффектом за 7 дней.

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

Stripe, похоже, сделала ставку не на «умный чатик для сотрудников», а на внутреннюю систему управления доступом, контекстом и рабочими сценариями. И вот это уже похоже на настоящую enterprise-историю: когда AI начинает не отвечать на вопросы, а лезть в данные, строить дашборды и выполнять действия, без слоя governance всё быстро превращается в хаос.

Что произошло

В эпизоде рассказывают про Kai — внутреннего AI-агента Stripe. По словам Sharadh Krishnamurthy, engineering manager в Stripe, Kai используют очень широко внутри компании — речь идёт о тысячах сотрудников каждую неделю. Он работал в инфраструктурных командах Stripe, в том числе в data и developer experience, а сейчас отвечает за слои governance, skills и infrastructure, чтобы AI был доступен сотрудникам с любым техническим бэкграундом.

Авторы эпизода отдельно проговаривают несколько вещей, которые Stripe сделала вокруг Kai: - построила его с нуля, а не купила готовый инструмент; - сделала так, что Kai «знает о вас» по умолчанию, но часть этого можно отключать; - использует projects не как папки, а как механизм governance; - собрала data layer так, чтобы агенты могли безопасно выполнять запросы в масштабе; - дала сотрудникам skills platform, где любой может упаковать workflow, и таких workflow у них уже много — это уже не уровень пилота.

Ещё в выпуске показывают живую демонстрацию: Kai строит dashboard. И отдельно обсуждают неприятный опыт, когда агенты едва не вывели production-системы из строя.

“projects” в Stripe — это механизм governance, а не просто папка.

Что здесь неочевидно

Первое: Stripe, судя по всему, строила не «AI поверх процессов», а саму среду, в которой AI вообще можно безопасно запускать. Это важная разница. Большинство компаний сначала покупают интерфейс, а потом удивляются, почему агенту нельзя доверить ничего серьёзного.

Второе: 2 000 workflow — это уже не игрушка и не пилот. На таком объёме главная проблема смещается с «как заставить модель отвечать» на «как не утонуть в мусорных сценариях, дубликатах и полурабочих автоматизациях». И тут без нормальных evals, telemetry и контроля версий всё разваливается очень быстро.

Третье: инфраструктура, которую Stripe строила для human developers, по их словам, оказалась полезной и для агентов. Это мне кажется самым практичным моментом выпуска. Не надо думать, что для AI нужен полностью новый мир — часто достаточно аккуратно переиспользовать уже существующие слои прав, данных, логирования и sandbox.

Что это значит для бизнеса в России

Для наших компаний вывод довольно приземлённый: если вы хотите не «поиграться с AI», а реально пустить его в работу, сначала надо ответить на скучные вопросы. Кто что видит. Где лежат данные. Что агенту можно делать, а что нельзя. Как откатывать ошибку. Кто отвечает, если он полезет не туда.

И да, здесь почти всегда упираемся не в модель, а в обвязку. В российской реальности это может быть связка из GigaChat или YandexGPT, локальной модели, плюс собственный слой прав, журналирования и sandbox. Если данные чувствительные, 152-ФЗ и контуры доступа всплывают сразу, а не «потом разберёмся».

Для среднего бизнеса самый быстрый эффект обычно дают не «универсальные агенты», а узкие сценарии: дашборд по продажам, сверка статусов, поиск по внутренним регламентам, подготовка черновиков ответов, разбор обращений. Всё, что связано с действиями в CRM, BI и документообороте, уже требует дисциплины, а не энтузиазма.

Честно: сам Kai я ещё не тестировал, но по описанию видно, что Stripe сделала ставку не на магию, а на инженерную дисциплину. Но по описанию видно, что Stripe сделала ставку не на магию, а на инженерную скуку, и именно поэтому у них это вообще взлетело.

Что бы я сделал на этой неделе

Если у вас в компании уже есть AI-эксперименты, я бы взял один рабочий сценарий и описал его как workflow с тремя вещами: входные данные, права доступа, точка остановки человека. Без этого любой «агент» остаётся красивой демкой, а не инструментом.

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

Что произошло

Автор пишет, что весь год использует AI coding assistants для написания кода, но доверяет им не до конца — ограничение не в модели, а в доступе. Если агент добирается до реальной инфраструктуры, он получает слишком много полномочий: shell access, database URL, cloud key.

Kestra предлагает другой подход. Операция описывается в YAML в Git, а агенту отдают не секреты, а список flows, которые ему можно запускать. Каждый вызов возвращается как обычное execution, которое можно открыть и прочитать. В источнике отдельно сказано, что Kestra 2.0 уже вышла, а core остаётся под Apache 2.0.

“Kestra делает это наоборот. Операция описывается в YAML в Git, а agent получает список flows, которые ему разрешено запускать, вместо credentials.”

Что здесь неочевидно

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

Второе: такой подход хорошо ложится на команды, где уже есть дисциплина вокруг Git и workflow. Если у вас всё живёт в чатах, ручных доступах и «ну я потом дам права», магии не будет. Kestra тут скорее усиливает порядок, чем заменяет его.

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

Что это значит для бизнеса в России

Для наших компаний идея довольно приземлённая. Если вы хотите пускать AI в автоматизацию, лучше начинать не с «пусть он сам всё делает», а с режима, где он запускает заранее описанные сценарии без прямого доступа к секретам. Это особенно полезно там, где есть 1С, CRM, телефония, облака и несколько подрядчиков, а доступы раздаются по старой доброй схеме «на всякий случай».

По доступности из РФ я сам не проверял именно этот релиз, но сама логика инструмента не завязана на какой-то экзотический стек. Если нужен аналогичный подход, я бы смотрел в сторону связки с Git, оркестрацией задач и локальными/корпоративными моделями — хоть через GigaChat или YandexGPT, хоть через self-hosted модель, если вопрос в данных и контроле доступа.

И да, 152-ФЗ тут всплывает не из-за моды, а когда агент начинает видеть персональные данные, клиентские базы и внутренние документы. Тогда уже важно не «какой AI красивее», а где лежат данные и кто может их трогать.

Что бы я сделал на этой неделе

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

Сам ещё не гонял именно Kestra 2.0 в бою, как проверю — напишу. Но сама идея мне нравится: сначала ограничить радиус ошибки, а уже потом расширять полномочия. В AI-автоматизации это обычно и есть взрослая версия внедрения.