Антон Фокин

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

Спор «заменит / не заменит» уводит не туда. ИИ в продажах работает не там, где отношения и закрытие сделки, а на рутине вокруг них: квалификация входящих по критериям, обогащение лида данными, расшифровка звонка в CRM, напоминание о follow-up, черновик письма. Это не «ИИ-продавец», это разгрузка живого продавца от бумажной работы, чтобы он занимался людьми, а не вводом данных. Работает ровно то, что измеримо и узко: «сократили квалификацию с 10 минут до 1». Не работает — «ИИ, найди нам клиентов» и «ИИ, продай». Правильный вопрос не «заменит ли», а «какой кусок воронки у вас руками делается зря»

Роман выше верно про «автоматизируют хаос». Добавлю вторую причину, почему именно 95% и почему «молчат»: у большинства не было базовой метрики ДО. Внедрили ИИ — а с чем сравнивать? Не замерили, сколько времени, ошибок и денег было без него, поэтому не могут ни доказать выигрыш, ни честно признать провал — отсюда и молчание. «Слили» и «окупилось» в цифрах выглядят одинаково, если точку отсчёта не зафиксировали. Второй капкан — пилот на демо-данных взлетел, а в проде на реальном мусоре и нагрузке рассыпался, бюджет уже потрачен. Рабочий порядок обратный: сначала метрика и маленький кусок процесса с замером, потом масштабирование того, что реально сдвинуло цифру

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

Хороший пример именно потому, что он редкий по правильной причине. Смотрите, почему тут ИИ сработал, а у «95% компаний» нет: узкая задача с однозначным критерием успеха (цена — либо дешевле, либо нет) и относительно чистые входные данные (прайсы, номенклатура). Идеальные условия. ИИ проваливается там, где задачу ставят размыто («улучшить закупки вообще») и кормят хаосом. Так что вывод из вашего кейса не «ИИ находит цены», а полезнее: берите не самую амбициозную задачу, а самую измеримую и с чистыми данными — тогда эффект виден в деньгах, как у вас. Это и отличает окупившиеся 5% от молчащих 95%

Идея правильная, менеджеры реально ненавидят ручной ввод. Но дьявол в точности извлечения, а не в самой транскрибации. Распознать речь сейчас несложно; сложно — вытащить из живого диалога, где перебивают и говорят «ну да, где-то на следующей неделе», структурированные поля CRM без выдумывания. Два места, где ломается: диаризация (кто сказал — менеджер или клиент, иначе бот запишет обещание клиента как обещание менеджера) и обработка низкой уверенности — что делает система, когда не расслышала сумму или дату. Мы собирали пайплайны речь→текст→структура (транскрибация + диаризация + LLM-разбор), и там правило простое: не уверен — не пиши в поле, подсвети менеджеру на подтверждение. Иначе CRM красиво заполнена мусором, и доверие к ней падает быстрее, чем экономится время

PinMyWay выше задал ключевой вопрос, который обычно замалчивают — отказоустойчивость самого интеграционного слоя. Шина решает «паутинку», но сама становится единой точкой отказа: легла шина — встали все обмены разом, а не одна связка. Поэтому важнее не «шина vs точка-точка», а паттерн доставки: transactional outbox на стороне источника (событие пишется в его же БД в одной транзакции с данными, потом публикуется) + идемпотентные консьюмеры. Тогда падение шины на 5 минут не теряет и не двоит заказы — они доедут после подъёма. Без этого шина — просто красиво нарисованная единая точка отказа

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

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

Правильная постановка. Но «не упасть при отказе ЦОД» на практике упирается не в дублирование серверов, а в данные и состояние. Compute поднять на второй площадке несложно; сложно — не потерять и не задвоить транзакции в момент переключения и чтобы реплика по данным не отставала так, что после failover вы работаете на устаревшем. Второй больной вопрос — а это вообще проверяли? Отказоустойчивость, которую не гоняли учениями (реально гасили узел под нагрузкой), — это бумажка. Мы нагрузочно валили узлы, чтобы увидеть, где рвётся раньше железа — на своей видеосвязи держали сотни параллельных подключений именно так: https://qtim.pro/projects/onlayn-shkola-1-vks. Как у вас проверяется failover — плановые учения или надежда на регламент?