Классный камент, спасибо что подробно раскрыли тему
Для начала соглашусь – ассистент, который отвечает "мне жаль" на любой вопрос – это плохой пример работы ассистента. Причина таких ответов скорее всего в том, что ИИ реально не знает, почему заказ опаздывает – он на складе застрял? или в доставке? Кстати, иногда и человеческие операторы техподдержки не имеют такой информации.
Про логику ответов ассистента Мы обычно инструктируем ассистента отвечать так, чтобы дополнительно дораскрывать намерение пользователя.
Например, если человек спрашивает, есть ли курсы для начинающих, ответ "да, есть" или "нет, нету" – вполне корректный. Но мы стараемся продолжить разговор, сказать, мол, да, курсы есть, вот смотри какие в наличии, что тебе больше нравится?
Про ссылки Ассистент знает ссылки на первоисточники всегда – и это очень важно. При этом да, пользователю эти ссылки не всегда нужны – и мы можем проинструктировать ассистента ссылки в явном виде не давать, и это тоже ок.
Зачем вообще ассистент
Чтобы закрывать скучные, но ценные штуки:
Сбор заказа по списку товаров (например, когда в почту приходит список из 40 позиций заказа, а кому-то надо этот заказ аккуратно собрать)
Ответы на вопросы о статусе чего угодно (если, например, у ассистента есть возможность сделать API-call и этот статус реально получить)
Замена человеческого эксперта для типовых вопросов (которых обычно бывает около половины из всех запросов в техподдержку)
ух, фильтрация фейков – это отдельная задача, там надо не только на текст смотреть, но и на время публикации, мб IP отправителя, возраст аккаунта и кучу еще всего. У нас было пару таких подходов, но это отдельная большая тема
Теоретически да, просто ответ LLMки на языке оригинала тяжелее проверять. Например вот такой отзыв если ты не знаешь испанского – он какой тональности? "¡Tienen una comida brutal, de chuparse los dedos! Por las noches caemos seguido en su restaurante."
Да, шкала конечно влияет на оценки. В статье я скорее о том, как анализировать уже полученные данные, а не о выборе идеального формата. Но да, согласна - если шкала слишком длинная, это действительно может добавить шума
Хорошее замечание! Тональность действительно может меняться при переводе. В статье я рассматривала общий принцип, но комментарий отлично дополняет тему, в сложных случаях действительно надо учитывать такие нюансы)
Text-to-SQL да, работает, но с одним нюансом: он генерирует SQL, который технически корректный и исполняется. Насколько этот SQL учитывает нюансы бизнес-логики и позволяет получить ответ, корректный с бизнес-точки зрения – это вопрос.
Наверное, это будет работать при хорошо и однозначно документированных полях в БД, но нужно очень тщательно тестировать, прежде чем выставлять инструмент на бизнес-пользователей. Excel в этом смысле пока гораздо надежнее.
Да, у Метабейз тоже это есть. Но конечно с моделями внутри BI-системы надо аккуратнее быть: на большом объеме данных это может быть медленно и/или дорого.
А мне кажется что это и человек никак не понимает) Мы даем тестовое всем и проверяем независимо от того, насколько плохо написано резюме, какой у человека опыт, как он выглядит, сколько ему лет итп. И оцениваем по результатам тестового.
Мы считаем некорректным вываливать на кандидата сразу весь поток информации о компании, графике, режиме работы и прочем – на это не всегда есть запрос.
А чат-бот на все эти вопросы ответит, если его спросить.
Когда незнакомый вам рекрутер, с которым вы общаетесь, просит отправить резюме, вы ведь, скорее всего, уважаете его просьбу и резюме таки отправляете. Про личность этого рекрутера вы, скорее всего, знаете не больше, чем про чат-бота. Если ваше резюме размещено на hh.ru, то оно уже доступно непонятно кому ?♀️
Добрый вечер, есть опыт использования tap-facebook, он в актуальном состоянии, но для того чтобы он нормально работал, нужно зарегистрировать приложение на фейсбуке и получить расширенный доступ для ads_read и Ads Management Standard Access.
Звучит как комментарий человека, знакомого с концепциями! :)
Мы сначала реализуем каждый атрибут независимо, но потом из независимых атрибутов собираем 1) широкую таблицу на анкер, просто left join‘ом всех атрибутов на анкер 2) широкую таблицу со всеми линками (по возможности).
То есть, когда появляется ещё один атрибут, мы добавляем ещё одну строчку left join’а в таблице анкера.
Это удобно для аналитики, для отображения в Metabase и sql-запросов.
Ща, погодите, у Singer же архитектура какая: - есть tap'ы – они для сбора данных из источников - есть target'ы – они для заливки данных в destination
Ну и соответственно если нужно данные из vk, например, залить в clickhouse, то надо взять tap-vk (например, наш), и target clickhouse. Target clickhouse кажется гуглится – https://www.npmjs.com/package/target-clickhouse например
Классный камент, спасибо что подробно раскрыли тему
Для начала соглашусь – ассистент, который отвечает "мне жаль" на любой вопрос – это плохой пример работы ассистента. Причина таких ответов скорее всего в том, что ИИ реально не знает, почему заказ опаздывает – он на складе застрял? или в доставке? Кстати, иногда и человеческие операторы техподдержки не имеют такой информации.
Про логику ответов ассистента
Мы обычно инструктируем ассистента отвечать так, чтобы дополнительно дораскрывать намерение пользователя.
Например, если человек спрашивает, есть ли курсы для начинающих, ответ "да, есть" или "нет, нету" – вполне корректный. Но мы стараемся продолжить разговор, сказать, мол, да, курсы есть, вот смотри какие в наличии, что тебе больше нравится?
Про ссылки
Ассистент знает ссылки на первоисточники всегда – и это очень важно.
При этом да, пользователю эти ссылки не всегда нужны – и мы можем проинструктировать ассистента ссылки в явном виде не давать, и это тоже ок.
Зачем вообще ассистент
Чтобы закрывать скучные, но ценные штуки:
Сбор заказа по списку товаров (например, когда в почту приходит список из 40 позиций заказа, а кому-то надо этот заказ аккуратно собрать)
Ответы на вопросы о статусе чего угодно (если, например, у ассистента есть возможность сделать API-call и этот статус реально получить)
Замена человеческого эксперта для типовых вопросов (которых обычно бывает около половины из всех запросов в техподдержку)
"напишите нам в личку, и мы проигнорируем" :)
positive / negative / neutral / дебри многоуровневого троллинга
ух, фильтрация фейков – это отдельная задача, там надо не только на текст смотреть, но и на время публикации, мб IP отправителя, возраст аккаунта и кучу еще всего. У нас было пару таких подходов, но это отдельная большая тема
Теоретически да, просто ответ LLMки на языке оригинала тяжелее проверять. Например вот такой отзыв если ты не знаешь испанского – он какой тональности?
"¡Tienen una comida brutal, de chuparse los dedos! Por las noches caemos seguido en su restaurante."
Да, шкала конечно влияет на оценки. В статье я скорее о том, как анализировать уже полученные данные, а не о выборе идеального формата. Но да, согласна - если шкала слишком длинная, это действительно может добавить шума
Хорошее замечание! Тональность действительно может меняться при переводе. В статье я рассматривала общий принцип, но комментарий отлично дополняет тему, в сложных случаях действительно надо учитывать такие нюансы)
Text-to-SQL да, работает, но с одним нюансом: он генерирует SQL, который технически корректный и исполняется. Насколько этот SQL учитывает нюансы бизнес-логики и позволяет получить ответ, корректный с бизнес-точки зрения – это вопрос.
Наверное, это будет работать при хорошо и однозначно документированных полях в БД, но нужно очень тщательно тестировать, прежде чем выставлять инструмент на бизнес-пользователей. Excel в этом смысле пока гораздо надежнее.
Какие сейчас AI BPA самые годные?
Да, у Метабейз тоже это есть. Но конечно с моделями внутри BI-системы надо аккуратнее быть: на большом объеме данных это может быть медленно и/или дорого.
А мне кажется что это и человек никак не понимает) Мы даем тестовое всем и проверяем независимо от того, насколько плохо написано резюме, какой у человека опыт, как он выглядит, сколько ему лет итп. И оцениваем по результатам тестового.
Ваше право!
Но да, соглашусь, что подход к найму senior-специалистов может отличаться.
Мы считаем некорректным вываливать на кандидата сразу весь поток информации о компании, графике, режиме работы и прочем – на это не всегда есть запрос.
А чат-бот на все эти вопросы ответит, если его спросить.
Когда незнакомый вам рекрутер, с которым вы общаетесь, просит отправить резюме, вы ведь, скорее всего, уважаете его просьбу и резюме таки отправляете. Про личность этого рекрутера вы, скорее всего, знаете не больше, чем про чат-бота.
Если ваше резюме размещено на hh.ru, то оно уже доступно непонятно кому ?♀️
Добрый вечер, есть опыт использования tap-facebook, он в актуальном состоянии, но для того чтобы он нормально работал, нужно зарегистрировать приложение на фейсбуке и получить расширенный доступ для ads_read и Ads Management Standard Access.
Звучит как комментарий человека, знакомого с концепциями! :)
Мы сначала реализуем каждый атрибут независимо, но потом из независимых атрибутов собираем 1) широкую таблицу на анкер, просто left join‘ом всех атрибутов на анкер 2) широкую таблицу со всеми линками (по возможности).
То есть, когда появляется ещё один атрибут, мы добавляем ещё одну строчку left join’а в таблице анкера.
Это удобно для аналитики, для отображения в Metabase и sql-запросов.
Ща, погодите, у Singer же архитектура какая:
- есть tap'ы – они для сбора данных из источников
- есть target'ы – они для заливки данных в destination
Ну и соответственно если нужно данные из vk, например, залить в clickhouse, то надо взять tap-vk (например, наш), и target clickhouse. Target clickhouse кажется гуглится – https://www.npmjs.com/package/target-clickhouse например
Или вопрос в другом?
Да ну ой, это тезис про качественные и количественные данные что ли?
Ну как откуда данные! На дашборд посмотрели, там график "средний чек заказа по дням" – и вон, видно же, что упал! :)
Привет! Легко:
- https://github.com/epoch8/tap-yandexdirect
- https://github.com/epoch8/tap-vk
Если будут вопросы – пишите olga@epoch8.co