InSAйт

В наших диалогах про ИИ незаметно появилось новое слово – Harness Давайте разберемся, это новая сущность, новый термин, собирательный образ или просто модное словечко? Дословно harness переводится как упряжь или сбруя. То есть то, что помогает в точном управлении 😊 В контексте ИИ harness — обвязка вокруг модели. Всё то, что превращает голый языковой движок в рабочий инструмент: промпты, инструкции, память, инструменты, проверки, логика вызовов. Как пример: 🔥 GPT (API OpenAI) или Claude (Anthropic) - модель 🔥 ChatGPT, Codex, Cursor - уже harness Каким бывает harness на практике? Рассмотрим абстрактное деление по уровням сложности реализации и эксплуатации: ✨ Простой: системный промпт с ролью и правилами. «Делай задачу, как синьор разработчик из FAANG». Уже harness. ✨ Средний: промпт плюс инструменты - поиск, калькулятор, доступ к базе данных. Модель не просто отвечает, а может проводить поиск, исследования, вычисления. ✨ Сложный: полноценная сервисная архитектура, давайте рассмотрим подробнее. Как устроен сложный harness? По сути это набор сервисов с чёткими зонами ответственности: 1⃣ Сервис оркестрации — workflow-движок: принимает входящий запрос, декомпозирует задачу на шаги, управляет последовательностью. 2⃣ Сервис исполнения — вызывает инструменты: внешние API, базы данных, запуск кода. 3⃣ Сервис памяти — два уровня: краткосрочный контекст сессии и долгосрочное хранилище БД. Отвечает за то, что система помнит контекст между вызовами. 4⃣ Сервис валидации — проверяет промежуточные и финальные результаты на соответствие требованиям, фильтрует недопустимые ответы (guardrails), логирует каждый вызов. 5⃣ Сервис роутинга — решает, какую модель подключить под конкретный шаг: дешёвую и быструю или точную и дорогую. Между сервисами уже более классические принципы обещния: входные и выходные данные, таймауты, fallback-логика. Всё как в микросервисной архитектуре, только вместо бизнес-логики внутри каждого сервиса языковая модель. Именно такой harness стоит за продуктами, которые кажутся умными: это просто хорошо упакованные базовые модели. Итого: harness не модное слово. И чем сложнее задача, тем важнее понимать и управлять этой архитектурой.

От школы до сеньора – сегодня на ИТ-Пикнике Сегодня в Москве проходит ИТ-Пикник, и мы тоже будем там. В 14:00 в лектории «Т-Образование» наши системные аналитики Илья и Александра расскажут, как построить карьеру в ИТ: от первых проектов ещё в школе до позиции сеньора – в системном анализе и не только. Приходите – будет насыщенно, полезно и без скучных карьерных шаблонов. А здесь собрали все ссылки из презентации. Сохраняйте, чтобы не потерять 👇 Для школьников – Проекты и образовательные курсы – Т-Класс – Московская Школа программистов – несмотря на название, учиться можно не только в Москве Для студентов и начинающих специалистов – Образовательные программы Т-Образования – Стажировки в Т-Банке – Talents at T-Bank Чтобы познакомиться с Т-Банком ближе – Экскурсии в офисы в Москве и Санкт-Петербурге – Центры разработки в регионах Для тех, кто готов делиться опытом – Стать преподавателем Т-Образования Про всё это, и даже немного больше, расскажем сегодня на ИТ-Пикнике. И да, вы узнаете, при чём тут аниме 😍

