Forwarded from DevFM
Python import: Advanced Techniques and Tips
Импорты в питоне могут стать головной болью начинающего разработчика, особенно при переходе от запуска в IDE разработчика на чужую машину. Полезно один раз детально разобраться в этой теме. В статье рассматриваются разные вопросы работы с пакетами в питоне. Доступен перевод в двух частях: часть 1, часть 2.
Начинается статья с базового описания модуля как пространства имён и применения dir для его исследования. Далее объединение модулей в пакет и разные варианты импорта.
В статье также подробно освещаются следующие темы:
— абсолютные и относительные импорты. На практике относительные импорты — зло, PEP8 рекомендует применять абсолютные импорты в большинстве ситуаций
— import path и порядок поиска модулей
— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения
— динамические импорты, которые позволяют перезагружать модули во время работы приложения. Такой способ позволяет реализовать плагинную структуру путём подключения произвольных модулей с кодом на лету
— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте
— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать
— использование профилировщика для импортов. На нашей практике, импорты не становились узким местом приложения. Но если важна скорость старта скрипта, знание о профилировании импортов будет полезным
Заход на правильную организацию импортов был в посте об анализаторах кода.
#python
Импорты в питоне могут стать головной болью начинающего разработчика, особенно при переходе от запуска в IDE разработчика на чужую машину. Полезно один раз детально разобраться в этой теме. В статье рассматриваются разные вопросы работы с пакетами в питоне. Доступен перевод в двух частях: часть 1, часть 2.
Начинается статья с базового описания модуля как пространства имён и применения dir для его исследования. Далее объединение модулей в пакет и разные варианты импорта.
В статье также подробно освещаются следующие темы:
— абсолютные и относительные импорты. На практике относительные импорты — зло, PEP8 рекомендует применять абсолютные импорты в большинстве ситуаций
— import path и порядок поиска модулей
— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения
— динамические импорты, которые позволяют перезагружать модули во время работы приложения. Такой способ позволяет реализовать плагинную структуру путём подключения произвольных модулей с кодом на лету
— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте
— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать
— использование профилировщика для импортов. На нашей практике, импорты не становились узким местом приложения. Но если важна скорость старта скрипта, знание о профилировании импортов будет полезным
Заход на правильную организацию импортов был в посте об анализаторах кода.
#python
Realpython
Python import: Advanced Techniques and Tips – Real Python
The Python import system is as powerful as it is useful. In this in-depth tutorial, you'll learn how to harness this power to improve the structure and maintainability of your code.
Forwarded from Aleksei Tarasov
Была статейка про инит весов. Говорят сота и уменьшает влияние сидов на финальный результат
https://arxiv.org/abs/2110.12661
https://arxiv.org/abs/2110.12661
Forwarded from Karim Iskakov - канал (Karim Iskakov)
Как сделать свой ChatGPT
Думаю все (или абсолютное большинство), кто это читает, уже попробовали ChatGPT. Я лично пользуюсь им почти каждый день и чувствую пользуи деградацию.
Но в один момент там появились конские лимиты сообщений, типа 2 сообщения в час. Потом адские задержки. Потом меня там вообще забанили. Да и вообще, чаты в веб-интерфейсе – это кусок💩
И я сделал свой удобный ChatGPT в телеграме! Притворяться браузером и делать запросы в их интерфейс – не вариант (лимиты, да и бан никто не отменял). Поэтому я решил построить ChatGPT на основе ее базовой модели – GPT-3, благо у нее есть API.
Немного ликбеза. GPT-3 – это большая языковая модель (LLM), которая умеет только одно: принимать на вход текст и писать к нему продолжение. ChatGPT в свою очередь построен на базе GPT-3, но он еще умеет поддерживать контекст в чате, что является game changer'ом🏆 (бешеный хайп на ChatGPT подтверждает это, ведь до него, GPT-3 была уже доступна около года, но всем было пох).
Получается, задача сводится к тому, чтобы научить GPT-3 поддерживать контекст. А сделать это очень просто с правильным промптом. Например, таким:
Далее засовываем это в API в GPT-3 и получаем ответ. Сохраняя вопросы-ответы, мы можем каждый раз вставлять историю диалога в наш промпт, и так GPT-3 будет знать весь контекст. Это работает очень хорошо и почти неотличимо от ChatGPT.
Внизу поделюсь ссылкой на свой репозиторий с телеграм ботом, куда вы сможете вставить OpenAI API ключ и наслаждаться общением с AI в уютном телеграмчике. А первым 10 комметаторам дам доступ в свой поднятный бот (только не обанкротьте меня там, плз 🥲).
P.S.: Если душнить, то ChatGPT в отличии от GPT-3 была дополнительно зафайнтьюнина на диалоговых данных + дообучена на ответахкенийских рабочих за 2$/час разметчиков с помощью RLHF. Но мои тесты показали, что похоже это все нацелено не на улучшение качества и полезности ответов, а на то, чтобы в OpenAI не подали в суд (за то, что их модель с удовольствием рассказывает людям как угнать машину).
*Еще в комменты закину несколько приколюх
🔗 ChatGPT Telegram Bot (GitHub)
🎒 @karim_iskakov
Думаю все (или абсолютное большинство), кто это читает, уже попробовали ChatGPT. Я лично пользуюсь им почти каждый день и чувствую пользу
Но в один момент там появились конские лимиты сообщений, типа 2 сообщения в час. Потом адские задержки. Потом меня там вообще забанили. Да и вообще, чаты в веб-интерфейсе – это кусок
И я сделал свой удобный ChatGPT в телеграме! Притворяться браузером и делать запросы в их интерфейс – не вариант (лимиты, да и бан никто не отменял). Поэтому я решил построить ChatGPT на основе ее базовой модели – GPT-3, благо у нее есть API.
Немного ликбеза. GPT-3 – это большая языковая модель (LLM), которая умеет только одно: принимать на вход текст и писать к нему продолжение. ChatGPT в свою очередь построен на базе GPT-3, но он еще умеет поддерживать контекст в чате, что является game changer'ом
Получается, задача сводится к тому, чтобы научить GPT-3 поддерживать контекст. А сделать это очень просто с правильным промптом. Например, таким:
As an advanced chatbot named ChatGPT, your primary goal is to assist users to the best of your ability. This may involve answering questions, providing helpful information, or completing tasks based on user input.
User: What is the meaning of the Nero Burning ROM logo?
ChatGPT:
Далее засовываем это в API в GPT-3 и получаем ответ. Сохраняя вопросы-ответы, мы можем каждый раз вставлять историю диалога в наш промпт, и так GPT-3 будет знать весь контекст. Это работает очень хорошо и почти неотличимо от ChatGPT.
Внизу поделюсь ссылкой на свой репозиторий с телеграм ботом, куда вы сможете вставить OpenAI API ключ и наслаждаться общением с AI в уютном телеграмчике. А первым 10 комметаторам дам доступ в свой поднятный бот (только не обанкротьте меня там, плз 🥲).
P.S.: Если душнить, то ChatGPT в отличии от GPT-3 была дополнительно зафайнтьюнина на диалоговых данных + дообучена на ответах
*Еще в комменты закину несколько приколюх
🔗 ChatGPT Telegram Bot (GitHub)
🎒 @karim_iskakov
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - father-bot/chatgpt_telegram_bot: 💬 Telegram bot with ChatGPT, Python-based, using OpenAI's API.
💬 Telegram bot with ChatGPT, Python-based, using OpenAI's API. - father-bot/chatgpt_telegram_bot
Forwarded from DevFM
Жизненная история
Мы часто видим на конференциях доклады об изящных технических решениях сложных проблем. Каждый второй изобретает вундервафлю, у каждого первого хайлоад и всё красиво.
Но в реальности всё не так радужно. Бизнесу нужны решения здесь и сейчас, и продукт нередко растёт стихийно, функционируя на костылях и подпорках.
Лёгкая и жизненная статья о достаточно крупной фирме, где всё было буднично. Чтобы выдержать нагрузку — накидывали железа вручную, тестирование — только на локальной машине разработчика, деплой проводили с помощью наколеночного решения.
А дальше автор описывает путь, как можно выбраться из этого болота. Статья сильно перекликается с нашим опытом, аж сжимается сердечко. Из-за постоянно меняющихся требований реального мира нельзя построить идеальную систему. Многие принимаемые решения являются компромиссами. Описанный в статье переход — это путь плавной трансформации, которая позволяет двигаться к светлому будущему в реальных условиях.
Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.
Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills
Мы часто видим на конференциях доклады об изящных технических решениях сложных проблем. Каждый второй изобретает вундервафлю, у каждого первого хайлоад и всё красиво.
Но в реальности всё не так радужно. Бизнесу нужны решения здесь и сейчас, и продукт нередко растёт стихийно, функционируя на костылях и подпорках.
Лёгкая и жизненная статья о достаточно крупной фирме, где всё было буднично. Чтобы выдержать нагрузку — накидывали железа вручную, тестирование — только на локальной машине разработчика, деплой проводили с помощью наколеночного решения.
А дальше автор описывает путь, как можно выбраться из этого болота. Статья сильно перекликается с нашим опытом, аж сжимается сердечко. Из-за постоянно меняющихся требований реального мира нельзя построить идеальную систему. Многие принимаемые решения являются компромиссами. Описанный в статье переход — это путь плавной трансформации, которая позволяет двигаться к светлому будущему в реальных условиях.
Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.
Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills
Хабр
Наши 5 лет с инфраструктурой «ВсеИнструменты.ру»: от нескольких ВМ до отказоустойчивого решения в трёх дата-центрах
Cтатья посвящена проекту «ВсеИнструменты.ру» — крупнейшему интернет-магазину DIY-товаров и нашему клиенту по совместительству. Расскажем, с чего начинали сотрудничество более пяти лет назад, как...
Forwarded from Время Валеры
Мой друг Игорь написал подробную статью про ChatGPT - которая скорее является полноценным обзором, который зайдет как новичкам, так и спецам. Советую прочитать
Еще у него есть Телеграм Канал, но это уже на ваш страх и риск
Еще у него есть Телеграм Канал, но это уже на ваш страх и риск
Хабр
ChatGPT как инструмент для поиска: решаем основную проблему
Вышедшая чуть больше месяца назад ChatGPT уже успела нашуметь: школьникам в Нью-Йорке запрещают использовать нейросеть в качестве помощника, её же ответы теперь не принимаются на StackOverflow, а...
Forwarded from Aspiring Data Science
#python #tricks #nwise #casefold #rml #tee
Собственно, где я и заметил использование casefold. Стоит посмотреть полностью, если кто не знал.
https://www.youtube.com/watch?v=iE5QLrzkGBU
Собственно, где я и заметил использование casefold. Стоит посмотреть полностью, если кто не знал.
https://www.youtube.com/watch?v=iE5QLrzkGBU
YouTube
James Powell- Why do I need to know Python- I'm a pandas user | PyData NYC 2022
It's common for data scientists to narrowly focus on the APIs of the tools they use every day—pandas, matplotlib, pymc, dask, &c.—to the detriment of any focus on the surrounding programming language. In the case of tools like matplotlib, the total amount…
Forwarded from DevFM
Введение в Kubernetes
В повседневной разработке без докера не жизнь, а каторга. Мы делились нашим опытом, какие именно задачи решает докер.
С ростом размера проекта растёт количество подсистем, особенно быстро в микросервистной архитектуре. Деление на подсистемы позволяет упростить совместную разработку, так как каждая команда работает с небольшой подсистемой вместо части большого монолита. Ценой упрощения разработки становится сложность управления этими подсистемами, и возникает проблема оркестрации. Каждую подсистему нужно деплоить, масштабировать и мониторить.
И в этот момент в дело вступает kubernetes, который вносит удобство оркестрации в больших проектах. Аккуратно, для маленьких проектов kubernetes обычно избыточно сложен и является оверинжинирингом.
Представляем серию из 6 душевных статей, посвящённых кубернетесу. Статьи читаются на одном дыхании и погружают в основы технологии.
Первая статья — концептуальное введение о необходимости оркестрации контейнеров без привязки к кубернетесу.
Вторая статья освещает основные концепции — cluster, nodes, pods, namespaces, кто на ком стоял.
Третья подробнее рассказывает о супер-важной штуке в кубере — подах (pods). Почему не хватает контейнера, из чего состоит под, в каких состояниях он может быть и как проверить его работоспособность.
Кто-то должен управлять всем развернутым зоопарком, предоставлять API для взаимодействия, решать на каком узле запустить под, контролировать работоспособность различных частей кластера и пытаться приводить всё к требуемому состоянию (desired state). Четвертая статья рассказывает о мастер-ноде и компонентах, которые берут на себя все эти задачи.
Пятая статья вводит ещё один набор концепций, которые активно применяются в кубернетесе — deployments, stateful set, daemon, jobs. Со всем этим неизбежно сталкиваешься на практике.
И заключительная, шестая статья рассказывает о том, как устроено взаимодействие различных частей в кластере, какие IP-адреса существуют, для чего они используются и как в обращении с ними помогают load balancer и ingress controller.
На практике всё гораздо сложнее, но эта серия будет отличной базой для дальнейшего освоения. Даже если не сталкивались с большими проектами, концептуальное понимание мощи оркестрации не будет лишним. В какой-то момент в профессиональной деятельности с чем-то подобным столкнетесь, на собесах про подобное тоже спрашивают. Так что лучше знать о существующих решениях, чтобы не городить свои велосипеды.
🔥, если интересна тема кубернетеса.
#skills
В повседневной разработке без докера не жизнь, а каторга. Мы делились нашим опытом, какие именно задачи решает докер.
С ростом размера проекта растёт количество подсистем, особенно быстро в микросервистной архитектуре. Деление на подсистемы позволяет упростить совместную разработку, так как каждая команда работает с небольшой подсистемой вместо части большого монолита. Ценой упрощения разработки становится сложность управления этими подсистемами, и возникает проблема оркестрации. Каждую подсистему нужно деплоить, масштабировать и мониторить.
И в этот момент в дело вступает kubernetes, который вносит удобство оркестрации в больших проектах. Аккуратно, для маленьких проектов kubernetes обычно избыточно сложен и является оверинжинирингом.
Представляем серию из 6 душевных статей, посвящённых кубернетесу. Статьи читаются на одном дыхании и погружают в основы технологии.
Первая статья — концептуальное введение о необходимости оркестрации контейнеров без привязки к кубернетесу.
Вторая статья освещает основные концепции — cluster, nodes, pods, namespaces, кто на ком стоял.
Третья подробнее рассказывает о супер-важной штуке в кубере — подах (pods). Почему не хватает контейнера, из чего состоит под, в каких состояниях он может быть и как проверить его работоспособность.
Кто-то должен управлять всем развернутым зоопарком, предоставлять API для взаимодействия, решать на каком узле запустить под, контролировать работоспособность различных частей кластера и пытаться приводить всё к требуемому состоянию (desired state). Четвертая статья рассказывает о мастер-ноде и компонентах, которые берут на себя все эти задачи.
Пятая статья вводит ещё один набор концепций, которые активно применяются в кубернетесе — deployments, stateful set, daemon, jobs. Со всем этим неизбежно сталкиваешься на практике.
И заключительная, шестая статья рассказывает о том, как устроено взаимодействие различных частей в кластере, какие IP-адреса существуют, для чего они используются и как в обращении с ними помогают load balancer и ingress controller.
На практике всё гораздо сложнее, но эта серия будет отличной базой для дальнейшего освоения. Даже если не сталкивались с большими проектами, концептуальное понимание мощи оркестрации не будет лишним. В какой-то момент в профессиональной деятельности с чем-то подобным столкнетесь, на собесах про подобное тоже спрашивают. Так что лучше знать о существующих решениях, чтобы не городить свои велосипеды.
🔥, если интересна тема кубернетеса.
#skills
Telegram
DevFM
Зачем вам нужен докер?
Встретили тут в бизнесе мысль: "мы недостаточно большие, чтобы использовать Docker". Не можем согласиться с таким тезисом. В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые…
Встретили тут в бизнесе мысль: "мы недостаточно большие, чтобы использовать Docker". Не можем согласиться с таким тезисом. В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые…
Forwarded from Записки Ппилифа (Ppilif Uliankin [GMT+3])
Задача коллекционера
Мы тут киндер-сюрпризы хаваем и попутно решаем задачу коллекционера. Только что Ира и Денис героически распаковали шоколадное яйцо и нашли последнюю игрушку из коллекции.
Если по-честному посчитать, получится, что E(X) ≈ n ln n.
Теоретическое математическое ожидание для коллекции из 18 игрушек оказывается примерно 52. Мы съели 50 яиц для того, чтобы собрать полную коллекцию.
Решение задачи коллекционера от меня можно найти на ютубе.
Оно очень красивое и использует два приёма: сначала надо разложить случайную величину в сумму индикаторов, а потом для каждой из маленьких случайных величин применить метод первого шага.
Много красивых задачек по терверу, кстати говоря, можно найти в культурном коде.
P.S. в случае коллекционера дисперсия довольно большая. Она пропорциональна n^2. При покупке яиц это придется учитывать.
Мы тут киндер-сюрпризы хаваем и попутно решаем задачу коллекционера. Только что Ира и Денис героически распаковали шоколадное яйцо и нашли последнюю игрушку из коллекции.
Задача:
Производитель яиц киндер-сюрприз кладёт в каждое яйцо одну из 50 случайно выбранных игрушек. Мы хотим собрать полную коллекцию. Пусть X — это количество яиц, которое надо купить. Найдите математическое ожидание E(X).
Если по-честному посчитать, получится, что E(X) ≈ n ln n.
Теоретическое математическое ожидание для коллекции из 18 игрушек оказывается примерно 52. Мы съели 50 яиц для того, чтобы собрать полную коллекцию.
Решение задачи коллекционера от меня можно найти на ютубе.
Оно очень красивое и использует два приёма: сначала надо разложить случайную величину в сумму индикаторов, а потом для каждой из маленьких случайных величин применить метод первого шага.
Много красивых задачек по терверу, кстати говоря, можно найти в культурном коде.
P.S. в случае коллекционера дисперсия довольно большая. Она пропорциональна n^2. При покупке яиц это придется учитывать.
Forwarded from Red Powerful
Data Validation
Валидация данных - одно из самых важных вещей, что бы лутать МЛ соревы, важнее только данные и их обработка.
1. Если у нас хороший FE, мы делаем вот что
- убеждаемся в том что train ~ test. Для этого проводим adversial validation и стат критерии на схожесть распределений средних и дисперсии. После чего делаем выводы о трансформации данных
2. Определяем какая валидация для нас нужна, но большинство делают просто CV без треккинга, а вы пробовали когда нибудь Repeated K-CV? Он позволяет трекать E[x] +- D[x], из чего мы можем сделать вывод о уверенности модели. А так же можно накинуть бутстрап (4 задача из демо симулятора вроде)
https://www.youtube.com/watch?v=qOwT553oMzs
Но есть такой человек Ron Kohavi, если вы смотрели внимательно видео, то он упоминается в статье. И я решил посмотреть что там за гипотезу он написал, а там огромное исследование о валидации данных, по сути видео - краткая выдержка статьи.
https://robotics.stanford.edu/users/ronnyk/teza.pdf
Мой канал - https://t.iss.one/notedatascience
Чат - https://t.iss.one/notedatasciencechat
Валидация данных - одно из самых важных вещей, что бы лутать МЛ соревы, важнее только данные и их обработка.
1. Если у нас хороший FE, мы делаем вот что
- убеждаемся в том что train ~ test. Для этого проводим adversial validation и стат критерии на схожесть распределений средних и дисперсии. После чего делаем выводы о трансформации данных
2. Определяем какая валидация для нас нужна, но большинство делают просто CV без треккинга, а вы пробовали когда нибудь Repeated K-CV? Он позволяет трекать E[x] +- D[x], из чего мы можем сделать вывод о уверенности модели. А так же можно накинуть бутстрап (4 задача из демо симулятора вроде)
https://www.youtube.com/watch?v=qOwT553oMzs
Но есть такой человек Ron Kohavi, если вы смотрели внимательно видео, то он упоминается в статье. И я решил посмотреть что там за гипотезу он написал, а там огромное исследование о валидации данных, по сути видео - краткая выдержка статьи.
https://robotics.stanford.edu/users/ronnyk/teza.pdf
Мой канал - https://t.iss.one/notedatascience
Чат - https://t.iss.one/notedatasciencechat