Forwarded from прод не упал
Как понять, кто ты по Адизесу
В первой части поста мы разбирали управленческие роли по Адизесу: Производитель, Администратор, Предприниматель и Интегратор. Теперь расскажем, как определить, кто вы или ваши коллеги в этой системе.
Самый точный способ — это официальный тест от Adizes Institute. Его разработала команда самого Адизеса. Он содержит 60 вопросов о ваших поведенческих предпочтениях в работе. Пройти тест можно бесплатно на сайте института — adizes.com, нужно будет только заполнить анкету с контактными данными. Лучше проходить его на английском языке, потому что перевод на русский там так себе.
Кроме официального теста есть еще аналоги, в том числе на русском языке — все они легко гуглятся по запросу "paei тест". Их много, но суть везде одинаковая.
И наверно самый лучший из всех, третий, способ — наблюдать за собой и коллегами. Адизес описывает не "типы личности", а поведенческие роли. И их можно и нужно замечать в жизни.
Например, если вас драйвят результаты и вы свято чтите дедлайны — скорее всего, вы Производитель. Если вам интереснее работать с регламентами, наводить порядок и налаживать процессы, то вы ближе к Администратору. Если вы вечно фонтанируете идеями, предлагаете изменения и подбиваете команду на эксперименты, вы Предприниматель. Любите объединять, слушать и собирать? Поздравляем, вы Интегратор.
В этой связи хорошо работает открытое обсуждение в команде: кратко расскажите коллегам про PAEI, а потом делитесь, кто кем себя (и другого) ощущает. В неформальной обстановке такие разговоры дают много ценной информации, особенно если в команде всё по-честному.
А теперь можно поделиться в комментариях, кем вы себя ощущаете. Только помните, что 1) плохих ролей не бывает; 2) у человека могут быть две ярко-выраженные роли, но не больше.
В первой части поста мы разбирали управленческие роли по Адизесу: Производитель, Администратор, Предприниматель и Интегратор. Теперь расскажем, как определить, кто вы или ваши коллеги в этой системе.
Самый точный способ — это официальный тест от Adizes Institute. Его разработала команда самого Адизеса. Он содержит 60 вопросов о ваших поведенческих предпочтениях в работе. Пройти тест можно бесплатно на сайте института — adizes.com, нужно будет только заполнить анкету с контактными данными. Лучше проходить его на английском языке, потому что перевод на русский там так себе.
Кроме официального теста есть еще аналоги, в том числе на русском языке — все они легко гуглятся по запросу "paei тест". Их много, но суть везде одинаковая.
И наверно самый лучший из всех, третий, способ — наблюдать за собой и коллегами. Адизес описывает не "типы личности", а поведенческие роли. И их можно и нужно замечать в жизни.
Например, если вас драйвят результаты и вы свято чтите дедлайны — скорее всего, вы Производитель. Если вам интереснее работать с регламентами, наводить порядок и налаживать процессы, то вы ближе к Администратору. Если вы вечно фонтанируете идеями, предлагаете изменения и подбиваете команду на эксперименты, вы Предприниматель. Любите объединять, слушать и собирать? Поздравляем, вы Интегратор.
В этой связи хорошо работает открытое обсуждение в команде: кратко расскажите коллегам про PAEI, а потом делитесь, кто кем себя (и другого) ощущает. В неформальной обстановке такие разговоры дают много ценной информации, особенно если в команде всё по-честному.
А теперь можно поделиться в комментариях, кем вы себя ощущаете. Только помните, что 1) плохих ролей не бывает; 2) у человека могут быть две ярко-выраженные роли, но не больше.
Forwarded from прод не упал
Hindsight bias: знание задним числом
Продолжаем говорить о когнитивных ловушках. Сегодня - один из самых коварных сбоев мышления: знание задним числом, оно же hindsight bias.
Это тот самый эффект, когда всё становится "очевидным" только после того, как произошло и хочется сказать что-то вроде: "Да я с самого начала знал, что так и будет, и ежу было понятно".
Прикол тут в том, что на самом деле вы не знали. Но наш мозг не любит неопределённость и с удовольствием подменяет память удобной ему интерпретацией.
В результате мы начинаем верить, что всё предсказали заранее, и, как следствие, не учимся на приобретенном опыте. Не анализируем ошибки, не улучшаем прогнозы, не развиваем системное мышление, потому что "ну и так же все понятно".
Вот пара примеров:
- У вас по каким-то причинам провалился релиз, после чего продакт начинает говорить, что все изначально шло не так. При этом он ничего не предпринял, а за два дня до дедлайна писал, что все окей.
- Отвалился крупный клиент, команда собирается на обсуждение и приходит к выводу, что все сделали правильно, это клиент какой-то мутный оказался. И вообще с самого начала было ощущение, что с ним не сработаемся. А в CRM при этом написано, что у клиента высокий интерес, теплый контакт и вообще все прекрасно.
Как не попасть в ловушку знания задним числом?
1. Фиксируйте гипотезы и ожидания заранее. Перед важным решением коротко запишите, что вы ожидаете. Так вы дадите себе шанс провести анализ, основанный на фактах, а не ощущениях.
2. Не верьте памяти, верьте бумаге. Перепроверяйте старые документы, заметки и письма - они точнее расскажут, что вы на самом деле думали. Воспоминания постоянно меняются, но то, что вы написали навсегда останется в неизменном виде.
3. Оставляйте место для неожиданностей. Если случившееся событие кажется предсказуемым, попробуйте честно спросить себя: а сколько ещё вариантов могло быть? Почему тогда вы не выбрали их?
Hindsight bias - это такой тихий и незаметный враг, напоминающий паразита. Он не шумит, не делает больно и не лишает сна. Он подменяет реальность и тем самым блокирует возможность увидеть зону роста и стать сильнее.
Так что в следующий раз, когда на ум придет "да и так все было понятно", задумайтесь, не попались ли вы в ловушку собственного мышления.
Продолжаем говорить о когнитивных ловушках. Сегодня - один из самых коварных сбоев мышления: знание задним числом, оно же hindsight bias.
Это тот самый эффект, когда всё становится "очевидным" только после того, как произошло и хочется сказать что-то вроде: "Да я с самого начала знал, что так и будет, и ежу было понятно".
Прикол тут в том, что на самом деле вы не знали. Но наш мозг не любит неопределённость и с удовольствием подменяет память удобной ему интерпретацией.
В результате мы начинаем верить, что всё предсказали заранее, и, как следствие, не учимся на приобретенном опыте. Не анализируем ошибки, не улучшаем прогнозы, не развиваем системное мышление, потому что "ну и так же все понятно".
Вот пара примеров:
- У вас по каким-то причинам провалился релиз, после чего продакт начинает говорить, что все изначально шло не так. При этом он ничего не предпринял, а за два дня до дедлайна писал, что все окей.
- Отвалился крупный клиент, команда собирается на обсуждение и приходит к выводу, что все сделали правильно, это клиент какой-то мутный оказался. И вообще с самого начала было ощущение, что с ним не сработаемся. А в CRM при этом написано, что у клиента высокий интерес, теплый контакт и вообще все прекрасно.
Как не попасть в ловушку знания задним числом?
1. Фиксируйте гипотезы и ожидания заранее. Перед важным решением коротко запишите, что вы ожидаете. Так вы дадите себе шанс провести анализ, основанный на фактах, а не ощущениях.
2. Не верьте памяти, верьте бумаге. Перепроверяйте старые документы, заметки и письма - они точнее расскажут, что вы на самом деле думали. Воспоминания постоянно меняются, но то, что вы написали навсегда останется в неизменном виде.
3. Оставляйте место для неожиданностей. Если случившееся событие кажется предсказуемым, попробуйте честно спросить себя: а сколько ещё вариантов могло быть? Почему тогда вы не выбрали их?
Hindsight bias - это такой тихий и незаметный враг, напоминающий паразита. Он не шумит, не делает больно и не лишает сна. Он подменяет реальность и тем самым блокирует возможность увидеть зону роста и стать сильнее.
Так что в следующий раз, когда на ум придет "да и так все было понятно", задумайтесь, не попались ли вы в ловушку собственного мышления.
Forwarded from ИИгорь R&D
Очень толковая статья попалась на хабре. Короткая и по делу вся
Как собрать Docker-образ, который можно запускать в проде (а не только у себя на ноуте) https://habr.com/p/917226/
Как собрать Docker-образ, который можно запускать в проде (а не только у себя на ноуте) https://habr.com/p/917226/
Habr
Как собрать Docker-образ, который можно запускать в проде (а не только у себя на ноуте)
Если ты пишешь Dockerfile , скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это...
Forwarded from Korenev AI - GPT в тапочках🩴
Покрутил в руках dify.ai
Это некий аналог n8n, конструктор, который быстро позволяет создать ИИ сервис с собственной базой знаний.
Сервис, кстати, опенсорсный, можно у себя на локалке развернуть. 103к звезд на гитхабе - столько же сколько у n8n, т.е. эти 2 проекта равнообожаемы
В сервисе реализован гибридный поиск: векторный (семантический) + полнотекстовый
При этом релевантные чанки можно выбирать или по весу, или подключая реранкер cohere
Но не хватает мне в этом сервисе предварительной обработки загружаемых документов. Хотелось бы разметить структуру, сделать саммари разделов - в общем сделать маппинг документа, который потом можно использовать в промпте.
Потестил chunkr.ai - там много разных стратегий обработки документа, включая OCR, но сервис работает только с англоязычными доками, как я понял, во всяком случае мою пдфку на английском разобрал. Ну и по сути это не совсем то, что хотелось бы
Вопрос в зал:
Есть ли опенсорсные решения, которые позволяют делать такой маппинг?
Вопрос2:
Кто в своих проектах успешно использует GraphRag? На каком стеке?
Это некий аналог n8n, конструктор, который быстро позволяет создать ИИ сервис с собственной базой знаний.
Сервис, кстати, опенсорсный, можно у себя на локалке развернуть. 103к звезд на гитхабе - столько же сколько у n8n, т.е. эти 2 проекта равнообожаемы
В сервисе реализован гибридный поиск: векторный (семантический) + полнотекстовый
При этом релевантные чанки можно выбирать или по весу, или подключая реранкер cohere
Но не хватает мне в этом сервисе предварительной обработки загружаемых документов. Хотелось бы разметить структуру, сделать саммари разделов - в общем сделать маппинг документа, который потом можно использовать в промпте.
Потестил chunkr.ai - там много разных стратегий обработки документа, включая OCR, но сервис работает только с англоязычными доками, как я понял, во всяком случае мою пдфку на английском разобрал. Ну и по сути это не совсем то, что хотелось бы
Вопрос в зал:
Есть ли опенсорсные решения, которые позволяют делать такой маппинг?
Вопрос2:
Кто в своих проектах успешно использует GraphRag? На каком стеке?
Forwarded from Korenev AI - GPT в тапочках🩴
Вчера консультировал команду, которая занимается речевой аналитикой. Ребята столкнулись с типичной проблемой: на малых объемах данных все работает нормально, но при увеличении ллм начинает некорректно работать
Слишком большой промпт с кучей подробностей, инструкций и множеством сущностей для классификации. Нужно было много элементов разложить по кучкам, но кучек слишком много, и ллм просто не справляется с такой нагрузкой.
Решение простое: разбить промпт на несколько, чтобы каждый из них выполнял лишь одну конкретную задачу. По моим оценкам этот промпт надо на разбить на 3-5 шагов.
Главное - опытным путем найти оптимальное количество данных, которое конкретная модель может нормально обработать.
Интересно ваше мнение - что еще посоветовали бы начинающим разработчикам?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Карьера в FAANG
Я рассказал, как писать половину performance review -- self assessment документ. В этом, завершающем цикл, посте поговорим о том, как писать вторую половину -- peer feedback.
Ваши коллеги тоже пишут свой performance review, после чего просят вас написать им фидбэк. Вам нужно будет прокомментировать их работу. Но не просто прокомментировать, а так, чтобы ваши комментарии были полезны оценивающему людей комитету. Эту часть нельзя забывать. Так же, как и в вашем собственном документе, в фидбеке неуместны произвольные возгласы похвалы или критики.
Прежде, чем советовать, что делать, посоветую, чего не делать: не нужно помогать коллеге дописать его self assessment своим фидбэком. Не нужно писать -- ах вот тут еще забыл такую-то деталь! Если приходят такие мысли, передайте их автору приватно. Во-вторых, не стоит комментировать человека. Вы даете фидбэк не человеку, а документу. Человеку можно дать фидбэк лично, или его менеджеру, если есть желание. Ваша работа -- строго прокомментировать существующий контент документа.
В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.
Ваши коллеги тоже пишут свой performance review, после чего просят вас написать им фидбэк. Вам нужно будет прокомментировать их работу. Но не просто прокомментировать, а так, чтобы ваши комментарии были полезны оценивающему людей комитету. Эту часть нельзя забывать. Так же, как и в вашем собственном документе, в фидбеке неуместны произвольные возгласы похвалы или критики.
Прежде, чем советовать, что делать, посоветую, чего не делать: не нужно помогать коллеге дописать его self assessment своим фидбэком. Не нужно писать -- ах вот тут еще забыл такую-то деталь! Если приходят такие мысли, передайте их автору приватно. Во-вторых, не стоит комментировать человека. Вы даете фидбэк не человеку, а документу. Человеку можно дать фидбэк лично, или его менеджеру, если есть желание. Ваша работа -- строго прокомментировать существующий контент документа.
В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.
Forwarded from Тоже Паша Техник
RL база.pdf
451.4 KB
живой 🫡
учеба, работа, не совсем успеваю писать
👀 ловите мой "нихуя-как-просто" инсайт с курса по RL у нас в маге.
Без всяких формул и мудрёных греческих букв расскажу, как работает обучение с подкреплением и почему именно оно заставляет большую языковую модель не тупо бубнить текст из интернета, а вести себя так, как нужно нам — слушать промпт, ловко фильтровать бред, фокусироваться на сути и выдавать ответы, за которые реально не стыдно.
Попытался написать максимально просто, но насколько далеко вы прочитаете, зависит от вашего опыта в ML
учеба, работа, не совсем успеваю писать
Без всяких формул и мудрёных греческих букв расскажу, как работает обучение с подкреплением и почему именно оно заставляет большую языковую модель не тупо бубнить текст из интернета, а вести себя так, как нужно нам — слушать промпт, ловко фильтровать бред, фокусироваться на сути и выдавать ответы, за которые реально не стыдно.
Попытался написать максимально просто, но насколько далеко вы прочитаете, зависит от вашего опыта в ML
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тоже Паша Техник
model are only as good as the context provided to them
- компьютер — это агент
- мышка, клавиатура, микрофон — это инструменты и различные источники контекста для LLM
- usb-c хаб — как раз model context protocol
по сути мы действительно "вставляем" все нужные нам инструменты и источники в парадигму MCP и затем просто используем этот протокол как стандартизированный способ общения с "контекстом".
MCP стандартизирует, как AI приложения взаимодействуют с внешними системами – аналогично тому, как API задают правила общения между веб-приложениями и backend.
Протокол охватывает промпты, тулзы и ресурсы.
У нас есть агент, у которого есть инструменты:
- сходить в задачник (jira) по API и вернуть нужную таску конкретного юзера
- сходить в github и сделать PR в репозитории
Агент с первой картинки:
1. на вход юзер подает тикет
2. агент запрашивает таску
3. решает задачку
4. создает pull request на сделанную задачу
также у нас есть еще пара агентов, которые так или иначе используют API jira и github.
- что если API изменилось? — тогда в каждом агенте придется делать правки
- что если вы захотели изменить пайплайн в каком-то агенте, так как API теперь позволяет еще и прикреплять ревьюера к PR? — придется добавить в агента новый интструмент.
а теперь представим, что у нас есть отдельные сервера для jira и github, в которых прописаны какие инструменты есть и как их использовать. Эти сервера имеют стандартизированные ручки, параметры и ответы.
теперь мы берем агента, говорим зачем он создан и даем ему доступ к этим серверам. При инициализации агент сам спросит у серверов, какие у них есть возможности и будет учитывать их при выполнении запросов. (агент на второй картинке)
этими серверами могут делиться другие разработчики, которые уже написали, например, сервер для взаимодействия с figma.
Архитектура MCP базируется на клиент-серверной модели:
- Host Process – основное AI-приложение (например, Claude Desktop или Cursor)
- MCP Clients – клиенты, которые устанавливают отдельное соединение с каждым сервером
- MCP Servers – специализированные серверы, предоставляющие инструменты и доступ к данным
плюсы: упрощает покдлючение и поддержку новых источников для контекста
минусы: первоначальная настройка и подготовка своей инфры под этот протокол, валидация возможностей чужих серверов + написание своих
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from XOR
Андрей Карпаты выложил свой гайд по моделям ChatGPT
Запоминаем:
Сохраняем и больше не ошибаемся в выборе модели.☕️
@xor_journal
Запоминаем:
🟢 o3 — лучшая для сложных задач. Эта модель рассуждений намного сильнее, чем 4o. Поможет с анализом данных и научными статьями. Карпаты использует эту модель в 40% случаев.🟢 GPT-4o — хорошая, быстрая модель для повседневного использования. Карпаты также использует ее в 40% запросов.🟢 GPT-4.1 — отличный выбор при вайб-кодинге.🟢 GPT-4.5 — если вам нужно покреативить или сгенерировать текст, она сильно меньше других галлюцинирует и ошибается. Но для задач кодинга хуже, чем GPT-4.1 или o3.🟢 режим Deep Research — лучший инструмент для исследований. Нужен, если хочется глубоко разобраться в какой-то теме.
Сохраняем и больше не ошибаемся в выборе модели.
@xor_journal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM