#softskills #career

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

Всем привет! Давно не было постов про курс, исправляюсь, нужно отрефлексировать полученные знания. Последний пройденный модуль был посвящен IT инфраструктуре в широком смысле.

Первый день модуля начался с разговоров о софте. Рассуждали и искали ответы на вопросы:
- Как бороться с Legacy? И стоит ли вообще? Можно ли его побороть?
- Осознанный выбор технологий
- Vendor-lock: различные варианты последствий. Митигирование рисков
- Покупка или свой велосипед: тренер довольно подробно рассказал о том на что обращать внимания в обоих вариантах.

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

-----

Далее перешли к проектированию: тут для меня не нашлось откровений, разобрали Закон Конвея и его обратную модификацию. Тренер высказал мысль с которой я живу со времен универа - цель любой архитектуры помимо достижения НФТ и ФТ это также достаточная степень гибкости, адаптации к изменениям. Обсудили в том числе то как реальный мир устроен, и какие мероприятия позволяют нам держать эту гибкость на нужном уровне.

Контент хороший, тренер постарался, но для себя я много нового не открыл, многие вещи на собственном опыте прожил.

-----

Закончили день разбором ключевых процессов разработки софта. Тренер подробно прошелся по 3м китам:
- Разработка (Проектирование, Жизненный цикл)
- Эксплуатация (SRE)
- Контроль качества (QA)

Если говорить в целом, осталось хорошее впечатление от контента, добавилось структуры + увидел что у меня довольно сильно пересекаются взгляды с тренером и ребятами в группе. При этом по годам опыта я значительно моложе ребят :)

Завтра опубликую отдельную заметку о втором дне модуля, на нем обсуждали закупки. Вот там для меня было прям много нового и незнакомого, все таки я в своей работе подобным почти не занимался.

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

Как и обещал, сегодня пост про второй блок модуля IT инфраструктура, изучали то как устроены закупки и как CTO должен ими управлять.

Тренер подошел к вопросу системно: прошлись по определениям из PMBOK, рассмотрели обобщенную схему как проводить закупки:
- Планирование
- Проведение
- Контроль
- Закрытие

Отдельно разобрались с тем какие ресурсы CTO может приобрести для своей компании (Рабочие руки, экспертиза, Софт, Инфра, Данные)

Отдельно прошлись по тому какие есть варианты контрактов:
- Fixed Price
- Cost Plus Fee
- Time and Material

Разобрались на примерах в каких задачах более уместен тот или иной вариант. Также рассмотрели какие риски мы несем в каждом из вариантов.

По сути разобрались с первыми 2мя этапами закупок (Планирование и проведение)

Отдельный блок тренер посвятил контролю закупок. Тренер рассказал про несколько вариантов:
🔸 Заранее договориться о наборе метрик на которые смотрим вместе с поставщиком (PROJECT метрики, Kanban, SCRUM).
Очень классный момент отметил тренер, сильно мне врезался в ухо. Процитирую почти дословно: ДЛЯ КОНТРОЛЯ ЗАКУПОК ОЧЕНЬ ВАЖНО СМОТРЕТЬ НЕ НА ROADMAP, Диаграмму Ганта или ПРОЕКТНУЮ ДОКУМЕНТАЦИЮ а на РЕАЛЬНОЕ ПОЛОЖЕНИЕ ДЕЛ. Проектная документация это всего лишь интерпретация реальности и с не самым добросовестным поставщиком можно обжечься. В общем фактура ван лав.

🔸Инспекции и аудиты
Нужны в том случае если фактура пропадает из поля зрения и действия поставщика перетекают в интерпретацию. Или появились проблемы с доверием.

🔸Отчетность об исполнении
Отчеты, метрики (с достаточным уровнем фактуры). Особенно важно для последующего ретроспективного анализа, поиска точки когда была допущена ошибка и что-то пошло не так.

И отдельно разобрались с тем как осуществлять контроллинг в зависимости от типа контракта с поставщиком.

Завершился день разбором сложнейшей темы - Развитие отношений с поставщиками и построение своей партнерской сети😊

#audio #petproject

#gan #petproject

#gan #petproject

#gan #petproject

Тут dreamina.capcut.com обновила интерфейс, при этом сохранила баги (все как мы любим😊).

Подсказал @astrolog_expert
- Регистрируем аккаунт под IP Аргентины (есть и другие страны)
- Смотрим чтобы слева у нас было 0 поинтов (значит все получилось)
- Переключаемся на IP США, и генерим все что нам нужно.
Это не безлимит, я доставал до дна. Но развлечься можно.

