Антон Фокин

Редкий случай, когда ИИ прикладывают ровно туда, где он окупается быстрее всего. Нормализация мастер-данных — идеальная задача для LLM: рутинная, объёмная, с проверяемым результатом (запись либо сматчилась с эталоном, либо нет), и человек остаётся на спорных случаях. Причём это внедрение с двойной отдачей: помимо прямой экономии на ручной чистке, оно готовит почву для всех следующих ИИ-проектов — которые в большинстве компаний проваливаются именно об грязные справочники, задвоенных контрагентов и «Иванов И.И. / Иванов Иван / ИП Иванов» в трёх системах. Мы это видим постоянно: бизнес хочет «ИИ-аналитику» и «ИИ-агентов», а начинать надо с того, о чём эта статья, — иначе умная надстройка честно воспроизводит бардак подложки. Единственное, что добавил бы: доля автоматического мэтчинга — не главная метрика; главная — сколько ложных слияний (два разных контрагента склеены в одного) ушло в прод. Одно такое слияние в финансовых данных стоит дороже, чем тысяча несмёрженных дублей

Это лучший сюжет про вайбкодинг за последнее время — не «собрал приложение за вечер», а «не-технарь самостоятельно дошёл до инженерной дисциплины». Удаление тестов агентом — классика: модель оптимизирует «чтобы прошло», а самый короткий путь к зелёному билду — убрать то, что краснеет. Вы упёрлись ровно в то, что отличает игрушку от процесса: агенту нельзя доверять контроль над механизмом, который его же проверяет. Отсюда общее правило, до которого команды доходят обычно после пары инцидентов: проверяющие механизмы (тесты, линтеры, CI-конфиги) должны быть вне зоны записи агента — защищённые файлы, отдельное ревью на их изменение, а в идеале тесты меняет только человек или отдельный процесс с подтверждением. Показательно, что эта потребность настигла даже проект без разработчиков: дисциплина разработки не исчезает с приходом ИИ — она просто становится обязанностью того, кто остался у руля, даже если он «не программист»

Полезная штука — руководители правда не хотят заходить в 1С ради одной цифры. Но подсвечу момент, который в таких ботах решает всё и о котором в статье не увидел: ролевая модель. В 1С права выстроены жёстко — кто какие отчёты видит, до копейки. Бот, который отвечает в Telegram, легко становится обходом этой модели: написал боту — получил цифры, которые в самой 1С тебе бы не показали. Правильная архитектура — бот наследует права конкретного пользователя 1С (авторизация с маппингом TG-аккаунта на учётку), а не ходит в базу под одной служебной учёткой с полным доступом. Плюс аудит запросов: кто, что и когда спрашивал — финансовые данные в мессенджере без этого через полгода превращаются в неуправляемую дыру. Скорость «10 секунд» ценна, только если под ней та же дисциплина доступа, что в самой учётной системе.

Тема, в которой мы сами по другую сторону стола, поэтому добавлю критерий, который заказчики почти никогда не проверяют, а он предсказывает успех сильнее портфолио: как подрядчик ведёт себя при плохих новостях. Портфолио показывает лучшие проекты; правду о работе с подрядчиком вы узнаете в первый момент, когда что-то пойдёт не так — а на проекте длиннее трёх месяцев так будет обязательно. Проверяется это до подписания: спросите про проект, который у них НЕ получился, и что они сделали; попросите показать, как выглядит их отчёт о проблеме (не о успехе); обратите внимание, торгуется ли подрядчик за реалистичные сроки на пресейле или обещает всё, что попросите. Кто на пресейле соглашается со всем — тот и о проблемах будет молчать до последнего. Мы у себя эту логику упаковали в чек-лист выбора подрядчика — там и про модели сотрудничества, и про красные флаги в договоре: https://vc.ru/dev/2916865-kak-vybrat-podryadchika-po-razrabotke

Честно — конкретных значений по пику под рукой не осталось. Тот прогон Go против Node мы делали под свою задачу, для себя, а не как материал под публикацию, поэтому стенд, профиль нагрузки и метрики отдельно не сохранили.

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

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

подпишусь, чтобы не пропустить

Руслан, спасибо — и вам за повод копнуть глубже.
Из того, что мало кто разбирает: почему точная предиктивная модель часто ничего не меняет в бизнесе. Прогноз есть, а действия по нему нет — переход «3 → 4» упирается не в алгоритм, а в то, кто и что делает, когда модель уже что-то сказала. Вот эта «последняя миля» и съедает ROI.

Или с обратной стороны — когда ML не нужен, и обычный BI обыгрывает модель. Все пишут «как дорасти», почти никто — «как понять, что расти пока рано».

Вот это будет действительно интересно почитать)

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

Согласнен. UTC плюс исходная таймзона, и повторить оба локальных времени перед созданием. Это та ошибка, которую каждый календарный бот совершает ровно один раз, а потом чинит навсегда. И ваш последний пункт — «безопаснее передать подтверждение человеку, чем молча выбрать запасную» — я бы вообще вынес из частного случая таймзон в главный принцип таких ботов: молчаливый выбор при неопределённости всегда хуже вопроса. Причём это касается не только момента создания события. Сорванная встреча из поста — это ведь обычно не «время неправильно записали», а «после создания никто не следил»: участник не подтвердил, в чате договорились перенести, а календарь остался старый. Бот, который умеет только создавать, делает половину работы — замкнутый цикл это когда он же за пару часов до встречи проверяет статус (все ли подтвердили, не сдвинулось ли) и, по вашему же принципу, при любой странности не решает сам, а дёргает человека

«Может» — потому что мы не стали ждать, пока «стал»)

Если серьёзно, то по формулировке поймали честно. Но решение было не постфактум «уперлись в проде → переписали», а по профилю нагрузки заранее. Медиаконтур — это маршрутизация RTP, шифрование каждого пакета, обработка потоков (WebRTC/SFU), то есть CPU-bound работа. Event loop однопоточный: под десятками параллельных потоков растёт не столько средняя задержка, сколько джиттер и хвосты — ровно то, что рвёт звук и картинку на созвоне. Это видно из профиля ещё до того, как оно «станет» в бою.

Поэтому и «может»: на API, авторизации и бизнес-логике Node живёт прекрасно (там I/O), а на медиа мы сознательно ушли на Go — ради предсказуемой задержки и контроля над соединениями. Чтобы это «стало» ловили мы в своих тестах, а не пользователь — по качеству связи