Как основу использовать можно, но если сообщений много, будет дорого за счет API LLM. Для такого лучше использовать что-то более специализированное. Как пример вот из этой статьи.
У меня недавна была статья именно на эту тему. Но по требованию этой доски объявлений статью забанили. Самое что смешное, в ней использовался их официальный API и не описывались спорные способы, просто запросы к официальному API. Если кратко - через их официальный API вполне реально работать, если либо ограничивать количество запросов, либо работать с нескольких IP, чтобы не превышать лимит и их правила. А вот использовать вещи описанные в этой статье лучше не стоит, у них продвинутые антибот алгоритмы, лучше работать корректно через инструменты, которые они сами дают.
Да, думаю, в следующей статье про Mini Apps опишу подробнее подключение оплаты и сам проект сделаю чуть более серьёзный. С PostgreSQL и интерфейсом из реального кейса.
Что вы имеете ввиду, под ffmpeg. Он спокойно и легко добавляется через Dockerfile, об этом есть в документации подробная инструкция. Да и это же не про n8n, а скорее про разных ботов на питоне
Можно, никаких проблем нет. Но на своем компьютере это больше для отладки и экспериментов. Если нужна работа 24/7, обычно, размещают на удаленном сервере
Благодарю, да, действительно, на продуктовых базах данных, это так просто не работает. Нужно будет реализовавывать дополнительную логику и делать подробное описание таблиц и столбцов
В n8n не обязательно использовать GPT от OpenAI. Можно даже поднять локально легкие сетки, но будет медленно и ограниченно по задачам из-за соответсвующего качества. Или использовать разные решения, доступные на нашем рынке. Думаю, когда кто-то начнет предоставлять DeepSeek как сервис c оплатой в рублях, будет проще, а пока нужно разные обходные варианты искать. Но как минимум LLAMA на 70 млрд. параметров на нашем рынке есть, она конечно уступает последним сеткам OpenAI, но для многих задач подойдет
Ключевое слово - свой отдел эксплуатации. И свои DevOps. Если эти два отдела есть, жизнь становится проще. Но не многие могут себе позволить эти два отдела. Об этом и статья
Даже если взять ваши цифры, основная стоимость упирается не в железо, а в DevOps. Т.е. результат расчета принципиально не изменится. Облака вас избавляют от необходимости самостоятельного развертывания Kubernetes, настройки бэкапов (и так, чтобы он был рабочий) и т.д. Плюс, многие вещи (условная распределенная СУБД с синхронизацией по атомным часам у AWS) вы самостоятельно просто не сможете сделать
Я опубликовал эту статью в нашем корпоративном блоге. Никто же ничего не скрывает. Логично, что деплой я приведу на нашем примере и немного похвалю компанию в которой работаю, а не конкурентов. Но вы можете взять код бота и развернуть его в том облаке/хостинге, который вам нравится
Heroku эти принципы под себя писали. К примеру в российском аналоге - Amvera, релиз разделен на два шага, но интеграционное тестирование вынесено на строну GitHub/GitLab. Т.е. там проходят все тесты, а в сервисе производится сборка и запуск. И в целом получилось по функционалу аналогично. И так можно почти по каждому из 12 принципов сказать
Да, не вижу сложностей, только если каптчу не нужно проходить.
В данной реализации парсинга, лучше ограничивать количество запросов, иначе будет прилетать 429 ошибка.
Как пример, вот как в этой статье - https://habr.com/ru/companies/amvera/articles/838204/
Как основу использовать можно, но если сообщений много, будет дорого за счет API LLM. Для такого лучше использовать что-то более специализированное. Как пример вот из этой статьи.
Так и называлась "Парсинг Ави... без ограничений по запросам". Но её скрыли, к сожалению.
У меня недавна была статья именно на эту тему. Но по требованию этой доски объявлений статью забанили. Самое что смешное, в ней использовался их официальный API и не описывались спорные способы, просто запросы к официальному API. Если кратко - через их официальный API вполне реально работать, если либо ограничивать количество запросов, либо работать с нескольких IP, чтобы не превышать лимит и их правила. А вот использовать вещи описанные в этой статье лучше не стоит, у них продвинутые антибот алгоритмы, лучше работать корректно через инструменты, которые они сами дают.
А лимит запросов к API Binance без авторизации и авторизацией сильно отличается?
Да, думаю, в следующей статье про Mini Apps опишу подробнее подключение оплаты и сам проект сделаю чуть более серьёзный. С PostgreSQL и интерфейсом из реального кейса.
Было бы еще полезно дополнить статью инструкцией по обновлению n8n. Инструкция, как сделать update n8n есть в официальной документации по ссылке.
Что вы имеете ввиду, под ffmpeg. Он спокойно и легко добавляется через Dockerfile, об этом есть в документации подробная инструкция. Да и это же не про n8n, а скорее про разных ботов на питоне
Digital Ocean заблокирован в России, его использование может привести к тому, что некоторые нужные интеграции в n8n не будут работать.
Спасибо за внимательность. По Open WebUI планирую следующую статью сделать, откуда и ссылку случайно скопировал. И потом обзор со сравнением
Можно, никаких проблем нет. Но на своем компьютере это больше для отладки и экспериментов. Если нужна работа 24/7, обычно, размещают на удаленном сервере
Благодарю, да, действительно, на продуктовых базах данных, это так просто не работает. Нужно будет реализовавывать дополнительную логику и делать подробное описание таблиц и столбцов
В n8n не обязательно использовать GPT от OpenAI. Можно даже поднять локально легкие сетки, но будет медленно и ограниченно по задачам из-за соответсвующего качества. Или использовать разные решения, доступные на нашем рынке. Думаю, когда кто-то начнет предоставлять DeepSeek как сервис c оплатой в рублях, будет проще, а пока нужно разные обходные варианты искать. Но как минимум LLAMA на 70 млрд. параметров на нашем рынке есть, она конечно уступает последним сеткам OpenAI, но для многих задач подойдет
Ключевое слово - свой отдел эксплуатации. И свои DevOps. Если эти два отдела есть, жизнь становится проще. Но не многие могут себе позволить эти два отдела. Об этом и статья
Даже если взять ваши цифры, основная стоимость упирается не в железо, а в DevOps. Т.е. результат расчета принципиально не изменится. Облака вас избавляют от необходимости самостоятельного развертывания Kubernetes, настройки бэкапов (и так, чтобы он был рабочий) и т.д. Плюс, многие вещи (условная распределенная СУБД с синхронизацией по атомным часам у AWS) вы самостоятельно просто не сможете сделать
Думаю, ему сейчас пригодится не это
Я опубликовал эту статью в нашем корпоративном блоге. Никто же ничего не скрывает. Логично, что деплой я приведу на нашем примере и немного похвалю компанию в которой работаю, а не конкурентов. Но вы можете взять код бота и развернуть его в том облаке/хостинге, который вам нравится
Heroku эти принципы под себя писали. К примеру в российском аналоге - Amvera, релиз разделен на два шага, но интеграционное тестирование вынесено на строну GitHub/GitLab. Т.е. там проходят все тесты, а в сервисе производится сборка и запуск. И в целом получилось по функционалу аналогично. И так можно почти по каждому из 12 принципов сказать