Всем привет! 🧡 Думаю, что многие из вас так или иначе занимались аналитическими выгрузками для бизнеса. Выбрать функцию, корректно подобрать группировку и посчитать агрегированные сведения (общее количество, мин. и макс. значения, среднее). Но мало кто смотрел дальше простого GROUP BY, потому что его хватало. А ведь возможности группировки намного шире... 🔍 В ведущих СУБД «из коробки» существует сразу несколько расширений традиционного оператора GROUP BY, позволяющих собирать сложные аналитические отчеты, не прибегая к многочисленному количеству отдельных SQL-запросов или использованию специализированных аналитических скриптов, первому из них и посвящен сегодняшний пост из серии "Продвинутого SQL". Rollup - иерархическая группировка ✉️ Когда полезен ✨ Когда нужны не только общие итоги, но и каскадная группировка по каждому из промежуточного набора уровней. Пример 📁 Допустим, у нас есть таблица grouping со следующим набором данных: | year | month | day | total | |------|-------|-----|-------| | 2025 | 1| 1| 200| | 2025 | 1| 1| 130| | 2025 | 1| 2| 100| | 2025 | 2| 1| 900| | 2026 | 11| 13| 60| Требуется написать запрос, который выведет суммарную прибыль в срезе дней, месяцев и лет. Запрос ☑️ SELECT year, month, day, SUM(total) FROM grouping GROUP BY ROLLUP(year, month, day); Результат ↗️ | year | month | day | total | |------|-------|-----|-------| | 2025 | 1| 1| 330| | 2025 | 1| 2| 100| | 2025 | 1| | 430| | 2025 | 2| 1| 900| | 2025 | 2| | 900| | 2025 | | | 1330| | 2026 | 11| 13| 60| | 2026 | 11| | 60| | 2026 | | | 60| | | | | 1390| То есть, запрос вывел общую сумму за каждый день, агрегированные показатели за каждый месяц, суммарное значение за каждый год, а также общую сумму. А использовали ли вы группировку с ROLLUP в реальных проектах?

😍 Какие планы на следующие выходные? Мы собираем своих в Москве на масштабном офлайне этого лета — ИТ-Пикнике. Это большой фестиваль под открытым небом для ИТ-специалистов и их близких. Соберем в одном месте все, за что любим индустрию, — только без шумных опенспейсов, зумов и горящих дедлайнов. Вас ждут десятки лекций, дискуссии, живая музыка, мастер-классы и интерактивы для всей семьи. Подробнее о них рассказали в карточках. 📅 8 августа 📍 Москва, Коломенское Покупайте билеты на сайте и зовите близких: по одному билету могут пройти двое взрослых и двое детей до 16 лет включительно. Будем отрываться, знакомиться и открывать что-то новое вместе 😍

Что за термин описан?

Всем привет! ⚡️ Одним из важных навыков системного аналитика является умение объяснять сложные вещи простым языком, буквально как для ребенка. И сегодня мы начинаем цикл постов, напрямую развивающих данное качество. Вам будет представлено описание того или иного технического термина глазами ребенка: так, как он понял его смысл. В то же время, будет представлено несколько вариантов ответа, каждый из которых так или иначе подходит под описание. Ваша задача - выбрать то понятие, которое больше подходит под представленное описание. Итак, первая #загадка 🔍 Представь, что ты зашел в лифт и нажал кнопку своего 5-го этажа. Но у кнопки перегорела лампочка, и ты нажал ее еще раз, чтобы убедиться. Но лифт не сошел с ума и не повез тебя на 10 этаж, он просто спокойно привез тебя до твоего 5-го этажа, проигнорировав лишнее нажатие.

И главное - смотреть не только на код, но и на команды. Иногда самый дорогой dependency - это не сервис, а необходимость согласовывать каждую правку с соседним отделом. Зачем всё это нужно? Модульность нужна не ради красивых схем. Она нужна, чтобы систему было проще: - менять - тестировать - разворачивать - масштабировать - поддерживать - не ронять целиком из-за одной ошибки ☕️ Когда связанность управляемая – маленькая правка остаётся маленькой правкой и не превращается в археологическую экспедицию по всей системе.

Знакомая история: меняем одно поле, а потом ловим 10 багов в соседних сервисах. И вроде правка небольшая, но релиз внезапно превращается в расследование. Часто причина не в команде и не в «плохом коде», а в том, как компоненты системы связаны между собой. В архитектуре это называют coupling – связанность. 🔍 Связи сами по себе не зло Без связей не бывает систем. Сервисы вызывают друг друга, модули обмениваются данными, команды договариваются о контрактах. От наличия связи нет проблем, проблема начинается, когда связь становится дорогой для изменения. Простой тест: если вы меняете один компонент, а ошибки появляются в пяти других - со связанность уже что-то не так Coupling - это не «есть связь или нет» Важнее понять, насколько эта связь опасна. Можно смотреть на неё через три параметра. 1. Сила связи Насколько жёстко компоненты зависят друг от друга. Самые болезненные варианты: - один сервис ходит в БД другого сервиса - компоненты завязаны на внутреннюю модель друг друга - изменение поля в одном месте требует синхронной правки в нескольких системах - бизнес-логика "размазана" по разным сервисам Более здоровые варианты: - явный API - DTO - события - контракт, который можно версионировать - ограниченный контекст, где модель принадлежит своему домену Чем меньше компонент знает о внутренностях другого компонента, тем легче жить. 🧡 2. Расстояние Где находятся связанные части Одно дело, когда два метода в одном классе. Другое - два сервиса в разных командах. Третье - интеграция с внешней системой, где изменения нужно согласовывать неделями. Чем дальше компоненты друг от друга технически и организационно, тем дороже связь.И да, изменения архитектуры почти всегда упирается в коммуникацию. Если для изменения нужно синхронизировать три команды, это уже не просто техническая зависимость. 3. Изменчивость Как часто связанные части меняются вместе. Если два компонента редко трогают - сильная связь может годами никого не беспокоить. Если они меняются каждую неделю - даже слабая связь быстро превращается в источник проблем. 📚 Отсюда простая формула: Боль от связанности = сила связи × расстояние × изменчивость Это полезнее, чем просто говорить: «у нас высокий coupling, надо всё переделать». Вопрос не в том, есть ли связь. Вопрос в том, сколько она стоит при изменениях. ✨ А что тогда такое cohesion? Тут часто возникает путаница Coupling — это когда зависят друг от друга разные части системы. Cohesion - это когда внутри одного модуля собраны вещи, которые действительно должны жить вместе. Высокая cohesion – это хорошо Например, всё, что относится к оформлению заказа, лежит рядом: правила, проверки, статусы, переходы, сценарии. Эти вещи часто меняются вместе, поэтому их удобно держать в одном контексте. Плохо не то, что у них сильная связь, а когда они разнесены по разным сервисам, командам и базам, но всё равно должны меняться одновременно. Хорошая архитектура - это когда: - то, что меняется вместе, находится рядом - то, что меняется независимо, можно менять независимо - внешние зависимости идут через понятные контракты - сервисы не лезут во внутренности друг друга - команда понимает стоимость каждой связи ☑️ Иногда сильная связь допустима. Например, есть легаси-система, которая почти не меняется. Интеграция с ней может быть неидеальной, но если её не трогать годами, проблем от этой связи никаких. Архитектура - это не догма, а управление стоимостью изменений. 🔥 Что можно делать на практике: 1. Группировать систему не по слоям «frontend/backend/database», а по бизнес-смыслу. 2. Использовать bounded contexts: одна и та же сущность может по-разному выглядеть в разных частях бизнеса. 3. Обмениваться через API, события и DTO, а не через общую БД и общую внутреннюю модель. 4. Не тащить одну универсальную модель на все сервисы. Она быстро станет общей точкой боли. 5. Делать асинхронные связи там, где это уместно: это снижает жёсткость зависимости и повышает устойчивость.

Привет! Сегодня рассказываем о 5 примерах ошибок при описании UI-элементов — и как их избежать. Ошибка 1: Появляется попап Что в ТЗ? 🔍 После нажатия появляется попап В чем проблема? ⚡️ "Попап" – расплывчатое понятие. Это скорее категория, а не конкретный элемент. Внутри понятия "попап" может быть много элементов: ↗️ Модальное окно (Modal) – блокирует экран, требует действия ↗️ Bottom Sheet – всплывающая шторка снизу ↗️ Тост (Toast) – краткое уведомление, исчезает само ↗️ Баннер (Banner) – полоска сверху/снизу, например для временных уведомлений ↗️Алерт (Alert) – срочное сообщение с критичной информацией В итоге один разработчик реализует bottom sheet, а другой обойдется баннером Что делать? ✨ Детальнее проработывай какое поведение пользователя ожидается при взаимодействии с элементом: нужно просто уведомить пользователя или от него потребуется какое-то действие? Ошибка 2: Хинт под полем Что в ТЗ?🔍 Добавить хинт с лимитами в поле ввода суммы. Когда пользователь введет сумму – подсказка исчезнет В чем проблема? ⚡️ Перепутали плейсхолдер , лейбл и хинт: - Лейбл – пишется над полем. Название поля - Плейсхолдер – пишется внутри поля и исчезает при вводе значения в поле - Хинт – пишется под полем. При вводе значения не исчезает Что делать?✨ Используй строгую терминологию при описании элемента и взаимодействия с ним Ошибка 3: Кнопка Назад Что в ТЗ?🔍 При нажатии на кнопку "Назад" пользователь возвращается на предыдущий экран В чем проблема?⚡️ Пользователь не нажимает на кнопку "Назад", а свайпает вправо📱 или нажимает системную кнопку📱 и приложение ведет себя не так как описано в ТЗ Что делать?✨ Если есть форма, куда пользователь вводит данные — всегда прописывай поведение при выходе: 📚 сохранять черновик? 📚 спрашивать подтверждение выхода? Прописывай не только нажатие кнопок на экране, но и учитывай особенности платформ при навигации: жестовое управление, физические кнопки Ошибка 4: Выберите из списка Что в ТЗ?🔍 При нажатии появляется список для выбора карты В чем проблема?⚡️ 📱 разработчик использует Action Sheet, а 📱 – Dialog. Один и тот же элемент выглядит и ведёт себя по-разному, потому что "список" – тоже не точный термин, а платформы используют свои нативные компоненты ↗️ Action Sheet 📱 – всплывающее меню снизу, закрывается свайпом и кликом на оверлей ↗️ Dialog 📱– всплывающее окно по центру экрана, поверх основного экрана. Обязательно есть кнопки действия («ОК»/«Отмена» или «Выбрать» / «Назад») ↗️ Bottom Sheet 📱 – всплывающее меню снизу. В отличие от 📱, на 📱 может полностью закрывать экран. Закрывается также свайпом и кликом на оверлей Что делать?✨ Вместо "списка" укажи конкретные элементы для каждой платформы Опиши единое поведение: закрытие свайпом вниз и кликом мимо. Так UX будет привычным на обеих платформах, даже если реализация разная Ошибка 5: Работает как раньше Что написано в ТЗ? «Окно закрывается стандартным способом» «Поведение элемента – как на других экранах» В чем проблема?⚡️ Платформы iOS и Android регулярно обновляют системные компоненты и поведение интерфейса. То, что работало в 2022 году, может быть несовместимо с текущей версией ОС Жест "назад" 📱 ↗️ Раньше: пользователь закрывал окно кликом по оверлею ↗️ С Android 10: появился универсальный жест "назад" — свайп с края экрана ↗️Если приложение не обновило логику, жест конфликтует с внутренней навигацией ↗️ Пользователь свайпит – и вылетает из сценария Bottom Sheet 📱 ↗️ Раньше: Bottom Sheet закрывался только по кнопке "Отмена" или кликом по оверлею ↗️ С iOS 15+: пользователи ожидают свайп вниз как основной способ закрытия ↗️ Если свайп не работает — окно кажется "залипшим" и кажется что приложение сломалось Подводя итог, хочется отметить, что главный шаг к недопущению грубых ошибок – это общий язык между командами. И начать стоит с того, как мы называем элементы. А какие «волшебные фразы» из ТЗ преследуют вас в кошмарных снах? Пишите в комментариях — сравним травмы системных аналитиков 🫂

