Водоходъ (Рубрика #ForKids)

Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.

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

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)

Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем

- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников» 
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)

Записал расширенную версию доклада, который продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании". Тогда я задал рамку и рассказал про то, как подходить к внедрению AI в крупной компании. А на этот раз я сделал фокус на переходе к агентским сценариям и обсудил следующие темы

- Введение и обсуждение темы доклада
- История ассистентов (GitHub Copilot, Cursor)
- Переход к агентам и почему они выглядят как революция
- Примеры агентов и инструменты (Claude Code от Anthropic, OpenAI Codex)
- Инфраструктура и протоколы (MCP, A2A)
- Экономические предпосылки агентского хайпа
- Примеры успешных кейсов от Google AlphaEvolve
- Будущее работы и уровни агентности в исследовании от Stanford
- Управление и регулирование агентов в исследовании от Google Deepmind
- Эволюция SDLC к агентскому Software Engineering 3.0
- Демо агентского режима внутри Т-Банка на примере игры "5 букв"
- Экосистема разработки и цели инженеров в исследовании "Measuring Developer Goals" от Google
- Внутренняя платформа разработки и Spirit и наш подход к AIфикации разработки
- Агентский режим и работа с данными внутри python notebook
- Агентский режим для обеспечения качества и создания тест-кейсов
- Агент для код-ревью
- Агент для поиска уязвимостей (safeliner)
- Измерение эффективности и фреймворки оценки
- Фреймворк для оценки ассистентов и агентов от платформы DX
- Результаты использования ассистентов/агентов в Т-Банке

Разбор и ссылки на все источники для изучения доступны в моем tg-канале
- https://t.me/book_cube/3925
- https://t.me/book_cube/3931

Выпуск подкаста доступен в Youtube, VK Video.

P.S.
Пройдите опрос, чтобы поучаствовать в нашем про влияние AI на разработку в России.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[2/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career)

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

1) Неделя 1 - Диагностика и рефрейм
- Начать вести энергодневник (5 дней). Отмечайте задачи, которые «заряжают/высасывают». Найдите 2‑3 быстрых улучшения (автоматизация, шаблоны, таймбоксы в расписании)
- Сделать рефрейминг топ‑боли. Например, "Слишком много митингов" можно превратить в задачу "за 2 недели сократить суммарно с 10ч до 6ч через 15‑мин стендапы и ассинк‑апдейты". Это и есть MAP (минимально осуществимая проблема), которую перед собой предлагают ставить авторы
- Разделите гравитацию и задачи. "Акции идут на рынке вниз" - это гравитация; а "у нас нет тестов" - это задача.

2) Неделя 2 - Мини‑эксперименты (bias to action)
- Составьте job backlog: выпишите 10 гипотез, что сделает работу лучше/ценнее; выберите 1 с максимальным эффектом
- Раскатите прототип, например, поставьте добавьте no‑meeting block 2×90 мин в своем расписании, или внедрение pre‑commit hooks с прогоном проверок. Только надо определить метрику успеха заранее.
- Проведите несколько инфо‑интервью. Это могут быть 30‑мин разговоры с людьми из интересных команд/ролей. Просите рассказать истории, а не спрашивайте "есть ли вакансии". Зафиксируйте навыки/артефакты, которые реально ценят.

3) Неделя 3 - Remodel/Relocate
- Составьте 1‑пейджер для изменения в своей работе. Что вы убираете/делегируете, что берёте взамен, выгода для команды, риски, план проверки через 2 недели.
- Попробуйте shadow‑ротацию. Попроситесь на 1–2 технических шэдоу‑слота в соседнюю команду (обзор инцидентов, демо). Это безопасный "relocate‑прототип".

4) Неделя 4 - углубление анализа
- Проведите ARC‑скан. Оцените работу по шкале 1–5: автономия/связность/компетентность и проанализируйте, удовлетворены ли эти потребности в его текущей работе, и как можно улучшить ситуацию.
- Оцените как вы хотели бы выглядеть баланс денег, смысла и саморазвития в работе. В долгосрочной перспективе карьеру нельзя измерять одним показателем (например, только зарплатой)
- Внедрите WIP‑лимиты. Не более 2 параллельных задач; остальное в очередь.
- Практикуйте ритуалы роста. Еженедельный короткий пост‑анализ без обвинений: что попробовать иначе в следующем спринте.

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

#Career #Software #Design

Как продакты, аналитики и дизайнеры создают ценность через мышление (Рубрика #ProductManagement)

Интересное выступление Кирилла Николаева, моего коллеги, директор по аналитике в Т-Банке. Кирилл разбирает, что на самом деле стоит за jobs to be done (JTBD) и почему не всегда цель продукта - "снять трение": иногда продукт должен намеренно заставлять пользователя подумать, если это повышает качество решения и снижает риски.

Если выделять ключевые идеи, то в разрезе ролей они выглядят так
- Product manager задает рамку смысла: он формулирует «работу» (JTBD) и желаемое изменение поведения, а не список фич. Цель - ценность, а не “проще любой ценой”.
- Аналитик переводит гипотезу в проверяемые критерии, выбирает метрики качества решения (не только CTR): ошибки, возвраты, LTV‑эффекты, время принятия решения.
- Дизайнер (когнитивный интерфейс): проектирует правильное трение - подсказки, подтверждения, микро‑обучение - там, где «подумать» критично (финансы, безопасность, ответственность).

Почему не всегда надо упрощать - упрощая без разбора, легко ускорить неверные решения. Добавленное «осмысленное усилие» иногда повышает доверие, снижает ошибки и улучшает долгосрочные метрики.

Что это значит для инженеров/техлидов:
- Инфраструктура экспериментов: feature‑flags, канареечные релизы, дешёвая постановка A/B системы, единая схема событий.
- Телеметрия качества решения: события «я понял/подтвердил риски», отмены, возвраты, ошибочные действия, dwell/time‑to‑decide.
- Доступ к объяснимости: журнал «критических точек мышления» (какие подсказки/правила сработали) для дебага и аудита.
- Ритуалы: единый JTBD‑бриф на 1 страницу; общий план экспериментов; еженедельный «decision review» по качественным и количественным сигналам.

Антипаттерны:
- "Оптимизация на клики": растит метрики, но ухудшает решения.
- "Простота ради простоты": убивает безопасность/ответственность там, где пользователю нужно разобраться.
- Feature-driven без JTBD: лечим симптомы, а не работу пользователя.

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

#Software #Metrics #ProductManagement #Software #Design

Vite: The Documentary (Рубрика #Frontend)

На прошлой неделе вышел документальный фильм про Vite или как один побочный проект Эвана Ю (автора Vue.js) за несколько лет изменил весь фронтенд. Начать стоит с того, а почему Vite так важен. Он появился в ответ на то, что Webpack стал слишком медленным и громоздким. В этот момент Эван Ю, автор Vue.js пытался улушить DevEx инженеров, что писали на Vue и он попробовал радикально другой подход: запускать dev-сервер без бандлинга, отдавая модули прямо в браузер через ESModules. Так появился Vite - инструмент, который:
- Стартует почти мгновенно;
- Обновляет код без перезагрузки страницы (hot module replacement, HMR);
- Компилирует зависимости через esbuild и Rollup, обеспечивая скорость на уровне Rust-решений.

В начале фильма звучит фраза «если вы пишете на современном JS-фреймворке, вы, скорее всего, используете Vite» и это уже не преувеличение. На нем работают Vue, SvelteKit, Nuxt, Astro, Remix, Qwik, Laravel, Shopify Hydrogen и десятки других фреймворков. Авторы фильма рассказывают про таймлайн развития технологии, который выглядит примерно так
- 2020 - Первая версия как dev-сервер для Vue.
- 2021 - Vite 2.0 — мультифреймворк, переход SvelteKit и Laravel.
- 2022 - Экосистема взрывается: ViteConf, Vitest, интеграции с Nuxt 3 и Astro.
- 2023 - Remix и RedwoodJS переходят на Vite; анонс Rust-бандлера Rolldown.
- 2024 - Основана компания VoidZero; Vite 6.0, 17 млн скачиваний в неделю.
- 2025 - Премьера фильма и планы на Rust-реализацию всего стека.

Ключевые факторы DevEx, за которые инженеры полюбили Vite
- Скорость: дев-сервер стартует за секунды, HMR - почти мгновенный.
- Простота: минимальная конфигурация и плагинная архитектура.
- Расширяемость: единая база для React, Vue, Svelte, Qwik и др.
- Интеграции: тестирование (Vitest), Storybook, E2E (Cypress, Playwright), Laravel, Rails.
- Сообщество: 850+ контрибьюторов, десятки компаний (Google, Shopify, Cloudflare, NASA, OpenAI).

Но Vite не стоит на месте и окмпания VoidZero уже пишет на Rust собственные инструменты:
- Rolldown - замена Rollup внутри Vite;
- Oxc - быстрый парсер и линтер;
- Есть планы на «Vite +» - единый стек для сборки, тестирования и форматирования.
- Есть движение в сторону AI - на ViteConf 2025 уже обсуждали агентов, помогающих создавать приложения на Vite.

Фильм получился не только про технологию, но и про сообщество: как инженерный «побочный проект» стал точкой объединения фронтенда.

Раньше я уже рассказывал про другие документальные фильмы из этой же серии и могу рекомендовать их любителям технологий и историй про их создание и развитие.
- Kubernetes Documentary
- eBPF Documentary
- Inside Envoy
- GraphQL: The Documentary
- Node.js Documentary
- Python: The Documentary
- Ruby on Rails: The Documentary
- React.js: The Documentary
- Angular: The Documentary

#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI)

Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже

- Введение и тема выпуска
- Почему оценка ИИ‑приложений сложна; рост важности валидации
- Валидация в пайплайнах и сложности доменов
- Ограничения бенчмарков и переход к продуктовой валидации
- Риски неконтролируемой генерации
- Теория информации: энтропия как база метрик
- Кросс‑энтропия и KL‑дивергенция для оценки моделей
- Перплексия и влияние контекста на уверенность модели
- Функциональная корректность vs нефункциональные требования
- От лексической к семантической близости; эмбеддинги
- Паттерны валидации и AI as a judge
- Попарные сравнения и ранжирование моделей; транзитивность и голосования
- Каркас системы: критерии → выбор моделей → сборка пайплайнов
- Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн
- Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал).
Тезисно этот paper можно сократить до следующих пунктов
1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO
2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели
3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer.
4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC)

Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал)

