#graph #courses

#llm #papers

Продолжаем про капасити эмбов LMок.

Коллеги выложили препринт своей новой статьи. Была у них вот такая работа о том, что замороженные LLM могут восстанавливать тексты определенной длинны из эмбов. И Дядя уже писал об этом в рамках RAG/long context memory (ответом на этот пост и пишу).

Теперь, всё то же самое можно делать за один forward-pass — без итеративного декодинга.
Но теперь нужно уже минимум два вектора.

Что это дает?
Дядя напомнит свой подход к работе с длинными диалогами, когда каждая фраза эмбеддилась в вектор, далее проходила мета-трансформер и получалось закодировать длинный диалог в один вектор. Теперь этот опыт, подтверждается экспериментально и можно с определенной длины не нарезать диалог/текст по фразам, а использовать капасити на " один вектор-К токенов". Т.е. нарезать уже окном длинной в капасити вектора. Таким образом можно использовать эффективный контекст+эмбеддер для эффективного кодирования длинной последовательности. Это может повлиять и на kv-caching и на алгоритмы RAG и на хаку, что я писал на заре канала.

Голосуйте за статью на daily papers.

#llm #papers

Иллюзия мышления: сильные и слабые стороны моделей Chain-of-Thought

В след за Антропик яблочники показали свое исследование внутренностей моделей, на примере рассуждений.
Оно выявило ключевые проблемы современных языковых моделей с цепочками рассуждений (Chain-of-Thought).

Тестировались следующие задачи:
- Башня Ханоя (более 100 шагов)
- Логическая задача с волком, козой и капустой
- Комбинаторные головоломки

Основные выводы:

- Модели не осуществляют реальных рассуждений, а полагаются на память.
- Чем сложнее задача, тем менее вероятно правильное решение.
- Дополнительные шаги размышлений ухудшают результат. Часто простое решение заменяется ошибочным.
- Увеличение вычислительных ресурсов и числа токенов не улучшает итоговую производительность.
- Показательно, что популярная задача "башня Ханоя" решается успешно благодаря частоте встречаемости в датасетах, тогда как классические головоломки типа "волк-коза-капуста" приводят к провалу.

Верим ли мы Apple или личный опыт говорит об обратном?

Я принес. Деньги мотивируют или демотивируют? Финансовая мотивация сотрудников глазами IT-менеджера

Сегодня вам принес видос про деньги-денежки-деньжищи https://www.youtube.com/watch?v=Stpa2FfCP8c

Мне в нем понравился разбор разных исследований, теории справедливости и как вообще деньги влияют на удовлетворенность от работы. Особенно интересно смотрится эксперимент с капуцинами и история про абсолютные и относительные деньги. Например, удовлетворен человек своей зарплатой и всё ему хорошо. Но стоит ему узнать, что соседу платят за примерно (он не знает точно) то же самое на 5% больше, как уже просыпается праведный гнев и сильная дизмораль 🙂

Я по-прежнему продолжаю напоминать, что как бы я ни искал в банковском приложении, всё еще не могу найти, как ипотеку оплатить интересными задачами или дружным коллективом. Тем не менее точно не только на деньгах свет клином сошелся.

Короче, смотрите, составляйте свое мнение, делитесь им в комментариях.

Спасибо Вите Корейше, что мне это видео скинул. Похоже, нового альтернативного человека не из нашего пузыря открыл мне, которого можно посматривать. Самобытный такой персонаж, судя по всему. Люблю такое 🙂

#softskills #speaking

💎 В MIT 40 лет читают лекцию о том, как читать лекции выступать. И она уже несколько лет доступна на Ютубе.

Там всё: как доносить мысль, как структурировать, что делать и не делать со слайдами. Естественно, те же рекомендованные принципы используются в самом мета-докладе.

Даже опытные спикеры могут что-то новое для себя найти, или старое вспомнить, и заиспользовать на основе этой лекции.

Я, например, крепко задумалась про использование реквизита на оффлайн-выступлениях. Патрик во время лекции использует указку, чтобы донести одну идею, и делает это так, что идею зритель точно запоминает. 🙂

Видео здесь, а ниже — цитата из лекции.

“Your success in life will be determined largely by your ability to speak, your ability to write, and the quality of your ideas. In that order." — Patrick Winston

Продолжаю учиться на курсе Школа технического директора от Стратоплана

Продолжаю писать про материалы с курса посвященными процессам. Сегодня распишу своими словами как я понял материал по теме: Строгие и гибкие процессы.

🔵 Введение
Строгие процессы — это чётко прописанные правила и инструкции, которым сотрудники обязаны следовать. Например, выполнение всех шагов в определённой последовательности и соблюдение стандартов качества. Такие процессы помогают избежать ошибок и обеспечить стабильность работы.

Гибкие процессы — это менее жёсткая система правил, позволяющая сотрудникам действовать свободно и адаптироваться к новым условиям. Главное внимание уделяется результатам, а не выполнению заранее установленных процедур. Это помогает быстрее реагировать на изменения и внедрять новые идеи.

Первая мысль которая мне откликнулась в рассказе тренера - строгость или гибкость это очень условные и растяжимые понятия. Чаще всего в реальной жизни процессы это некоторый спектр. По опыту тренера и моему личному - любые крайности это скорее ограничение чем возможность. Тренер также отметил что даже в ГОСТах и различных ISO документах по процессам, которые на первый взгляд должны быть супер строгими и формальными встречаются сноски позволяющие видоизменять и адаптировать процесс под свою ситуацию.

Поэтому имеет смысл попробовать взглянуть на свои процессы через призму и оценить в каких этапах присутствует строгость, а в каких гибкость.

🔵 Как выбрать?
Но если мы только строим процессы - на что нам стоит опереться как базис? На первый взгляд может показаться, что конечно нужно брать гибкие процессы, так как это модно-молодежно. Но такое целеполагание может привести к проблемам (вспоминаем продукты и проекты из прошлого поста). Важно учитывать многие факторы, рассмотрю несколько:

Степень риска - в случае если цена ошибки высока строгий процесс будет предпочтительным чем гибкий.
Динамичность рынка - если мы работаем в высококонкурентной среде где побеждает тот кто зарелизил быстрее, гибкие процессы помогут не застревать на бюрократии и согласованиях. В гибких процессах мы в первую очередь фокусируемся на результате, если есть что-то мешающее его достичь - нафиг.
Квалификация исполнителей - когда у нас есть опытные профи способные сами определить как достичь цели. Для новичков без опыта или с маленьким опытом - наличие инструкций и пошаговых руководств обязательно.
Уникальность / Регулярность задач - если мы делаем нечто инновационное или около того строгие процессы не позволят проявить креативность и творческую жилку. В свою очередь если у нас понятные задачи day by day то гибкость процессов будет скорее вредна, так как доставка ценности может увеличиться из за того что ребята будут делать так как им удобно а не оптимально.

Как найти баланс?
Отмечу главный пункт по моему мнению и который также упомянул тренер - Насаждение культуры инноваций и нетерпеливости к неудобствам. Атмосфера и зрелость сотрудников в отделе или команде должна быть такой чтобы можно было честно и открыто делиться обратной связью, подмечать шероховатости в процессах, предлагать улучшения и брать ответственность за внедрение. Сотрудники должны быть по хорошему жадными и ценить свое время, проактивно приносить руководителю обратную связь по результатам работы.

🔵 Лидерство.
В разных процессах и фокус руководителя будет на разных вещах. Короткое саммари от тренера:

Роль лидера в строгих процессах
- Контроль качества и производительности
- Контроль дисциплины и следования нормативной документации
- Управление рисками
- Корректировка процессов и работа с аномалиями

Роль лидера в гибких процессах
- Создание благоприятной среды для автономности и гибкости
- Контроль дисциплины и следования принятым практикам
- Устранение препятствий для роста и развития
- Культивирование самостоятельности и инициативности

Как видите, отличия сильные, не перепутайте😇
----

На этом всё, пост получился очень большим, при этом я не рассказал и 10% того что было на курсе, так что если у вас появились вопросы после прочтения - пишите в комментарии, поразгоняем обсуждение😊

Решил сделать перерыв от высоких менеджерских материй и запостить простой годноты, которую встречаю в day by day работе.

Сегодняшний лот - статья с подробнейшим разбором такого понятия как CPU Throttling.

Под катом:
- Что такое CPU Throttling, какое влияние оказывает на сервис под нагрузкой?
- Как в K8s работают CPU limits?
- Как можно столкнуться с CPU Throttling на примере Golang?
- K8s limits, requests + GOMAXPROCS
- Milliseconds vs Cores, что будет если установить программе в K8s лимиты < 1?

Очень советую к прочтению, если не сталкивались, это важная и полезная база. И, конечно, проверьте дашборды сервисов на наличие панелек с индикаторами троттлинга, нужная штука при разборе инцидентов.


https://kanishk.io/posts/cpu-throttling-in-containerized-go-apps/

-----

Делитесь в комментариях своим опытом связанным с CPU нагрузками, где и чего оптимизировали, как избавлялись от троттлинга сервисов?😊