🏦Т-Банк активно участвует в развитии Центрального Университета 🎓 В ЦУ уже есть несколько направлений обучения. Бакалавриат: • 02.03.01 «Математика и компьютерные науки» 🧮 • 38.03.05 «Бизнес-информатика» 💼 • 54.03.01 «Дизайн» 🎨 Магистратура: • Продуктовый менеджмент 📦 • Машинное обучение 🤖 • Продуктовая аналитика 📊 • Backend-разработка 💻 • Школа дизайна 🖌 Можно заметить: среди направлений пока нет наших любимых цифр 09.03.XX – прикладной информатики, информационных систем и технологий и всего, что мы привыкли связывать с системным анализом напрямую. Но это не значит, что системного анализа в ЦУ нет. В этом году практикующие и очень опытные преподаватели из Т-Банка проведут сразу несколько дисциплин, где системный анализ будет в центре внимания. Системный анализ для магистров и бакалавров бизнес-направлений 📈 Большой практический курс о том, как техническим продуктам выстраивать процессы системного анализа в своей команде. Разберём: • что на самом деле происходит на «магическом» этапе написания ТЗ; • когда продукту стоит попробовать выполнить функцию системного аналитика самому, а когда – делегировать её разработчику или аналитику; • какие артефакты действительно нужны и как с ними работать; • на каком языке говорить с командой разработки; • как не заложить бомбу замедленного действия в требования к продукту. Системный анализ для тимлидов 👥 Плавная и вдумчивая подготовка к системному дизайну – с упором на проектирование, качество артефактов и практический инструментарий. Будем без лишней воды разбирать то, чем каждый день пользуются системные аналитики: требования, модели, интеграции, ограничения, сценарии, договорённости и способы думать о системе целиком. После курса станет проще подступиться к системному дизайну – и, конечно, ответить на вечный вопрос: кто такой системный аналитик и чем он на самом деле занимается? 🧐 Системное и критическое мышление 🧠 Софтовая дисциплина для бакалавров. Первый запуск прошёл без нашего участия – исправляем эту недоработку. Теперь учить мыслить будет в том числе самая системная профессия на рынке. Даём знания, подходы и принципы, которые помогают не только в IT, но и в любой сложной жизненной ситуации: разбирать хаос, видеть связи, задавать правильные вопросы и принимать более осознанные решения. Подписывайтесь на канал ЦУ, учитесь сами и учите других ✍️

Привет! Когда коллеги спрашивают меня про предметную область, в которой я работаю, сложно ответить в двух словах... Поэтому начнем с двух терминов: ✨ Сёрвинг - запуск и обслуживание моделей машинного обучения в продакшене ✨ Инференс - получение предсказаний от обученных модели на новых данных Теперь к сути - я занимаюсь платформой сёрвинга и инференса Machine Learning, Deep Learning и Large Language Models. На этапе эксперимента модель можно запустить на своем ноутбуке, но для продакшена требуется система. Ее основные задачи: ⚡ Разместить модель в исполняемой среде – Triton, MLServer ⚡ Предоставить до модели сетевой доступ ⚡ Следить за консистентным состоянием версии модели ⚡ Выполнять соглашение об обслуживании по времени доступности (SLA) Особенность сёрвинга – размещение моделей не только на CPU, но и на видеокартах. GPU – ресурс дефицитный, дорогой, его трудно масштабировать ввиду физических и технологических ограничений: 🔒 На текущий момент не существует гибкого подхода по разделению ресурсов аналогично CPU и RAM - приходится рассматривать каждую видеокарту и учитывать ее ограничения 🔒 Несколько моделей можно разместить на одном сёрвинге, под который будет выделена одна видеокарта, но тогда они могут конкурировать за ресурсы без возможности гибкого масштабирования 🔒 Нужно учитывать совместимость: не все модели можно запускать одновременно из-за ограничений фреймворков или драйверов карт 🔒 Важно даже учитывать себестоимость видеокарт: размещение моделей на определенных ресурсах может быть нецелесообразным Более подробно про одно из программных решений сёрвинга и инференса моделей Triton от Nvidia В итоге, сёрвинг – это не просто хостинг. Обычный бэкенд масштабируется по CPU и памяти, здесь добавляются: 🤍 Специфика GPU 🤍 Чувствительность к сетевым задержкам 🤍 Сложности с версиями и видами моделей, какие мы можем поддерживать. Изюминка на торт – всё это под разные уровни экспертизы пользователей. Мы работаем с разными клиентами: от аналитиков, которым нужно просто получить предсказания через API, до ML-инженеров, которые глубоко понимают модели и четко знают, что им нужно. Здесь задача сделать единый путь, который поможет не заблудиться в мире моделей новичку и даст контроль опытному пользователю. Вывод – не бойтесь этих страшных терминов, это лишь еще одна область знаний, и сегодня вы в ней разобрались ✋

