Продажи

«Лучше пять раз переспросить, чем один раз выдумать» — я посадил ИИ-ассистента отвечать коллегам в рабочем мессенджере

Обложка: «Лучше пять раз переспросить, чем один раз выдумать» — я посадил ИИ-ассистента отвечать коллегам в рабочем мессенджере

Всем привет! Меня зовут Александр, я руковожу направлением аналитики страховой вертикали в Банки.ру. Наша вертикаль живёт в отчётах и данных: продажи ОСАГО и КАСКО, ипотечное страхование, кроссы, пролонгация, воронки, кэшбэк и сверки с партнёрами. И каждый день в рабочем мессенджере на меня прилетает поток одного и того же жанра: «где посмотреть КВ по ОСАГО за сентябрь?», «почему упало одобрение у страховой?», «сделай выгрузку по регионам», «это у нас баг или так и задумано?». КВ здесь комиссионное вознаграждение. Постепенно аналитик превращается в справочное бюро. Ответы есть, но живут они в голове, в SQL-запросах и в вики, а вопросы приходят в личку и в каналы в любой момент, в том числе пока ты на встрече. Я решил посадить на эту очередь ИИ-ассистента. Условие одно и жёсткое: ассистент не выдумывает. В аналитике выдуманная цифра хуже отсутствия ответа, потому что по ней примут решение.

Читать далее

ZOLT JOURNAL / ДАЛЬШЕ

Обложка: Зачем голосовому боту на LLM снова нужен классификатор вроде Jev
ПродажиHabr AI

Зачем голосовому боту на LLM снова нужен классификатор вроде Jev

Голосовой бот на LLM разговаривает приятно, но на реальных звонках регулярно спотыкается. Он может найти свободное окно и так и не записать клиента или перебить человека, который просто задумался посреди фразы. Часть таких решений можно снять с LLM и отдать быстрой модели-классификатору. Самая обсуждаемая из них сейчас Jev от TypeSafe, и у нее уже появились открытые аналоги. Ниже разбираю, как Jev-подобные модели применяют в голосовых ботах другие команды, и сравниваю их кейсы с нашим опытом в Voximplant.

Обложка: Speech Analytics: почему сервис речевой аналитики может правильно распознать разговор и неправильно его оценить
ПродажиHabr AI

Speech Analytics: почему сервис речевой аналитики может правильно распознать разговор и неправильно его оценить

Одна из самых распространенных ошибок при выборе системы речевой аналитики — оценивать ее по качеству расшифровки аудио. Загрузили запись. Получили текст. Несколько терминов распознаны неправильно, но в целом разговор читается. Кажется, что основная техническая задача решена. На практике самое интересное начинается после транскрибации. Допустим, клиент спрашивает менеджера: — А есть возможность интеграции с нашей CRM? — Да, такая возможность предусмотрена. — А сколько времени это займет? — Обычно недолго. С точки зрения распознавания здесь почти нечего обсуждать. Даже простая ASR‑модель может восстановить такой диалог достаточно точно. А теперь попросим систему оценить качество консультации. Менеджер ответил на вопрос? Да. Выяснил, какая CRM используется? Нет. Уточнил требования к интеграции? Нет. Назвал конкретный срок? Нет. Договорился о следующем действии? Нет.

Обложка: Как я написал линтер для Model Context Protocol (MCP) и нашел баги в официальных серверах Anthropic
ПродажиHabr AI

Как я написал линтер для Model Context Protocol (MCP) и нашел баги в официальных серверах Anthropic

Если вы пишете MCP-серверы для Claude Desktop или Cursor, то знаете, как легко поймать неочевидный баг: • Случайный console.log() в stdout ломает JSON-RPC протокол и наглухо вешает клиент. • Если у опасного инструмента (удаление БД/файлов) нет аннотации destructiveHint, агент выполнит его без подтверждения пользователя. • В описания инструментов можно зашить Prompt Injection, который заставит модель слить контекст. Написал mcp-linter (без единой сторонней зависимости, чистый Node.js/TS): — 34 правила проверки протокола и безопасности — Оценка здоровья сервера от A+ до F (0-100) — Генератор автоисправлений (–fix) — Экспорт в SARIF v2.1.0 для GitHub Security и готовый GitHub Action Попробовать в одну строку: npx mcp-linter – npx -y @modelcontextprotocol/server-memory Репозиторий: https://github.com/bakhtiyor-aminzoda/mcp-doctor Обезопасить себя