За полтора года я собрал шесть продуктов с ИИ. Самое сложное оказалось научить систему говорить "Я не знаю".
Я Михаил, фулстак разработчик из Москвы, вот самое крутое, что я делал :)
RAG-система поддержки из 104000 старых тикетов. Сотрудник пишет в телеграм, система находит похожие решения и отвечает на основе тикетов, а если не уверена, то передает вопрос оператору. В данных клиента тикет закрывался в среднем за 47 часов, и ассистент нацелен на то, чтобы ответ происходил за секунды
Система умного поиска для Портала Поставщиков города Москвы. Покупатель вводит запрос, а система понимает, что он имел ввиду и показывает самые подходящие товары. Она исправляет опечатки, знает синонимы и сокращения, учитывает историю закупок пользователя и то, что он ищет прямо сейчас. Каждый результат сопровождается пояснением, почему он находится именно на этом месте. Также система учится на действиях всех пользователей: если многие по запросу "бумага для подарков" выбирают упаковочную бумагу, следующий покупатель получит этот товар выше
Система мониторинга цен по трем маркетплейсам (Озон, Яндекс Маркет, WB)
Бот в телеграм для психологического клуба, который превращает платную рекламу в подписчиков канала и показывает, какая реклама окупается. Человек приходит по рекламной ссылке, бот проверяет подписку на канал и выдает материалы. Затем по расписанию присылает цепочку сообщений. Администратор клуба управляет всем сам, без программиста, через панель в самом боте: меняет материалы, тексты и расписание, смотрит статистику и делает рассылки
Сейчас работаю над медицинской платформой, которая распознает документы с результатами лабораторных анализов, автоматически обрабатывает их и хранит в личном кабинете пользователя эти данные. Можно смотреть динамику отдельных показателей, определять доступ к данным. Отвечаю за бэкенд и инфраструктуру, включая защиту данных и разграничение прав
Ищу заказы на разработку ПО, удаленно. Делаю веб-приложения, бэкенд и интеграции от идеи до работающей системы. Особенно интересны проекты с ИИ-функциями и данными, за которыми стоят люди, где нужно думать про безопасность и сохранность личных данных
Если у вас есть идея или задача, но пока непонятно, с чего начать - напишите мне. Бесплатно разберу вашу задачу, составлю ТЗ, в там посмотрим, чем я могу быть полезен
· 9 ч
Самая дорогая версия «я не знаю» — когда система уверенно продолжает workflow после того, как потеряла основание для вывода. Я бы проверял это отдельным набором ситуаций, где правильный результат — остановиться: конфликт источников, отсутствующее обязательное поле, устаревшие данные или выход за область полномочий.
И отдельно — что происходит после отказа: пользователь понимает, чего не хватает и как продолжить, или получает просто тупик? Тогда abstention становится не красивой фразой модели, а проверяемым состоянием продукта.
1
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 8 ч
Спасибо, хорошее уточнение. Частично мы это проверяли. У нас был отдельный набор запросов, где правильный результат это остановиться: проблема, которой нет в базе или которая слишком редкая, явная просьба позвать оператора и оффтоп. По нему подбирали порог передачи вопроса человеку.
С тем, что происходит после отказа, тупика нет. Если ответ не помог, бот сам собирает детали и создаёт заявку, а оператор получает карточку с похожими решениями из базы. Размытые запросы бот сначала уточняет, а не передаёт сразу.
А вот конфликт источников, отсутствие обязательного поля и устаревшие данные мы отдельно не проверяли. Индекс обновлялся раз в сутки, но актуальность самих ответов не оценивали. Это наше слепое пятно, и я возьму ваш список в следующий набор проверок.
1
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 1 ч
Михаил, вот это уже очень сильный ответ: у вас отказ не заканчивает сценарий, а переводит его в управляемую эскалацию с собранным контекстом для оператора. Отдельно полезно, что вы различаете размытый запрос и случай, где системе действительно не хватает основания.
Для проверки актуальности я бы добавил не только возраст индекса, но и возраст самого подтверждающего факта: база могла обновиться сегодня, а решение внутри тикета уже устарело. Хороший минимальный тест — два формально похожих ответа с разной датой или политикой и требование либо выбрать актуальный с объяснением, либо остановиться при конфликте.
Будет интересно узнать, сколько прежних уверенных ответов такой набор переведёт в уточнение или эскалацию.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 2 мин
Спасибо, хорошее уточнение про возраст самого факта, а не только индекса. Для нас это пробел: даты внутри тикета мы не учитывали, поэтому два похожих ответа с разной датой система не различает. Сколько прежних ответов такой тест перевёл бы в эскалацию, я не измерял, цифры назвать не могу. Тест с парами разной даты и политики оставляю как идею для следующей версии.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён