ух, фильтрация фейков – это отдельная задача, там надо не только на текст смотреть, но и на время публикации, мб 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 например
"напишите нам в личку, и мы проигнорируем" :)
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
А, или речь идет о картинке с Lineage? Такие штуки рисует https://getdbt.com/