Если подбивать уроки из истории Monarch, то стоит
- Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости)
- Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения)
- Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн
- Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Что происходит, когда продукт строится не из метрик, а из идеи. История «Сфер» (Рубрика #ProductManagement)

Этот доклад рассказал мой коллега, Иван Турлаев, который уже больше 8 лет развивает мобильные приложения в Т-Банке. Доклад был посвящен созданию и внедрению новой концепции банковского приложения – «Сферы». Предпосылка проста: современные банковские приложения устроены одинаково. Счета, карты, платежи, кредиты – все разложено по привычным категориям. Банки, ориентируясь на метрики и копируя друг друга, выпускают однотипные решения. Но мы решили взглянуть на приложение не со стороны компании, а со стороны клиента и подумать, а что если сгруппировать сервисы не по банковским продуктам, а по жизненным потребностям человека? Так возникла идея «Сфер». Эта концепция родилась не на основе цифр или бизнес-планов - она появилась из стремления сделать сервис понятным и полезным для человека.

Придумать смелую идею мало, ее нужно реализовать. Разработка «Сфер» потребовала объединить усилия множества разрозненных команд. В T‑Банке разные направления (карты, кредиты, платежи, страховки, путешествия и др.) имели свои цели и метрики. Объединить их вокруг новой концепции оказалось непросто. Нужно было убедить менеджеров и разработчиков принять общую идею и найти с ними общий язык. При этом бросить текущие проекты было нельзя.

Проекту помог единый vision, который был подготовлен командой в качестве наглядного концепта нового интерфейса. Увидев цельный образ будущего продукта, разработчики и менеджеры смогли эффективнее взаимодействовать. Обсуждения сместились с узких показателей на пользовательский опыт: фокус на том, как сделать удобнее человеку. Единый дизайн-концепт выступил «клеем», объединяющим команды. Важно было регулярно сверяться с изначальным замыслом и быть настойчивым.

Основой был дизайн-концепт. Команда сознательно отошла от банковских шаблонов интерфейса. Цель - сделать так, чтобы интерфейс говорил на языке жизненных ситуаций, а не банковских продуктов. Дизайнеры экспериментировали с навигацией и визуальным стилем, уходя от перегруженных списков и меню. На главном экране пользователь сразу видит ключевые сферы своей жизни вместо длинного перечня услуг. В итоге, на первом этапе в приложении T‑Банка появились четыре первые «Сферы»: «Шопинг», «Дом», «Авто» и «Путешествия». Каждая стала единым центром для своей темы, объединяя все связанные сервисы банка и партнеров. Например, «Дом» собрал в одном месте оплату коммунальных услуг, страховку жилья и покупки для дома. А «Авто» объединил все для автовладельцев: от штрафов и заправки до страховок и ТО. Такой подход резко отличался от традиционного: прежде эти операции были разбросаны по разным разделам, а теперь клиент решает задачу целиком, не переключаясь между вкладками.

Для инженеров проект «Сферы» тоже стал испытанием. Нужно было интегрировать множество разных систем – внутренних и внешних – в единое целое. Фактически команда создала платформу по принципу супераппа, где разнородные модули работают согласованно ради общего сценария. Архитектуре потребовалась гибкость: унифицированные API, общая навигация, единая система уведомлений - всё для цельного UX. Решения по backend и frontend принимались с оглядкой на задуманный пользовательский опыт, чтобы техническая реализация не испортила UX.

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

#Management #Design #Engineering #Leadership #Project #Metrics #Philosophy

Программирование смыслов (Рубрика #AI)

Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать.

Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам
1) Как всё началось
В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает.
2) Поворотный момент
В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи.
3) Что именно сделали (и где)
- Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов.
- Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение.
- Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы.
4) Машинное обучение как конвейер
Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей
- Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления.
5) Какие проблемы были и как их лечили
- Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры.
- Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают.
- В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код.
6) Принципы ранжирования и ответов
Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха.
Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems