Одним-единственным ботом обойтись неудобно, если нужно одновременно чатиться с несколькими клиентами. Нужно как-то организовать в мессенджере множество чатов для агента. Можно было бы через группы с одним ботом сделать, но тогда их на каждого агента придётся индивидуальные плодить.
Подключить другой мессенджер можно. Нужно реализовать соответствующий фронтенд (клиентский или агентский). Можно по образцу телеграмного посмотреть, как он должен работать.
LLM-ка будет встраиваться в зависимости от того, как именно вы хотите её использовать. Подозреваю, что это будет изменение в бэкенде — классификация и либо отправление в очередь заявок как обычно, либо автоответ.
Я в шоке не столько от того, какой это глупый сексистский поток сознания, сколько от того, что Хабр постит это в свои соцсети. Хабр, ты норм? Может, хватит слово «айтишник» в унизительное превращать?
1) LoadBalancer приводит трафик на поды, поднятые ингресс-контроллером (т. е. непосредственно в контейнеры с nginx/traefik/...), а они уже смотрят на существующие в системе ингрессы и роутят куда нужно.
2) Если мы подняли сервис, балансировка будет происходить только если обращаться по урлу, соответствующему всему сервису — <имя сервиса>.svc.cluster.local. Но помимо такого урла Kubernetes создаёт урлы для всех подов сервиса, чем мы и пользуемся, обращаясь напрямую в statefulset-0.mongodb-service.default.svc.cluster.local. Такие урлы с фиксированными именами подов мы можем использовать для конфигурирования базы данных.
Не совсем понял. Чтобы получить произведение каждого разряда на множитель, вам уже нужно операций. В любом случае нужно умножить каждый разряд одного числа на каждый разряд другого.
Он легко обосновывается через арифметику по модулю! Берем число, скажем, 123. Нам нужно выяснить, равен ли нулю его остаток от деления на три. Раскладываем по десятичным разрядам и пользуемся свойством, что :
Нынче все собеседования онлайн, можно взять идентификатор и поиском по странице проверить, что он везде одинаково написан. Базовый навык пользования браузером опять-таки.
Вы химик/врач?
Нет, не рассматривал. Звучит интересно.
Привет!
Одним-единственным ботом обойтись неудобно, если нужно одновременно чатиться с несколькими клиентами. Нужно как-то организовать в мессенджере множество чатов для агента. Можно было бы через группы с одним ботом сделать, но тогда их на каждого агента придётся индивидуальные плодить.
Подключить другой мессенджер можно. Нужно реализовать соответствующий фронтенд (клиентский или агентский). Можно по образцу телеграмного посмотреть, как он должен работать.
LLM-ка будет встраиваться в зависимости от того, как именно вы хотите её использовать. Подозреваю, что это будет изменение в бэкенде — классификация и либо отправление в очередь заявок как обычно, либо автоответ.
Хороший старт!
В статью бы пару примеров кода, чтобы глазу было за что зацепиться.
Интерактив с названием статьи ?
Вы проверили этот подход на своей компании? Без описания личного опыта «плюсы сильно перевешивают минусы» не звучит достаточно веско.
Я в шоке не столько от того, какой это глупый сексистский поток сознания, сколько от того, что Хабр постит это в свои соцсети. Хабр, ты норм? Может, хватит слово «айтишник» в унизительное превращать?
Конкретно у меня нет, но материалов по теме много. Вот кто-то поддерживает Kubernetes-оператор для Кассандры, вот большая статья про подводные камни.
1) LoadBalancer приводит трафик на поды, поднятые ингресс-контроллером (т. е. непосредственно в контейнеры с nginx/traefik/...), а они уже смотрят на существующие в системе ингрессы и роутят куда нужно.
2) Если мы подняли сервис, балансировка будет происходить только если обращаться по урлу, соответствующему всему сервису —
<имя сервиса>.svc.cluster.local. Но помимо такого урла Kubernetes создаёт урлы для всех подов сервиса, чем мы и пользуемся, обращаясь напрямую вstatefulset-0.mongodb-service.default.svc.cluster.local. Такие урлы с фиксированными именами подов мы можем использовать для конфигурирования базы данных.А можно ссылку на Гиппарха? Интересно почитать
Ну, сами исследования все давно опубликованы, моя оригинальная тут только подача. Хотел написать с тех пор, как статья про алгоритм за
вышла.
Вы не согласны с тем, что это факт, или с тем, что он занимательный?)
Не совсем понял. Чтобы получить произведение каждого разряда на множитель, вам уже нужно
операций. В любом случае нужно умножить каждый разряд одного числа на каждый разряд другого.
Он легко обосновывается через арифметику по модулю! Берем число, скажем, 123. Нам нужно выяснить, равен ли нулю его остаток от деления на три. Раскладываем по десятичным разрядам и пользуемся свойством, что
:
При работе разработчиком каждый день нужно до чего-то догадываться!
Нынче все собеседования онлайн, можно взять идентификатор и поиском по странице проверить, что он везде одинаково написан. Базовый навык пользования браузером опять-таки.
Так ведь dense это и есть дополнительный неупорядоченный список.
Не знаю, как сделать юниформ проще, если нужно сохранить возможность быстро добавлять и удалять элементы из сета.
Нет, не более умное, ровно так) Просто в традиционном хешсете это за О(1) вообще нельзя сделать.
В sparse set ещё можно быстро случайный элемент генерировать.