Forwarded from Борис опять
#дайджест
Дайджест ML/AI за неделю 5 - 11 Января 2026
Lightricks: LTX-2
Open-weight видео foundation-модель с синхронной генерацией 4K/50fps видео. Модель заточена под длинные клипы до 20 сек, нативный звук. На artificialanalysis в общем зачете занимает почетное 21-е место и первое среди моделей с открытыми весами.
Блогпост, HF, Статья, Код
OpenAI: ChatGPT Health
OpenAI запустили ChatGPT Health - отдельный режим для работы с медицинскими данными. Можно загружать анализы, снимки, отчёты врачей, данные из фитнес-трекеров и MyFitnessPal. Доступно даже бесплатным пользователям через вэйтлист (записаться здесь) и пока, как обычно, без EU/UK.
Блогпост
Tencent: Hunyuan HY-MT1.5-1.8B
Tencent выпустили компактную модель для машинного перевода HY-MT1.5-1.8B. Обещают лучший перформанс в своем весе. Поддерживает 33 языка, оптимизирована под on-device и дешёвый inference.
HF, Код , Карточка, Статья
ByteDance: DreamID-V
ByteDance выпустили DreamID-V - модель для замены лиц на видео по фото-референсу через трансформер-диффузию. Обещают устойчивость к разному освещению, прическам и тд. Черри-пики выглядят хорошо.
Примеры и проект, GitHub, Статья
NVIDIA: Vera Rubin
NVIDIA представили платформу Vera Rubin для датацентров - next-gen архитектуру для AI-вычислений, которая придёт на смену Blackwell. Простым людям пообещали игровые видеокарты RTX 60xx на базе Vera Rubin во второй половине 2027 года. Как обычно все в несколько раз быстрее, выше, сильнее. Готовый сервер NVL144 будет иметь в три раза больше exaFLOPS, чем NVL72 GB300.
Из прекрасного: параллельно с трансляцией Nvidia кто-то запустил трансляцию на Youtube, где Дип-фейк Хуанг продавал крипу. Она собрала в 10 раз больше зрителей.
Пресс-релиз NVIDIA, Про фейк-крипто-хуанга, разбор Сиолошной
Дайджест ML/AI за неделю 5 - 11 Января 2026
Lightricks: LTX-2
Open-weight видео foundation-модель с синхронной генерацией 4K/50fps видео. Модель заточена под длинные клипы до 20 сек, нативный звук. На artificialanalysis в общем зачете занимает почетное 21-е место и первое среди моделей с открытыми весами.
Блогпост, HF, Статья, Код
OpenAI: ChatGPT Health
OpenAI запустили ChatGPT Health - отдельный режим для работы с медицинскими данными. Можно загружать анализы, снимки, отчёты врачей, данные из фитнес-трекеров и MyFitnessPal. Доступно даже бесплатным пользователям через вэйтлист (записаться здесь) и пока, как обычно, без EU/UK.
Блогпост
Tencent: Hunyuan HY-MT1.5-1.8B
Tencent выпустили компактную модель для машинного перевода HY-MT1.5-1.8B. Обещают лучший перформанс в своем весе. Поддерживает 33 языка, оптимизирована под on-device и дешёвый inference.
HF, Код , Карточка, Статья
ByteDance: DreamID-V
ByteDance выпустили DreamID-V - модель для замены лиц на видео по фото-референсу через трансформер-диффузию. Обещают устойчивость к разному освещению, прическам и тд. Черри-пики выглядят хорошо.
Примеры и проект, GitHub, Статья
NVIDIA: Vera Rubin
NVIDIA представили платформу Vera Rubin для датацентров - next-gen архитектуру для AI-вычислений, которая придёт на смену Blackwell. Простым людям пообещали игровые видеокарты RTX 60xx на базе Vera Rubin во второй половине 2027 года. Как обычно все в несколько раз быстрее, выше, сильнее. Готовый сервер NVL144 будет иметь в три раза больше exaFLOPS, чем NVL72 GB300.
Из прекрасного: параллельно с трансляцией Nvidia кто-то запустил трансляцию на Youtube, где Дип-фейк Хуанг продавал крипу. Она собрала в 10 раз больше зрителей.
Пресс-релиз NVIDIA, Про фейк-крипто-хуанга, разбор Сиолошной
ltx.io
LTX-2: Production-Grade AI Video Generation Model | LTX Model
LTX-2 is a pro AI video model for production. It offers precise control, native 4K, high frame rates and proven performance for long-form creative tasks.
Forwarded from Борис опять
Очень хороший практический гайд по всем трюкам, велосипедам и костылям для построения RAG систем:
https://habr.com/ru/articles/893356/
В продакшне часть из описанного можно упростить (с точки зрения реализации) подключив любимый агентский фреймворк, но суть особо не меняется
https://habr.com/ru/articles/893356/
В продакшне часть из описанного можно упростить (с точки зрения реализации) подключив любимый агентский фреймворк, но суть особо не меняется
Хабр
Как я победил в RAG Challenge: от нуля до SoTA за один конкурс
Автор - DarkBones Предисловие В этом посте я расскажу про подход, благодаря которому я занял первое место в обеих призовых номинациях и в общем SotA рейтинге. В чём суть RAG Challenge? Нужно создать...
Forwarded from Алексей
claude для кода gpt для проверки qwen для оценки gemini для того чтобы понять что написано
Forwarded from Quant Researcher
Nautilus Trader — индустриальный бэктестинг
https://github.com/nautechsystems/nautilus_trader
Если вы пытались превратить красивую идею в реплицируемый PnL, вы знаете, как это весело и увлекательно: бэктест не сходится, исполнение — по ценам с ффилами, а латенси существует только на словах.
Nautilus Trader — это попытка закрыть именно этот разрыв. Проект от Nautech Systems, open-source, сразу целится в production-grade trading stack.
🧠 Ключевая идея
Бэктест = симуляция реальной торговой системы, а не просто прогон сигналов по историческим ценам.
Библиотека моделирует не только рынок, но и ордера, исполнение, задержки, комиссии, частичную ликвидность, состояние портфеля, event-driven логику.
Фактически, это единый движок для research, backtesting, paper trading, live.
Без переписывания стратегии под каждый этап.
⚙️ Архитектура
- Event-driven ядро (никаких «for price in prices»)
- Строгое разделение:
- Strategy
- Execution
- Portfolio
- Risk
- Детальная модель ордеров (limit / market / stop / OCO и т.д.)
- Поддержка crypto, FX, equities
- Python + Rust (где нужна скорость)
Это не обертка над pandas, а торговый симулятор, ближе по духу к тому, как думают HFT / prop desks.
📊 Почему это важно для квантов
Большинство стратегий умирают не из-за идеи, а из-за недоучтённого исполнения, хвостов распределения PnL, нелинейностей при масштабировании.
Nautilus Trader заставляет как можно раньше подумать про ликвидность, проскальзывание, устойчивость PnL, path-dependence.
А значит — лучше понимать, какие риски вы реально покупаете или продаете.
⸻
А выкаким порошком пользуетесь:
• моделируете исполнение в бэктестах?
• знаете, чувствительность своего PnL от проскальзывания и комиссий?
Quant Researcher
https://github.com/nautechsystems/nautilus_trader
Если вы пытались превратить красивую идею в реплицируемый PnL, вы знаете, как это весело и увлекательно: бэктест не сходится, исполнение — по ценам с ффилами, а латенси существует только на словах.
Nautilus Trader — это попытка закрыть именно этот разрыв. Проект от Nautech Systems, open-source, сразу целится в production-grade trading stack.
🧠 Ключевая идея
Бэктест = симуляция реальной торговой системы, а не просто прогон сигналов по историческим ценам.
Библиотека моделирует не только рынок, но и ордера, исполнение, задержки, комиссии, частичную ликвидность, состояние портфеля, event-driven логику.
Фактически, это единый движок для research, backtesting, paper trading, live.
Без переписывания стратегии под каждый этап.
⚙️ Архитектура
- Event-driven ядро (никаких «for price in prices»)
- Строгое разделение:
- Strategy
- Execution
- Portfolio
- Risk
- Детальная модель ордеров (limit / market / stop / OCO и т.д.)
- Поддержка crypto, FX, equities
- Python + Rust (где нужна скорость)
Это не обертка над pandas, а торговый симулятор, ближе по духу к тому, как думают HFT / prop desks.
📊 Почему это важно для квантов
Большинство стратегий умирают не из-за идеи, а из-за недоучтённого исполнения, хвостов распределения PnL, нелинейностей при масштабировании.
Nautilus Trader заставляет как можно раньше подумать про ликвидность, проскальзывание, устойчивость PnL, path-dependence.
А значит — лучше понимать, какие риски вы реально покупаете или продаете.
⸻
А вы
• моделируете исполнение в бэктестах?
• знаете, чувствительность своего PnL от проскальзывания и комиссий?
Quant Researcher
Forwarded from max.sh
Когда-то давно, во времена учебы в ШАДе, нам читали интенсив по основам архитектуры GPU и разработки на CUDA. Обещали рассказать, как устроены видеокарты и почему они эффективны для машинного обучения. Я тогда дальше
Лекции читали разработчики из Nvidia. Да, это было такое время, когда у компании был Московский офис и они периодически нанимали DL-инженеров, а иногда и стажеров (марафон технических раундов и глубоких вопросов на понимание, чтобы побороться за 2 стажерские позиции).
Курс, по моему мнению, получился ужасным. Материал стремительно усложнялся без какой-либо оглядки на аудиторию и тот факт, что ко второй лекции половина слушателей уже отвалилась. Я потерял суть происходящего уже минуте на 20-30 первой лекции, в момент когда термины вида SM, warp schedulers, cuda cores заполняли каждый слайд, а повествование превратилось во внутренний митап для инженеров Nvidia.
Худо-бедно интенсив я закрыл, решая задачи методом проб и ошибок. От курса в голове не осталось почти ничего. Разве что боязнь копаться в деталях работы с GPU.
Позже, уже в 2022-2023 году, модели перестали влазить в память одной ГПУ и нужно было учиться паралелить, оценивать эффективность инфраструктуры в поисках ответа на вопрос: а почему все так медленно? are we compute bound or communication bound? Снова я столкнулся с GPU акселераторами лицом к лицу. Документации от Nvidia было не очень много, так что неподготовленному читателю входить было не просто. Но дело двигалось тем же путем проб и ошибок и общением с коллегами по работе.
А хороших гайдов на понимание все еще не было. Мне кажется их и сейчас не очень много. ( Как и специалистов в этой области. Performance Engineer крайне актуальная роль в области DL на ближайшие годы)
Недавно наткнулся на "книгу" от ребят из DeepMind, они проделали невероятную методологическую работу. И выпустили онлайн-учебник How to Scale Your Model. Центральный предмет книги о том, как учить трансформеры на больших кластерах, арифметику моделей (откуда набегает так много гигабайтов памяти, чтобы сделать один forward pass) и что такое TPU/GPU. К каждой главе идет еще набор квизов, чтобы посчитать что-нибудь руками.
Крайне Рекомендую!
https://jax-ml.github.io/scaling-book/
model.to('cuda:0') в этом вопросе ничего не знал, поэтому с интересом записался.Лекции читали разработчики из Nvidia. Да, это было такое время, когда у компании был Московский офис и они периодически нанимали DL-инженеров, а иногда и стажеров (марафон технических раундов и глубоких вопросов на понимание, чтобы побороться за 2 стажерские позиции).
Курс, по моему мнению, получился ужасным. Материал стремительно усложнялся без какой-либо оглядки на аудиторию и тот факт, что ко второй лекции половина слушателей уже отвалилась. Я потерял суть происходящего уже минуте на 20-30 первой лекции, в момент когда термины вида SM, warp schedulers, cuda cores заполняли каждый слайд, а повествование превратилось во внутренний митап для инженеров Nvidia.
Худо-бедно интенсив я закрыл, решая задачи методом проб и ошибок. От курса в голове не осталось почти ничего. Разве что боязнь копаться в деталях работы с GPU.
Позже, уже в 2022-2023 году, модели перестали влазить в память одной ГПУ и нужно было учиться паралелить, оценивать эффективность инфраструктуры в поисках ответа на вопрос: а почему все так медленно? are we compute bound or communication bound? Снова я столкнулся с GPU акселераторами лицом к лицу. Документации от Nvidia было не очень много, так что неподготовленному читателю входить было не просто. Но дело двигалось тем же путем проб и ошибок и общением с коллегами по работе.
А хороших гайдов на понимание все еще не было. Мне кажется их и сейчас не очень много. ( Как и специалистов в этой области. Performance Engineer крайне актуальная роль в области DL на ближайшие годы)
Недавно наткнулся на "книгу" от ребят из DeepMind, они проделали невероятную методологическую работу. И выпустили онлайн-учебник How to Scale Your Model. Центральный предмет книги о том, как учить трансформеры на больших кластерах, арифметику моделей (откуда набегает так много гигабайтов памяти, чтобы сделать один forward pass) и что такое TPU/GPU. К каждой главе идет еще набор квизов, чтобы посчитать что-нибудь руками.
Крайне Рекомендую!
https://jax-ml.github.io/scaling-book/
jax-ml.github.io
How To Scale Your Model
Training LLMs often feels like alchemy, but understanding and optimizing the performance of your models doesn't have to. This book aims to demystify the science of scaling language models: how TPUs (and GPUs) work and how they communicate with each other…
Forwarded from Machine head - Александр О.
Анатомия ИИ-агентов. Часть 1 - Истоки и архитектура. [1/2]
Подходит концу первая рабочая неделя этого года. Дабы провести выходные с пищей для ума, самое время с двух ног запрыгнуть в устройство ИИ-агентов. Начнем с истоков.⚡️
Первыми практическими предшественниками современных ИИ-агентов стали экспертные системы, появившиеся в 1960-х годах. Экспертная система — это система искусственного интеллекта (весьма ограниченного), которая на основании знаний и опыта эксперта-человека может решать задачи в определенной области. В 1965 году в Стэнфордском университете Эдвард Фейгенбаум создал DENDRAL — первую в истории экспертную систему для определения структуры химических веществ.
Прорыв в понимании ИИ-агентов произошел в 1973 году, когда Карл Хьюитт разработал модель актора — подход, позволяющий создавать системы, где независимые агенты взаимодействуют друг с другом через обмен сообщениями. Одной из первых таких систем стала Distributed Problem Solver, созданная в 1981 году. В 1986 году Марвин Минский в книге “Society of Mind” предложил представлять сложные задачи как результат взаимодействия множества отдельных агентов, работающих в “сообществе”. Почему это важно? Модель актора обеспечила сдвиг ментальной модели программирования от систем с общей памятью и блокировками к архитектуре, основанной на передаче сообщений и изоляции состояния.
Современный ИИ-агент, следуя принципам акторной модели и построенный поверх большой лингвистической модели, отличителен 3-мя ключевыми свойствами:
Свойство 1. Автономность и независимое выполнение задач.
В понимании современных ИИ-агентов речь идет о способности агента к планированию следующего шага. В отличие от “голой” LLM, где мы работаем в режиме “запрос-ответ”, агент действует в, так называемом, агентском цикле: Наблюдение → Планирование → Действие. Агентский цикл конечен. Независимо от его сложности, агент на вход получает запрос, запускает цикл и его цель вернуть ожидаемый результат. Вот, что делают шаги цикла:
1. Наблюдение. Агент анализирует результаты своих предыдущих действий, собирает данные из окружения, выполняет контекстное обогащение.
2. Планирование. Агент использует различные методы рассуждений для определения наилучшего способа действий. Модель начинает думать над решением запроса пользователя, разрабатывает план для дальнейших действий и определяет, какие инструменты можно использовать.
3. Действие. Агент выбирает необходимые инструменты и начинает их использовать в соответствии с задачами, сформулированными на этапе планирования.
Свойство 2. Интеграция с инструментами и окружением
В шаге планирования и действия агенту доступно мета-описание его окружения: команд, которые может выбрать LLM, для взаимодействия с окружающим миром. Между командой и LLM - тонкий слой управляющего кода, интерпретирующего текстовые ответы в вызов кода самой команды. Именно поэтому к LLM выдвигается требование к способности отвечать структурированно (Structured output). Действуя, агент делает 1 или множество запросов к LLM, получая структурированные ответы, вызывает инструменты - обычный код в функциях и классах с поведением, исполняемый процессором, выполняет работу, а также сверяется с исходным планом.
продолжение...
Подходит концу первая рабочая неделя этого года. Дабы провести выходные с пищей для ума, самое время с двух ног запрыгнуть в устройство ИИ-агентов. Начнем с истоков.
Первыми практическими предшественниками современных ИИ-агентов стали экспертные системы, появившиеся в 1960-х годах. Экспертная система — это система искусственного интеллекта (весьма ограниченного), которая на основании знаний и опыта эксперта-человека может решать задачи в определенной области. В 1965 году в Стэнфордском университете Эдвард Фейгенбаум создал DENDRAL — первую в истории экспертную систему для определения структуры химических веществ.
Прорыв в понимании ИИ-агентов произошел в 1973 году, когда Карл Хьюитт разработал модель актора — подход, позволяющий создавать системы, где независимые агенты взаимодействуют друг с другом через обмен сообщениями. Одной из первых таких систем стала Distributed Problem Solver, созданная в 1981 году. В 1986 году Марвин Минский в книге “Society of Mind” предложил представлять сложные задачи как результат взаимодействия множества отдельных агентов, работающих в “сообществе”. Почему это важно? Модель актора обеспечила сдвиг ментальной модели программирования от систем с общей памятью и блокировками к архитектуре, основанной на передаче сообщений и изоляции состояния.
Современный ИИ-агент, следуя принципам акторной модели и построенный поверх большой лингвистической модели, отличителен 3-мя ключевыми свойствами:
Свойство 1. Автономность и независимое выполнение задач.
Многие проводят равенство между автономностью и самостоятельностью, мол, агент живет сам по себе и делает работу, как человек, то нет. Самостоятельность - способность не только выполнять действия без надзора, но и ставить подцели, адаптироваться к неизвестным заранее условиям. Дело не в технических ограничениях. Самостоятельность (и его объем) - производное от доверия, а доверие - краеугольный камень любых внешних, не только агентских систем.
В понимании современных ИИ-агентов речь идет о способности агента к планированию следующего шага. В отличие от “голой” LLM, где мы работаем в режиме “запрос-ответ”, агент действует в, так называемом, агентском цикле: Наблюдение → Планирование → Действие. Агентский цикл конечен. Независимо от его сложности, агент на вход получает запрос, запускает цикл и его цель вернуть ожидаемый результат. Вот, что делают шаги цикла:
1. Наблюдение. Агент анализирует результаты своих предыдущих действий, собирает данные из окружения, выполняет контекстное обогащение.
2. Планирование. Агент использует различные методы рассуждений для определения наилучшего способа действий. Модель начинает думать над решением запроса пользователя, разрабатывает план для дальнейших действий и определяет, какие инструменты можно использовать.
3. Действие. Агент выбирает необходимые инструменты и начинает их использовать в соответствии с задачами, сформулированными на этапе планирования.
Свойство 2. Интеграция с инструментами и окружением
В шаге планирования и действия агенту доступно мета-описание его окружения: команд, которые может выбрать LLM, для взаимодействия с окружающим миром. Между командой и LLM - тонкий слой управляющего кода, интерпретирующего текстовые ответы в вызов кода самой команды. Именно поэтому к LLM выдвигается требование к способности отвечать структурированно (Structured output). Действуя, агент делает 1 или множество запросов к LLM, получая структурированные ответы, вызывает инструменты - обычный код в функциях и классах с поведением, исполняемый процессором, выполняет работу, а также сверяется с исходным планом.
продолжение...
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Machine head - Александр О.
Анатомия ИИ-агентов. Часть 1 - Истоки и архитектура. [2/2]
В начало
Свойство 3. Память
LLM не обладает собственной памятью (или состоянием) между запросами - каждый запрос обрабатывается независимо, как в первый раз. То, что мы называем агентом, является обычной программой с собственным окружением. Как и любая другая программа, она может хранить состояние в оперативной памяти, обращаться к базам данных, собирать необходимый контекст для выполнения пользовательской задачи. Простейший вид памяти - сохранение всей последовательности запросов к LLM и ее ответов.
Так же как человеческий мозг имеет полушария и специализированные отделы, обеспечивающие нам интеллектуальные способности во всем их многообразии, ИИ-агент может быть разделен на части для пущей интеллектуальности. Программную архитектуру можно представить в виде фрактала - узора, обладающего свойством самоподобия: его части в уменьшенном масштабе повторяют структуру целого, где основной узор - агентский цикл. Агентский цикл, как архитектурная единица, в том же виде используется для создания под-модулей: планировщика, рефлексии, цензора, интерпретатора и тд. Когда и как эти подмодули-микроагенты (не путать с суб-агентами) будут вступать в работу определяет разработчик, склеивая их в процесс всё тем же обычным кодом (как, увидим в следующих статьях).
——
Подытоживая, архитектура ИИ-агента удивляет своей простотой и масштабируемостью, являясь кирпичиком системы любой сложности. Агент может быть как простейшим SingleRun-вызовом к LLM с остановкой после ответа, так и ReAct-агентом, самостоятельно принимающим решение как действовать дальше и когда заканчивать. Их и будем разбирать далее.
Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned!✌️
В начало
Свойство 3. Память
LLM не обладает собственной памятью (или состоянием) между запросами - каждый запрос обрабатывается независимо, как в первый раз. То, что мы называем агентом, является обычной программой с собственным окружением. Как и любая другая программа, она может хранить состояние в оперативной памяти, обращаться к базам данных, собирать необходимый контекст для выполнения пользовательской задачи. Простейший вид памяти - сохранение всей последовательности запросов к LLM и ее ответов.
Так же как человеческий мозг имеет полушария и специализированные отделы, обеспечивающие нам интеллектуальные способности во всем их многообразии, ИИ-агент может быть разделен на части для пущей интеллектуальности. Программную архитектуру можно представить в виде фрактала - узора, обладающего свойством самоподобия: его части в уменьшенном масштабе повторяют структуру целого, где основной узор - агентский цикл. Агентский цикл, как архитектурная единица, в том же виде используется для создания под-модулей: планировщика, рефлексии, цензора, интерпретатора и тд. Когда и как эти подмодули-микроагенты (не путать с суб-агентами) будут вступать в работу определяет разработчик, склеивая их в процесс всё тем же обычным кодом (как, увидим в следующих статьях).
——
Подытоживая, архитектура ИИ-агента удивляет своей простотой и масштабируемостью, являясь кирпичиком системы любой сложности. Агент может быть как простейшим SingleRun-вызовом к LLM с остановкой после ответа, так и ReAct-агентом, самостоятельно принимающим решение как действовать дальше и когда заканчивать. Их и будем разбирать далее.
Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Nikolay
Амазон
1)https://www.amazon.jobs/en/principles
2)https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d 3)https://docs.google.com/spreadsheets/d/1oBA6vanArm8gh79vzUnyJL-1kriLiGznYKh8gXAfD4s/edit?usp=drivesdk 4)https://www.notion.so/BE-Interview-8adc74cf14ad450fab3083e0633d2821#7b7c9b724012423f9572ef0787536c6e тут собираем вопросы https://docs.google.com/document/d/10mS6Whiybl3VjO9t3ZbMhp9TinNWBIArQoqmTaoSfqs/edit?usp=sharing 5) https://www2.hws.edu/pdf/career/behavioral_interview_questions.pdf
1)https://www.amazon.jobs/en/principles
2)https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d 3)https://docs.google.com/spreadsheets/d/1oBA6vanArm8gh79vzUnyJL-1kriLiGznYKh8gXAfD4s/edit?usp=drivesdk 4)https://www.notion.so/BE-Interview-8adc74cf14ad450fab3083e0633d2821#7b7c9b724012423f9572ef0787536c6e тут собираем вопросы https://docs.google.com/document/d/10mS6Whiybl3VjO9t3ZbMhp9TinNWBIArQoqmTaoSfqs/edit?usp=sharing 5) https://www2.hws.edu/pdf/career/behavioral_interview_questions.pdf
amazon.jobs
Leadership Principles
We use our Leadership Principles every day, whether we’re discussing ideas for new projects or deciding on the best way to solve a problem. It’s just one of the things that makes Amazon peculiar.
Forwarded from DziS Science | Data Science
Привет всем!👋
Сегодня поговорим про небольшую оптимизацию кода по памяти.
Известный факт, что неизменяемые структуры, которые имеют фиксированные размеры, имеют некоторые преимущества в сравнении с изменяемыми.
В рамках проектов, где часто вызываются миллионы мелких объектов (например, узлы в графе, события в симуляции, кастомные токены) проблема утечки памяти встает очень остро. Отчасти, это касается и атрибутов объектов.
По умолчанию🐍 хранит атрибуты объектов в словаре, включенном в метод
Для решения проблемы предлагается использовать метод
Он отключает создание
Рассмотрим на примере:
🔸 Определим классический класс
🔸 Теперь определим объекты классов
- Какие разницы в этих объектах?
🔵 В
Пример:
Причина такого поведения лежит именно в формировании класса с использованием
🔵 В obj2 нет словаря атрибутов
Проверить это просто:
Вывод следующий (до добавления атрибута):
Таким образом, если мы имеет часто используемый класс и нам не нужна свобода в изменении состава атрибутов, то правильнее использовать конструкцию со
Ставь 🔥, если не знал.
Ставь👍, если знал.
#ds_лайфхаки
Сегодня поговорим про небольшую оптимизацию кода по памяти.
Известный факт, что неизменяемые структуры, которые имеют фиксированные размеры, имеют некоторые преимущества в сравнении с изменяемыми.
В рамках проектов, где часто вызываются миллионы мелких объектов (например, узлы в графе, события в симуляции, кастомные токены) проблема утечки памяти встает очень остро. Отчасти, это касается и атрибутов объектов.
По умолчанию
__dict__ (появился он в языке 8 февраля 2012 года), который, как и обычный словарь имеет динамическое выделение памяти и может быть расширяем, что при всех своих плюсах создает большую нагрузку на память. Для решения проблемы предлагается использовать метод
__slots__. Он отключает создание
__dict__ и резервирует память только под конкретные атрибуты, что помогает оптимизировать код по памяти, но жестко фиксирует набор атрибутов объекта, что является одновременно и плюсом и минусом. Рассмотрим на примере:
CoordinatesDict`и класс `CoordinatesSlots с использованием __slots__import sys
class CoordinatesDict:
def __init__(self, x, y,z):
self.x = x
self.y = y
self.z = z
class CoordinatesSlots:
__slots__ = ['x', 'y', 'z'] # Фиксируем атрибуты
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
obj1 и obj2:obj1 = CoordinatesDict(1, 2, 3)
obj2 = CoordinatesSlots(1, 2, 3)
- Какие разницы в этих объектах?
obj1 можно дополнительно объявить новый атрибут, скажем, dist и присвоить ему значение, он пополнит ряды __dict__. В obj2 аналогичная операция вернет AttributeErrorПример:
obj1.dist = 2
obj1.__dict__
>>>{'x': 1, 'y': 2, 'z': 3, 'dist': 2}obj2.dist = 2
>>>AttributeError: 'CoordinatesSlots' object has no attribute 'dist'
Причина такого поведения лежит именно в формировании класса с использованием
__slots__. Такой класс, как говорилось ранее, хранит атрибуты в массиве фиксированной размерности, отключая возможность работы со словарем атрибутов (то есть у вас не появляется __dict__), а все атрибуты, не записанные в массив, поднимают ошибку. __dict__, а следовательно на него не требуется память.Проверить это просто:
print(sys.getsizeof(obj1), sys.getsizeof(obj1.__dict__))
print(sys.getsizeof(obj2))
print(sys.getsizeof(obj2.__dict__))
Вывод следующий (до добавления атрибута):
48 272
56
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
/tmp/ipython-input-390784945.py in <cell line: 0>()
18 print(sys.getsizeof(p1), sys.getsizeof(p1.__dict__))
19 print(sys.getsizeof(p2))
---> 20 print(sys.getsizeof(p2.__dict__))
AttributeError: 'CoordinatesSlots' object has no attribute '__dict__'
Таким образом, если мы имеет часто используемый класс и нам не нужна свобода в изменении состава атрибутов, то правильнее использовать конструкцию со
__slots__Ставь 🔥, если не знал.
Ставь👍, если знал.
#ds_лайфхаки
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тимлид Очевидность | Евгений Антонов
Контекст тимлида
Недавно записывал один подкаст, где одним из вопросов мы затронули контекст тимлида.
Это полезно понимать как для текущего тимлида в разрезе его нагрузки в настоящий момент, так и для тимлида, который приходит в новую команду/компанию, в разрезе того, что ему необходимо добрать, чтобы нормально работать.
Члены команды
Все люди разные и имеют свои особенности, мотивацию, текущие цели, особенности характера, темперамента, разные жизненные ценности, разные жизненные ситуации. На это накладывается, как они взаимодействуют между собой. Этот комбинаторный взрыв нужно знать и следить за ним регулярно, ибо, как говорил Гераклит, «всё течёт, всё меняется».
Рабочие процессы
Понятное дело, тут про всякую организационную и операционную деятельность, которая сейчас в команде присутствует, НО…
Есть еще исторический контекст того, что уже пробовали, что работало хорошо, а что плохо и почему.
Есть еще процессный долг, когда что-то сейчас как-то работает не лучшим образом и/или на ручной тяге, а надо бы это улучшить, но пока не было времени точить пилу, ведь дедлайн скоро и надо пилить.
Проекты и продукты
В вотчине тимлида есть набор проектов и продуктов. Это можно разбить на две части:
- Менеджерская. Проектный менеджмент, планирование, контроль, сроки, дедлайны, риски, KPI, OKR, договоренности с заказчиками и смежниками, ценность самих продуктов.
- Техническая. Само устройство, архитектура, технический долг.
Стратегия
Сейчас как-то всё работает, а как и для чего оно всё будет работать в будущем? Тут тоже 2 стула:
- Менеджерский. Басфактор, подготовка преемника, обучение и развитие команды. Цели и ценность самой команды и как она должна выглядеть в будущем.
- Технический. Технологическая стратегия тоже важна. Не просто «нам нальют х2 пользователей, мы железом ливанем, да и всё».
Наём
Кто-то из команды уходит, или открываются новые вакансии (про которые надо вообще понять, зачем они нужны, сформулировать портрет кандидата и дальше отбором заниматься), надо кого-то прособеседовать, или надо кого-то удержать, или надо, наоборот, кого-то уволить. Всё это тоже в контексте тимлида загружено.
Руководство
Надо хорошо понимать своё руководство: его ожидание, его личность, его особенности работы, то, как и когда по каким вопросам репортить, как просить помощи, как и когда спорить, как не спорить и вот это вот всё.
Политика
Есть хорошая картинка про то, как НА САМОМ ДЕЛЕ выглядит оргструктура https://ic.pics.livejournal.com/talent_a/45400893/2597/2597_original.jpg, и вот понимание этого контекста тоже очень важно. Всегда у людей есть куча неформальных историй, амбиций, притязаний, фаворитизма, протекции, обид, претензий и т. д. При непонимании этих негласных связей можно наступить на невидимые грабли, которых на официальной карте местности не должно быть.
Итог
У тимлида чертова гора контекста, которые ему нужно знать, держать в голове, в планах и регулярно использовать.
Поэтому я всегда диву даюсь, когда слышу «да у него там 2-3 человека, это ж на полдня в неделю менеджерской работы».
Или когда приходит новый тимлид, и от него сразу ждут такой же объем выполнения планов, как от прошлого, в которого этот контекст уже был вгружен и у которого все социальные связи установлены.
Недавно записывал один подкаст, где одним из вопросов мы затронули контекст тимлида.
Это полезно понимать как для текущего тимлида в разрезе его нагрузки в настоящий момент, так и для тимлида, который приходит в новую команду/компанию, в разрезе того, что ему необходимо добрать, чтобы нормально работать.
Члены команды
Все люди разные и имеют свои особенности, мотивацию, текущие цели, особенности характера, темперамента, разные жизненные ценности, разные жизненные ситуации. На это накладывается, как они взаимодействуют между собой. Этот комбинаторный взрыв нужно знать и следить за ним регулярно, ибо, как говорил Гераклит, «всё течёт, всё меняется».
Рабочие процессы
Понятное дело, тут про всякую организационную и операционную деятельность, которая сейчас в команде присутствует, НО…
Есть еще исторический контекст того, что уже пробовали, что работало хорошо, а что плохо и почему.
Есть еще процессный долг, когда что-то сейчас как-то работает не лучшим образом и/или на ручной тяге, а надо бы это улучшить, но пока не было времени точить пилу, ведь дедлайн скоро и надо пилить.
Проекты и продукты
В вотчине тимлида есть набор проектов и продуктов. Это можно разбить на две части:
- Менеджерская. Проектный менеджмент, планирование, контроль, сроки, дедлайны, риски, KPI, OKR, договоренности с заказчиками и смежниками, ценность самих продуктов.
- Техническая. Само устройство, архитектура, технический долг.
Стратегия
Сейчас как-то всё работает, а как и для чего оно всё будет работать в будущем? Тут тоже 2 стула:
- Менеджерский. Басфактор, подготовка преемника, обучение и развитие команды. Цели и ценность самой команды и как она должна выглядеть в будущем.
- Технический. Технологическая стратегия тоже важна. Не просто «нам нальют х2 пользователей, мы железом ливанем, да и всё».
Наём
Кто-то из команды уходит, или открываются новые вакансии (про которые надо вообще понять, зачем они нужны, сформулировать портрет кандидата и дальше отбором заниматься), надо кого-то прособеседовать, или надо кого-то удержать, или надо, наоборот, кого-то уволить. Всё это тоже в контексте тимлида загружено.
Руководство
Надо хорошо понимать своё руководство: его ожидание, его личность, его особенности работы, то, как и когда по каким вопросам репортить, как просить помощи, как и когда спорить, как не спорить и вот это вот всё.
Политика
Есть хорошая картинка про то, как НА САМОМ ДЕЛЕ выглядит оргструктура https://ic.pics.livejournal.com/talent_a/45400893/2597/2597_original.jpg, и вот понимание этого контекста тоже очень важно. Всегда у людей есть куча неформальных историй, амбиций, притязаний, фаворитизма, протекции, обид, претензий и т. д. При непонимании этих негласных связей можно наступить на невидимые грабли, которых на официальной карте местности не должно быть.
Итог
У тимлида чертова гора контекста, которые ему нужно знать, держать в голове, в планах и регулярно использовать.
Поэтому я всегда диву даюсь, когда слышу «да у него там 2-3 человека, это ж на полдня в неделю менеджерской работы».
Или когда приходит новый тимлид, и от него сразу ждут такой же объем выполнения планов, как от прошлого, в которого этот контекст уже был вгружен и у которого все социальные связи установлены.
Forwarded from Остриков пилит агентов
Важные секции, которые должны быть в наших PRD
Плиз проверьте, что эти блоки точно есть, и давайте их располагать в след структуре, чтобы было проще читать:
1. Назначение сервиса
Формат: один абзац, который коротко описывает суть и назначение сервиса, какую задачу он решает на большом ландшафте всей системы.
Planner - отвечает за заведение и запуск новых кампаний для взаимодействия с пользователями через агентов. Отбирает пользователей по сегментам и запускает по ним кампании
2. Глоссарий основных сущностей сервиса
Формат: набор пар термин - описание. Нужно, чтобы всем говорить на одном языке дальше по документу.
Task - задача для агента на общение с пользователем с конкретной целью. Агент должен ее стартануть в определенное время, и довести до завершения
Session - сессия разговора агент-пользователь, начинается с сообщения агента и заканчивается спустя последнее сообщение человека/агента через 2 часа
3. Как внешний мир видит этот компонент
И на каком языке с ним общается. Тут детально расписывается вся внешняя апишка сервиса и другие входящие потоки данных.
4. Модель БД сервиса
Детальное описание всех таблиц, полей, смысла полей, foreign keys constraints и индексов. Пишем все - nullable/not null/default итд. Самая важная секция, max attention - самая дорогая цена ошибки
5. Sequence flow всех основных процессов
По всем процессам есть расписанная по шагам последовательность действий, которые происходят в сервисе, в четкой структуре
6. Внешние сервисы, в которые мы ходим изнутри сервиса
Все внешние системы, в которых мы дергаем ручки/отправляем файлы/пишем в чужие очереди итд.
Главное отличие от пункта 3 - в нем наш сервис как черный ящик, и мы описываем как внешний мир его видит и использует. Тут - наоборот.
- хранилище офферов - забираем оффер в json описании при заведении новой кампании
7. Мониторинги, за которыми мы будем следить и которые будут нам звонить если что-то идет не так
Пишем только криты, которые если происходят, мы в любое время дня и ночи сразу собираем звонок и решаем инцидент
- в табличке messages скопилось больше 500 сообщений от пользователей в статусе NEW, которые мы не разгребаем более 10 минут (то есть процессинг упал)
Зачем такая духота?
Важно, чтобы до программирования (передачи PRD в клод код) мы детально понимали логику будущего сервиса на всех уровнях, без участков "ну тут хуле делать, пусть клод сам затащит"
Второй момент - верю, что при идеально написанном PRD клод будет писать сервис за один промт, а потом потребуется лишь незначительная шлифовка. Если не пишет, будем править claude.md, пока не напишет))
И последнее, ваш PRD может иметь другие доп секции, но убедитесь что текущие присутствуют обязательно и оформлены один в один в том же формате
———
Сидел потел, пробовал оцифровать правила наших PRD для будущих сервисов, без помощи нейронок 🫠
Есть что-то важное, что забыл? За лучший комментарий отправлю Кабанчика бесплатно по России (без шуток)
#prd
Плиз проверьте, что эти блоки точно есть, и давайте их располагать в след структуре, чтобы было проще читать:
1. Назначение сервиса
Формат: один абзац, который коротко описывает суть и назначение сервиса, какую задачу он решает на большом ландшафте всей системы.
Planner - отвечает за заведение и запуск новых кампаний для взаимодействия с пользователями через агентов. Отбирает пользователей по сегментам и запускает по ним кампании
2. Глоссарий основных сущностей сервиса
Формат: набор пар термин - описание. Нужно, чтобы всем говорить на одном языке дальше по документу.
Task - задача для агента на общение с пользователем с конкретной целью. Агент должен ее стартануть в определенное время, и довести до завершения
Session - сессия разговора агент-пользователь, начинается с сообщения агента и заканчивается спустя последнее сообщение человека/агента через 2 часа
3. Как внешний мир видит этот компонент
И на каком языке с ним общается. Тут детально расписывается вся внешняя апишка сервиса и другие входящие потоки данных.
POST /api/v1/offers/create - добавление нового оффера
{"offer_type": "bonus100", "offer_name": "xyz", ...}
PUT /api/v1/campaign/start - ручной запуск компании
{"id": "ieur-er4r4r-4r4"}
4. Модель БД сервиса
Детальное описание всех таблиц, полей, смысла полей, foreign keys constraints и индексов. Пишем все - nullable/not null/default итд. Самая важная секция, max attention - самая дорогая цена ошибки
== tasks (задачи на общение с пользователями) ==
id: bigint - pk
user_uuid: text - index
created_at: timestamp
...
== messages (сообщения чатов) ==
id: bigint - pk
task_id: bigint (fk -> tasks.id) - index
text: text // текст сообщения
role: test // автор сообщения, человек или агент
created_at: timestamp
...
id_task_id - unique constarint
5. Sequence flow всех основных процессов
По всем процессам есть расписанная по шагам последовательность действий, которые происходят в сервисе, в четкой структуре
1. Горутина обработки ответа на сообщение
- подтягиваем прошлую историю переписки из кеша переписок, если кеш пуст, достаем из messages)
- достаем заранее созданные инстанс агента из мапы агентов
- достаем информацию (user context) по пользователю из кеша пользователей (если нет, идем в avalon за данными)
- динамически собираем промт агента, добавляя туда историю, данные пользователя
- запускаем цикл агента, получаем новое сообщение
- сообщение сохраняем в messages + кеш
- отправляем сообщение в whatsup gateway
2. Создание новой кампании
...
6. Внешние сервисы, в которые мы ходим изнутри сервиса
Все внешние системы, в которых мы дергаем ручки/отправляем файлы/пишем в чужие очереди итд.
Главное отличие от пункта 3 - в нем наш сервис как черный ящик, и мы описываем как внешний мир его видит и использует. Тут - наоборот.
- хранилище офферов - забираем оффер в json описании при заведении новой кампании
7. Мониторинги, за которыми мы будем следить и которые будут нам звонить если что-то идет не так
Пишем только криты, которые если происходят, мы в любое время дня и ночи сразу собираем звонок и решаем инцидент
- в табличке messages скопилось больше 500 сообщений от пользователей в статусе NEW, которые мы не разгребаем более 10 минут (то есть процессинг упал)
Зачем такая духота?
Важно, чтобы до программирования (передачи PRD в клод код) мы детально понимали логику будущего сервиса на всех уровнях, без участков "ну тут хуле делать, пусть клод сам затащит"
Второй момент - верю, что при идеально написанном PRD клод будет писать сервис за один промт, а потом потребуется лишь незначительная шлифовка. Если не пишет, будем править claude.md, пока не напишет))
И последнее, ваш PRD может иметь другие доп секции, но убедитесь что текущие присутствуют обязательно и оформлены один в один в том же формате
———
Сидел потел, пробовал оцифровать правила наших PRD для будущих сервисов, без помощи нейронок 🫠
Есть что-то важное, что забыл? За лучший комментарий отправлю Кабанчика бесплатно по России (без шуток)
#prd