Спасибо за вопрос! да, я сам устал от нейрохайпа и последнее чего хотел в этой статье это хайпануть на этом кейсе) мне кажется вы не совсем поняли основную мысль, возможно у вас не много опыта работы с курсором или ии агентами. монорепо, гит, несколько разработчиков - да мы так и работаем в командах над другими проектами. естественно. здесь же попытка именно интегрировать заказчика и его команду в работу. ведь в каждом проекте кроме разработке как правило работает ещё куча народу, например, дизайнер, маркетологи, сммщики, да и сам ceo. эти люди не станут учить гит, да и они в большенстве своём впервые видят чат с ии агентом. то есть мы их с нуля учим,с азов как писать промты. вот и как это всё сделать с обычным гитом?) что бы не ходить далеко приведу пример. ui дизайнер от заказчика заходит на сервер через курсор, у него локально на сервере крутится поднятый в докере контур превью на локальном хосте, то есть то состояние приложения которое находится в разработке на данный момент и его можно потрогать в браузере. дизайнер видит проблему, допустим кнопка не того цвета. он в этом курсоре использует mcp browser, выделаяет кнопку - ему сразу курсор даёт ссылку на контейнер где находится эта кнопка в html коде страницы (то есть прям на строки кода). далее он формирует задание для фронта от нашей команды. в задание ссылка на код и комментарий мол так и так "поправь цвет кнопки пжлст". альтернативный флоу - дизайнер начинает писать комменты в фигме, использовать какие то сторонние инструменты. и это я привёл уж очень простой пример. на деле конечно же в более сложных ситуациях польза ощутимей... к слову я щас работаю над тем что бы дизайнер вообще мог с помощью агента сам перекрасить кнопку, создать ПР - и это всё по одному промту. а фронт потом просто пришел в гите и апрувнул этот ПР (или поправил), и влил в дев ветку или куда то ещё. собственно это щас в работе и об этом сделаю следующий пост... пока исследуем
он выбрал такой вариант потому что основной вариант это через stripe - иметь юрлицо в евросоюзе/штатах. телеграмм конечно очень распространен в ес и штатах
eventHandler ты имеешь ввиду в формате некой парадигмы? просто ты скинул пример на php а я на python пишу, соответственно ничего не понял. для питона есть библиотека telethon и у неё есть events. по идее работать должно так (ещё не пробовал):
Когда я регистрирую обработчики событий Telethon автоматически подписывается на обновления от Telegram. Эти обновления передаются через открытое соединение, и когда появляется новое сообщение, которое соответствует моим критериям фильтрации (например, сообщение из определенной группы), Telethon вызывает мойобработчик событий. то есть нет отдельных запросов.
Соответственно вопрос, какие в этом случае лимиты?
500 групп без премиума и 1000 с премиумом ? Просто уточняю
у меня нет задачи сделать парсинг интерактивным. я просто забираю раз в час сообщения сообщения из групп и после их обрабатываю. мне кажется реагировать на каждое сообщение это плохая идея.. ведь это отдельный запрос. а так я за один запрос забираю например 30 сообщений из группы.
Спасибо! крутая инфа! в моём случае я не так много парсю, не думаю что будут проблемы. я щас взял нормальный акк и прокси, второй день всё ок.. а есть смысл вступить в те группы которые парсю?
я использовал tdata. да и ещё без проксей.. видимо аккаунт бы заспамленный. а вы можете примерно мне сказать какие ограничения на парсинг. то есть насколько я щас понял, за один запрос я могу достать из группы разное кол-во сообщений (это регулируется limmit) - здесь есть какое-то ограничение от телеги? и соответственно есть ограниение по запросам. я щас сделал так. Запускаю for по списку групп, внутри for использую while True собираю из каждойй группы за один запрос партию в 30 сообщений - пишу их в текстовый файлик. Использую offset_id для того что бы знать на каком сообщение остановилась предыдущая партия. выглядит как то так: async for message in client.iter_messages(group, limit=30, offset_id=offset_id): Так же я проверяю что бы у меня парсились сообщения написанные не старше часа: if message.date < datetime.datetime.now(datetime.timezone.utc) - datetime.timedelta(hours=1):
Ну и эту функцию запускаю раз в час. Другими словами каждый час парсю этот список групп
@xtrime Добрый день. Заинтересовало ваше уточнение к посту
[UPDATE 2023-10-08]Важное напоминание: Телеграмм не разрешает парсить аудиторию каналов. Используя серверный клиент можно получить только те данные, которые видны в обычном, оффициальном приложении.
откуда такая информация? не нашёл ничего подобного в интернете. У меня первый опыт парсинга ТГ, задачка заключается в том что бы с определённых групп спарсить текст сообщений и id их авторов. По какой-то причине столкнулся с блокировкой. Я думал что ограничения ТГ не касаются парсинга в принципе!
Вся соль заключается в этой фразе из вашего замечания " А во втором случае мы имеем корпус из 5 текстов и, если слово встречается во всех 5 текстах, то знаменатель будет равен 5. " . Вы не учитываете числитель - то есть кол-во текстов в коллекции (корпусе).
Давайте на примере. Предположим слово t - "бедолага" - редкое слово с негативной эмоциональной окраской, которое редко встречается в текстах, допустим 3-го класса, всё как в примерах из статьи.
Считаем его idf. Кол-во документов в колл. для 3-го класса - 40000 - это числитель.
первый случай - пять раз в одном тексте (500 слов) - в знаменателе 1. 40000/1 = 40000
второй случай - по одному разу в пяти текстах длинной 100 слов - в знаменателе 5. 40000/5 = 8000.
Есть разница? Стоит упомянуть что
Для каждого уникального слова в пределах конкретной коллекции документов существует только одно значение IDF.
Можно посмотреть подробно описание формулы tfidf в вики
Спасибо! Матрица здесь используется в качестве метрики взаимотношения между классами при предсказание, визуализироемое с помощью тепловой карты - на ней показано кол-во предсказаний класса всеми имеющимися классами. То есть к примеру в последней картинке: 5ый класс предсказан 5ым (верно) 3266 раз, а 4ым (не верно) 344 раза.
Спасибо за замечание, я думал об этом. В моём случае был набор данных за 319 дней
с 1 августа 21года по 15 июня 22го. Набор и так маленький. Если, скажем, рассматривать отдельно зиму, то это выйдет 90 дней, а если ещё убрать выходные и праздники - так совсем маленькая выборка выйдет. Я же ограничился только выделением рабочих и не рабочих дней. Было бы у меня 3 года хотя бы наблюдений - думаю, я бы поступил как вы говорите.
Конечно было бы интересно рассмотреть статистику исходя из менструальных циклов.. Но увы) на такое ИО разрешения не дал..
События на Украине был прям существенным выбросом - на недели 3.. Но это жизнь и нельзя просто взять и выкинуть 3 недели из данных
пожалуйста. если не сложно, сделайте палец вверх статье. а то мне минусов наставили и я честно говоря не понимаю почему...)
Спасибо за вопрос! да, я сам устал от нейрохайпа и последнее чего хотел в этой статье это хайпануть на этом кейсе)
мне кажется вы не совсем поняли основную мысль, возможно у вас не много опыта работы с курсором или ии агентами.
монорепо, гит, несколько разработчиков - да мы так и работаем в командах над другими проектами. естественно.
здесь же попытка именно интегрировать заказчика и его команду в работу. ведь в каждом проекте кроме разработке как правило работает ещё куча народу, например, дизайнер, маркетологи, сммщики, да и сам ceo. эти люди не станут учить гит, да и они в большенстве своём впервые видят чат с ии агентом. то есть мы их с нуля учим,с азов как писать промты. вот и как это всё сделать с обычным гитом?)
что бы не ходить далеко приведу пример. ui дизайнер от заказчика заходит на сервер через курсор, у него локально на сервере крутится поднятый в докере контур превью на локальном хосте, то есть то состояние приложения которое находится в разработке на данный момент и его можно потрогать в браузере. дизайнер видит проблему, допустим кнопка не того цвета. он в этом курсоре использует mcp browser, выделаяет кнопку - ему сразу курсор даёт ссылку на контейнер где находится эта кнопка в html коде страницы (то есть прям на строки кода). далее он формирует задание для фронта от нашей команды.
в задание ссылка на код и комментарий мол так и так "поправь цвет кнопки пжлст". альтернативный флоу - дизайнер начинает писать комменты в фигме, использовать какие то сторонние инструменты.
и это я привёл уж очень простой пример. на деле конечно же в более сложных ситуациях польза ощутимей...
к слову я щас работаю над тем что бы дизайнер вообще мог с помощью агента сам перекрасить кнопку, создать ПР - и это всё по одному промту. а фронт потом просто пришел в гите и апрувнул этот ПР (или поправил), и влил в дев ветку или куда то ещё. собственно это щас в работе и об этом сделаю следующий пост... пока исследуем
он выбрал такой вариант потому что основной вариант это через stripe - иметь юрлицо в евросоюзе/штатах.
телеграмм конечно очень распространен в ес и штатах
спасибо тебе добрый человек. а то я здесь камнем искры высекаю...
eventHandler ты имеешь ввиду в формате некой парадигмы? просто ты скинул пример на php а я на python пишу, соответственно ничего не понял. для питона есть библиотека telethon и у неё есть events. по идее работать должно так (ещё не пробовал):
Когда я регистрирую обработчики событий Telethon автоматически подписывается на обновления от Telegram. Эти обновления передаются через открытое соединение, и когда появляется новое сообщение, которое соответствует моим критериям фильтрации (например, сообщение из определенной группы), Telethon вызывает мойобработчик событий. то есть нет отдельных запросов.
Соответственно вопрос, какие в этом случае лимиты?
500 групп без премиума и 1000 с премиумом ? Просто уточняю
у меня нет задачи сделать парсинг интерактивным. я просто забираю раз в час сообщения сообщения из групп и после их обрабатываю. мне кажется реагировать на каждое сообщение это плохая идея.. ведь это отдельный запрос. а так я за один запрос забираю например 30 сообщений из группы.
Спасибо! крутая инфа! в моём случае я не так много парсю, не думаю что будут проблемы. я щас взял нормальный акк и прокси, второй день всё ок.. а есть смысл вступить в те группы которые парсю?
я использовал tdata. да и ещё без проксей.. видимо аккаунт бы заспамленный. а вы можете примерно мне сказать какие ограничения на парсинг. то есть насколько я щас понял, за один запрос я могу достать из группы разное кол-во сообщений (это регулируется limmit) - здесь есть какое-то ограничение от телеги? и соответственно есть ограниение по запросам.
я щас сделал так. Запускаю for по списку групп, внутри for использую while True собираю из каждойй группы за один запрос партию в 30 сообщений - пишу их в текстовый файлик. Использую offset_id для того что бы знать на каком сообщение остановилась предыдущая партия. выглядит как то так:
async for message in client.iter_messages(group, limit=30, offset_id=offset_id):
Так же я проверяю что бы у меня парсились сообщения написанные не старше часа:
if message.date < datetime.datetime.now(datetime.timezone.utc) - datetime.timedelta(hours=1):
Ну и эту функцию запускаю раз в час.
Другими словами каждый час парсю этот список групп
@xtrime Добрый день. Заинтересовало ваше уточнение к посту
откуда такая информация? не нашёл ничего подобного в интернете. У меня первый опыт парсинга ТГ, задачка заключается в том что бы с определённых групп спарсить текст сообщений и id их авторов. По какой-то причине столкнулся с блокировкой. Я думал что ограничения ТГ не касаются парсинга в принципе!
AI Assistant использует gpt3.5 особенного толку от него нет в отличие от copilot который использует 4ку. плюс AI Assistant хорошая интеграция с ide
https://www.youtube.com/watch?v=xnwi2WMEvbM
собес в яндекс был?)
Вот она где собака зарыта)) Это я описался! Как обычно, смотрю в книгу и вижу фигу...
Спасибо вам большое за то что поправили меня! Дико извиняюсь что завёл вас в заблуждение. Статью поправил
Хорошо что вы спросили. Спасибо за вопрос!
Вся соль заключается в этой фразе из вашего замечания " А во втором случае мы имеем корпус из 5 текстов и, если слово встречается во всех 5 текстах, то знаменатель будет равен 5. " . Вы не учитываете числитель - то есть кол-во текстов в коллекции (корпусе).
Давайте на примере. Предположим слово t - "бедолага" - редкое слово с негативной эмоциональной окраской, которое редко встречается в текстах, допустим 3-го класса, всё как в примерах из статьи.
Считаем его idf. Кол-во документов в колл. для 3-го класса - 40000 - это числитель.
первый случай - пять раз в одном тексте (500 слов) - в знаменателе 1. 40000/1 = 40000
второй случай - по одному разу в пяти текстах длинной 100 слов - в знаменателе 5. 40000/5 = 8000.
Есть разница? Стоит упомянуть что
Можно посмотреть подробно описание формулы tfidf в вики
По поводу нормального распределения мне бы тоже было интересно услышать предположения)
Я перепробовал кучу вариантов, почему выстрелил именно этот объяснить не могу((
Спасибо! Матрица здесь используется в качестве метрики взаимотношения между классами при предсказание, визуализироемое с помощью тепловой карты - на ней показано кол-во предсказаний класса всеми имеющимися классами. То есть к примеру в последней картинке: 5ый класс предсказан 5ым (верно) 3266 раз, а 4ым (не верно) 344 раза.
Надо бы там побывать) в Приморье
Здравствуйте
В Приморье не был никогда. Честно говоря, уже не вспомню почему такой выбор)
ахах
есть такое))
Спасибо за замечание, я думал об этом. В моём случае был набор данных за 319 дней
с 1 августа 21года по 15 июня 22го. Набор и так маленький. Если, скажем, рассматривать отдельно зиму, то это выйдет 90 дней, а если ещё убрать выходные и праздники - так совсем маленькая выборка выйдет. Я же ограничился только выделением рабочих и не рабочих дней. Было бы у меня 3 года хотя бы наблюдений - думаю, я бы поступил как вы говорите.
Конечно было бы интересно рассмотреть статистику исходя из менструальных циклов.. Но увы) на такое ИО разрешения не дал..
События на Украине был прям существенным выбросом - на недели 3.. Но это жизнь и нельзя просто взять и выкинуть 3 недели из данных