Harnessing the Universal Geometry of Embeddings (Рубрика #Security)

Буквально на днях я выступал на PHDays, рассказывая про надежность и безопасность как фундаментальную часть наших систем, отмечая новые риски от AI. Вроде модель угроз была мне относительно понятна, но вчера читая канал Сергея Николенко Sinекура (@sinecor), наткнулся на рассказ про whitepaper "Harnessing the Universal Geometry of Embeddings", в котором авторы буквально разработали метод vec2vec для трансформации векторов из одного пространства представлений (embeddings) в другое. Сергей дальше в своем посте объясняет последствия

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

На практике это очень много чего значит, и в основном не очень хорошее. Получается, что базы данных, которые содержат векторные представления, надо защищать так же тщательно, как исходный текст (чего никто сейчас, насколько я понимаю, не делает). В одном эксперименте они взяли эмбеддинги корпоративных email'ов Enron, перевели их в пространство известной модели (рис. 4) и смогли извлечь чувствительную информацию (имена, даты, суммы) из 80% документов.

В общем, еще один интересный вектор атаки, только уже не на базы с оригинальными данными, а на векторные базы с embeddings. Может у меня дойдут руки и я почитаю этот whitepaper в ближайшее время:)

P.S.
Я подписался на канал Сергея Николенко после того, как написал отзыв на книгу "Глубокое обучение. Погружение в мир нейросетей" 2018 года, соавтором который был Сергей. Суть в том, что один из подписчиков канала сказал, что у автора есть прикольный tg-канал, я проверил - канал оказался действительно интересным и теперь я его иногда почитываю. Спасибо за эту рекомендацию!

#Security #AI #Software #Engineering #Database #Data

Microsoft Build 2025 | Satya Nadella Opening Keynote (Рубрика #AI)

На прошлой неделе Сатья Наделла, CEO Microsoft, открывал большую конференцию MS Build интересным keynote докладом, в котором подключались гости в виде Сэма Альтмана, Илона Маска и других. И вот ключевые моменты, что были в его выступлении

1. GitHub Copilot как автономный агент
GitHub Copilot эволюционировал в полноценного агентного помощника, способного самостоятельно выполнять задачи разработки: от добавления новых функций и исправления ошибок до рефакторинга и генерации документации. Он использует Model Context Protocol (MCP) для взаимодействия с внешними данными и инструментами, а также поддерживает мультимодальные входные данные, включая скриншоты и макеты.
2. Azure AI Foundry: более 1900 моделей и мультиагентная оркестрация
Платформа Azure AI Foundry расширена до поддержки более 1900 моделей, включая интеграцию с Grok 3 от xAI. Она предоставляет инструменты для создания и управления мультиагентными системами, позволяя разработчикам строить сложные ИИ-приложения с высокой степенью кастомизации.
3. NLWeb: открытый протокол для агентного веба
Представлен NLWeb — открытый протокол, позволяющий внедрять ИИ-интерфейсы на веб-сайты с минимальным кодом. Он поддерживает подключение к различным LLM и использует MCP для взаимодействия с контентом сайта, открывая путь к созданию "агентного интернета".
4. Windows AI Foundry: локальная разработка ИИ на Windows
Новая платформа Windows AI Foundry предоставляет инструменты для локальной разработки, оптимизации и развертывания ИИ-моделей на Windows и macOS. Она поддерживает интеграцию с MCP и обеспечивает доступ к системным функциям, таким как файловая система и WSL.
5. Copilot Studio и настройка агентов
Copilot Studio теперь позволяет создавать и настраивать ИИ-агентов, используя внутренние данные компании. Это включает в себя настройку поведения агентов, их взаимодействие с другими системами и поддержку мультиагентных сценариев.
6. Интеграция моделей Grok от xAI в Azure
Microsoft объявила о партнерстве с xAI, предоставляя доступ к моделям Grok 3 и Grok 3 mini через Azure AI Foundry. Это расширяет выбор LLM для разработчиков и снижает зависимость от OpenAI. Именно на этой новости подключался Илон:)
7. Открытие исходного кода Windows Subsystem for Linux (WSL)
Microsoft открыла исходный код ключевых компонентов WSL, включая wsl.exe и wslg.exe, под лицензией MIT. Это шаг к большей прозрачности и вовлечению сообщества в развитие инструмента.
8. MCP как стандарт взаимодействия
MCP становится ключевым стандартом для взаимодействия ИИ-моделей с внешними данными и инструментами. Он обеспечивает унифицированный способ подключения моделей к различным источникам данных и системам, включая Windows и Azure.
9. Microsoft Discovery: платформа для научных исследований
Представлена платформа Microsoft Discovery, использующая специализированных ИИ-агентов для управления научными исследованиями — от генерации гипотез до анализа результатов. Она предназначена для ускорения научных открытий и повышения эффективности исследований. Интересно, что у Google и OpenAI уже были такие платформы
10. Фокус на мультиагентных системах и их оркестрации
Microsoft делает акцент на разработке мультиагентных систем, где агенты могут взаимодействовать друг с другом для выполнения сложных задач. Copilot Studio и Azure AI Agents Service предоставляют инструменты для создания таких систем с возможностью делегирования задач между агентами.

Интересно, что после этого нас порадовал и Google со своей презентацией достижений народного хозяйства на Google I/O 2025

#AI #Software #Engineering

State of platform engineering in the age of AI (Рубрика #AI)

Интересный отчет конца 2024 года, который подготовлен компанией Red Hat совместно с исследовательским агентством Illuminas. Red Hat — мировой лидер в области корпоративных open source-решений, активно развивает платформенную инженерию и внедрение ИИ в инфраструктуру предприятий. Illuminas — опытная исследовательская компания, специализирующаяся на IT и B2B-рынках. Этот отчет построен на опросе 1000 инженеров платформ и IT-руководителей из США, Великобритании и стран Азиатско-Тихоокеанского региона.

Методология исследования была следующей
- Это был онлайн-опрос на 20 минут, где было 1000 респондентов (поровну инженеров и руководителей)
- 35% участников представляло средние компании, а 65% — крупные
- Участвовали сотрудники компаний из отраслей: IT, финансы, ритейл, здравоохранение, профессиональные сервисы
- География опроса: США, Великобритания, англоязычные страны APAC

Ключевые идеи и выводы опроса следующие
1. Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
2. Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.
3. Модель зрелости платформенной инженерии
Red Hat выделяет 4 уровня зрелости:
- Exploring - исследование
- Emerging - начало внедрения
- Established - устоявшаяся практика
- Advanced - продвинутый уровень
Компании с высокой зрелостью достигают на 41% лучших результатов (по продуктивности, инновациям, безопасности).
4. Основные драйверы внедрения
- Безопасность
- Улучшение взаимодействия между командами
- Автоматизация и ускорение процессов
5. Эволюция инвестиций
- На ранних этапах — фокус на модернизации инфраструктуры (55%)
- На продвинутых этапах — автоматизация (85%), безопасность (59%), инструменты для разработчиков (55%)
6. Проблемы и вызовы
На всех уровнях зрелости сохраняются сложности с интеграцией рабочих процессов и рисками безопасности (по 37%).
- На ранних этапах — нехватка навыков и бюджета (40%)
- На продвинутых этапах — несовместимость инструментов, нестабильность платформ, дефицит знаний (около 30%)
7. Метрики успеха
Зрелые компании отслеживают больше показателей (в среднем 7), включая продуктивность, безопасность, производительность приложений, удовлетворённость разработчиков. На ранних этапах чаще фокус на снижении затрат.

Если подводить итоги отчета, то можно заключить, что
- Платформенная инженерия становится отдельной профессией, требующей новых навыков и командной структуры.
- Компании и вендоры должны интегрировать ИИ в платформенные решения, а не рассматривать ИИ как отдельный инструмент.
- Стандартизация архитектур и best practices ускоряет внедрение и снижает риски.
- Безопасность и автоматизация — ключевые приоритеты для будущего развития.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

Code of Leadership #39 - Interview with Denis Pakhomov about social platforms (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Денис Пахомов, который является техническим руководителем в управлении разработки социальных платформ. Возглавляет 14 команд, которые разрабатывают социальную платформу и два продукта на её основе: Пульс и Линк. Команды e2e делают бэкэнд сервисы, мобильные SDK и продуктовые интеграции в клиентские поверхности. Собственно, с Денисом мы поговорили про его путь в IT, а также про развитие социальных сервисов внутри Т.

За час мы обсудили следующие темы
- Знакомство с гостем, обсуждение его биография и старта карьеры
- Переезд в Москву и работа в Сбербанке
- Переход в Тинькофф: работа над маркетинговыми проектами
- Проблемы, новый модуль и его задачи
- Рост команды и управленческие изменения
- Переключение на развитие соцплатформ и объединение команд
- Архитектурные процессы и формирование продукта
- Интеграция решений, внутренняя соцсеть и гибридизация мобильных и веб-платформ
- Культура, структура команд и видение социальных механик
- Роль менеджера, вызовы и советы по развитию

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

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика #Engineering)

Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней

1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий:
- Discuss - обсуждение пользовательских историй
- Distill - выделение критериев приемки
- Develop - разработка
- Demo - демонстрация прототипа
Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей.
2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса.
3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием.
4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга.
5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды.
6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно".
7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества.
8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы.
9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса.
10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось.

В итоге, книга ок с точки зрения базы, но требуется обновление в части
- Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study")
- Использовании актуального стека (например, Playwright или Cypress).
- Интеграции в процессы CI/CD

P.S.
Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей).

#QA #DevOps #Process #Software #Engineering #AI

ArchDays 2025 - CFP (Рубрика #Architecture)

Этой осенью пройдет уже 7 ежегодная конференция ArchDays по software architecture. Я в программном комитете этой конференции с момента ее появления, поэтому не могу не поделиться стартом CFP (call for paper). Если вы хотите выступить на конференции и рассказать доклад об одной из тем: процессы проектирования, практики, инструменты, обучение архитектуре или про собственную разработку, то you are welcome. В этом году, как и в прошлом у нас упор на практику - можно подать заявку на проведение арх каты, порешать арх кейсы или подискутировать насчет разных концепций архитектуры.

В общем, если планируете стать спикером, то вам сюда.
А если вы планируете прийти послушать, то уже можно покупать билеты:)

P.S.
Я выступал на всех предыдущих конференциях ArchDays, что были до этого с разными докладами на тему архитектуры. По ним даже можно отследить как менялась архитектурная повестка у нас в компании:)
1) "Эволюция web’а tinkoff.ru за последние 3 года" в 2019 (youtube)
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" в 2020 (youtube, статья с расшифровкой)
3) "System Design Interview как проверка навыков проектирования систем на собеседованиях" в 2021 (youtube, статья с расшифровкой)
4) "Как подготовиться и пройти System Design Interview" в 2022 (youtube, статья с расшифровкой)
5) "Публичное интервью по System Design про бронирование отелей" в 2022 (youtube, статья с расшифровкой)
6) "Публичное интервью по System Design про простую a/b платформу" в 2023 (youtube)
7) "Архитектура в Т-Банке: вчера, сегодня, завтра" в 2024 (youtube, статья с расшифровкой)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Гибридный поиск на базе OpenSearch и Qdrant / Егор Прохоренко (Рубрика #Architecture)

Интересное выступление моего коллеги, Егора Прохоренко, руководителя отделя поисковых технологий, про гибридный поиск в Т. Гибридный он потому, что Егор и его ребята смешали стандартный полнотекстовый поиск OpenSearch и векторную базу Qdrant для семантического поиска по embeddings. А как они это делали и для чего можно узнать из доклада, в котором были примерно следующие моменты

1. Проблематика поиска в банке
Поиск нужен как клиентам (мобильные приложения, продукты, статьи), так и сотрудникам (внутренние базы, мессенджер, GitLab). В компании достаточно разветвленная инфраструктура - более 100 источников данных и сравнительно высокая нагрузка (1 млн DAU, 150 RPS), много индексов.
2. Концепция гибридного поиска
Гибридный поиск сочетает классический полнотекстовый поиск и векторный (на основе близости эмбеддингов). Это позволяет находить релевантные документы, даже если в них нет прямого совпадения по ключевым словам.
3. Векторные базы данных и их особенности
Векторные БД (например, Qdrant) решают задачу поиска ближайших соседей ANN (Approximate Nearest Neighbor) и часто используют графовый алгоритм HNSW (Hierarchical navigable small world). Хранят вектора и метаданные, поддерживают фильтрацию и масштабирование.
4. Архитектура реализации гибридного поиска
Архитектура делится на слои
- L1 — базовый индекс OpenSearch
- L2 — ML-ранжирование (Catboost)
- L3 — бизнес-логика
Векторный поиск реализован как отдельный сервис, что позволяет быстро экспериментировать и не мешать основному поиску.
5. Эволюция реализации: от монолита к микросервисам
- Первая попытка — интеграция ANN-модуля в монолит на C++ (Elastic), не дала прироста метрик, были проблемы с производительностью.
- Вторая попытка — вынесение векторного поиска в отдельный Python-бэкенд (FastAPI, Qdrant), затем переписан на Rust для ускорения.
6. Фасетная фильтрация и ограничения векторного поиска
В полнотекстовом поиске фильтрация реализуется легко, в векторном — сложно. Пришлось реализовать пост-фильтрацию и комбинированные подходы для отбора релевантных документов.
7. Кеширование эмбеддингов
Для ускорения поиска и снижения нагрузки на эмбеддер реализовано агрессивное кеширование (до 98% cache-hit, 20 млн векторов в кеше).
8. Дообучение моделей и использование пользовательских данных
Для повышения релевантности дообучают эмбеддеры на данных о кликах и релевантности из логов поиска, используют ContrastiveLoss.
9. Объединение результатов полнотекстового и векторного поиска
Проблема была в разных шкалах: BM25 для полнотекста и косинусная близость для эмбеддингов. В качестве решения пробовали разные схемы: нормировка BM25, трафаретные схемы, обучение Catboost-ранжировщика на обоих факторах (это показало лучшие результаты).
10. Масштабирование и ограничения
Гибридный поиск хорошо работает для коротких документов и длинных запросов, снижает число пустых выдач. Для больших документов требуется деление на чанки, поиск идеального решения пока в процессе. Гибридный подход улучшил метрики, но требует сложной архитектуры и постоянных экспериментов.

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

P.S.
Я уже расскаывал про интересный обзор возможностей векторных баз данных, что был в докладе на goto конференции 2024 года "A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias". Этот рассказ хорошо дополняет рассказ Егора.

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