Каждый человек WITH способен на многое. Но, к сожалению, не каждый знает, на что он способен. © Михаил Иванович — таксист, офицер милиции, Бриллиантовая рука Всем привет! 🐾 Для большинства пользователей SQL конструкция WITH – это достаточно простое заклинание, позволяющее немного «причесать код». Однако, стоит добавить к нему безобидное слово RECURSIVE, как эта конструкция превращается в оружие массового поражения. Только представьте себе, как один короткий SQL-запрос разворачивает структуру вложенности из 50+ уровней, на каждом шаге генерируя сотни и тысячи записей, попутно заменяя большое количество кода на уровне backend-а и скорее всего намертво вешая аналитический отчет, так как запрос ушел в бесконечную рекурсию. Чтобы последнее не случилось, нужно хорошо понимать механизм работы рекурсивного WITH, а также задачи, для решения которых он эффективен – этому и будет посвящен сегодняшний пост. Что это такое 👻 Итак, WITH RECURSIVE – это конструкция для создания рекурсивных общих табличных выражений, благодаря чему можно выполнять запросы, которые могут ссылаться сами на себя. Сама команда состоит из 3-х частей: ✨ базовый запрос (база рекурсии) – основной запрос, с которого начинается вычисление ✨ оператор объединения результатов между шагами рекурсии (как правило, используется UNION или UNION ALL) ✨ рекурсивная часть – ссылается на результат предыдущего шага и позволяет накапливать состав строк в запросе Круг задач, в которых полезен рекурсивный WITH: ✨ вывод древовидных структур и иерархий – классическая задача для использования рекурсии ✨ анализ графов и логистики – для перехода по связям между узлами в обе стороны ✨временные ряды – для генерации непрерывного потока данных «на лету» (из альтернатив в PostgreSQL существует функция generate_series) ✨ поиск циклов и валидация данных – в рамках задачи отладки какого-либо функционала Пример В качестве примера рассмотрим популярную задачу, где можно использовать рекурсивный WITH – поиск иерархии сотрудников в компании. Описание таблицы Пусть у нас есть таблица employees со следующим набором полей: – emp_id (идентификатор сотрудника), – name (ФИО сотрудника), – age (возраст сотрудника), – head_emp_id (идентификатор руководителя – FOREIGN KEY со ссылкой на атрибут emp_id этой же таблицы). Построим для этой таблицы полное дерево организационной структуры сверху вниз. Описание запроса WITH RECURSIVE org_tree as ( --1. Базовый запрос SELECT emp_id, name, age, null as head_emp_id, 1 as org_level FROM employees WHERE head_emp_id is null --2. Объединение результатов UNION ALL --3. Рекурсивная часть SELECT e.emp_id, e.name, e.age, e.head_emp_id, org_tree.org_level + 1 FROM employees e INNER JOIN org_tree ON (e.head_emp_id = org_tree.emp_id) ) --4. Итоговый запрос SELECT * FROM org_tree ORDER BY org_level; Описание работы 1. Базовый запрос – начинаем собирать орг. структуру с главных руководителей – у которых не указан head_emp_id. 2. Оператор соединения результатов на каждом шаге рекурсии – для решения задачи достаточно UNION ALL (сработает быстрее UNION за счет сохранения возможных дублей, но в данном случае не повлияет на результат). 3. Рекурсивная часть – на каждом шаге алгоритма обращаемся к результатам предыдущего шага, чтобы к текущему последнему уровню иерархии найти подчиненных. 4. Итоговый запрос к рекурсивному выражению с сортировкой по уровню структуры. А что требуется исправить в запросе, чтобы вывести дерево вверх от конкретного сотрудника (например, с emp_id = 10)? Ответы ждем в комментариях!