P.S. Еще у меня получалась сбрасывать потраченные баллы к исходным ежедневным, если переключить VPN во время генерации с Аргентины на США.
P.S.S. Кидайте в комменты, чего получилось нагенерить👇👇👇.

Пожалуйста!

#tips

https://streammydata.ru/otkryvaya-mir-cepej-markova-ponimanie-i-primenenie-v-atribucii/

Статья по цепям Маркова, по которой мы с моим CTO делали проект по скриптам, считающим коэфы Маркова для каждого месяца активности пользователей в году.

Очень будет полезна маркетинговым аналитикам.

Эта статья даст базу для цепей Маркова и у вас после нее уже будут результаты и какие-то коэффициенты, что круто, научитесь считать в питоне их.

Скажу сразу, у нас получилось немного по другому, в статье не объясняют откуда 50 степень для стационарного состояния (спойлер, степень должна быть больше любой сессии любого пользователя в плане количества пользовательских событий)))) и немного странно считают removal эффект, мы считали чуть-чуть по другому.

Слишком много подсказывать не буду, NDA вся фигня😎

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

4 методики работы с контекстом LLM

В Паттерне 4 мы поняли, насколько важно использовать контекст в LLM-системе.
Сейчас давайте разберемся, как это можно делать. Все эти правила прекрасно изложены в статье.

1) Запись во внешнюю память

Очень похоже на то, как люди работает с информацией. В момент поступления данных LLM может догадаться, что это важние знания и записать их куда-то. Например, в текстовый файлик. Это популярный метод, так делает рисерч агент Anthropic.

Не нужно засорять контекст, пихая в него всю информацию. Пускай модель использует только нужное для решения конкретной задачи в текущем состоянии.

2) Выбор нужного из внешней памяти

К долгой памяти нужно обращаться и искать полезные куски. Ровно также, как вы ищете в вашем блокноте полезные записи. То есть делаете RAG по памяти. Искать можно кучей вариантов, не зацикливайтесь на эмбеддингах:

- Если память маленькая, можно прочитать ее всю

- Можно размечать тегами разные участки памяти, например "error" для ошибок, и дальше искать по тегам

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

3) Суммаризация

Часто информации настолько много, что ее проще хранить/использовать в сжатом виде. Обычно делают так: если токенов > X, тогда отдельный LLM-call суммаризует последнюю историю. Это позволяет свежую информацию хранить полностью, а старую уже менее детально.

Так делает Google со своим Gemini, когда агент играет в Покемонов (я кстати в жизни ни разу не играл, расскажите, как оно?).

4) Разделение контекста

В мультиагентских системах разумно иметь изолированные контексты разных LLM. У них могут быть свои задачи/тулы/история.

Еще можно делить контекст не с другими агентами, а с внешней средой. Например, если вы общаетесь со средой черед код, как это делает Huggingface, то среда вам может отдать только название переменной, а весь контент хранить у себя.

Например, агент будет значть, что в VAR1 лежит список всех покупок пользователя. Но сам список он может и не читать, чтобы не засорять контекст.

Нудное послесловие

Разработка крутых LLM-систем это всегда про эксперименты и креатив. Я запрещаю зацикливаться на простых решениях, типа, пихаем в контекст все. Или фиганем эмбеддинги, FAISS потом разберется. Позаботьтесь о себе и о вашей LLM.

Как обычно, рад вопросам по теме в комментариях. Если нужно разобрать ваш кейс — можно в личные сообщения.

🦑 Привет, друзья!

Меня не было тут почти месяц, хотя я не прекращала работать. Или пытаться это делать. В последнее время думаю о выборе магистратуры, учу математику и пытаюсь допинать статью. Думаю ещё, чем точечно в интерпретируемости хочу заниматься и куда хочу идти.

Думать сложно, но я пытаюсь.

Вернуться хотелось как-то красиво, поэтому я с новым туториалом: LIME for Time Series Data.

LIME (Local Interpretable Model-Agnostic Explanations) — популярный модет в решении задачи интерпретации. Он основан на простой идее — приблизить прогнозы сложного оценщика (например, нейронной сети) простым — обычно линейной/логистической регрессией.

Применить LIME можно из коробки при помощи одноименной библиотеки [lime]. Однако, при применении LIME к, в частности, к временным рядам возникают особенности,
поэтому в чистом виде lime для TimeSeries не всегда легко применить.

И в этом туториале мы сделаем приближенение метода самостоятельно! И получим красивые, очень красивые, графики.

Как всегда, вместе с Хабропостом, код на гитхаб.

Скучала, и надеюсь вернуться из творческого кризиса,
Ваш Дата-автор! ❤️