[1/3] A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making (Рубрика #Architecture)

В декабре 2024 года вышел whitepaper на тему использования Gen AI в архитектуре. Я заинтересовался этой темой и решил прочитать что же придумали ребята. Оказалось, что это некоторый co-pilot для архитекторов, который помогает правильные решения. Для этого авторы предлагают использовать паттерны промптинга, что объединяются в цепочку подготовки, анализа и принятия архитектурных решений. Основные паттерны здесь следующие
- Software architect persona pattern
- Architectural project context pattern
- Quality attribute question pattern
- Technical premises pattern
- Uncertain requirement statement pattern
- Prompt pattern sequence
Эти паттерны авторы исследования опробовали на 3 компаниях - двух настоящих (leading automobile financing bank's technological portal и leading retail pharmacy network) и одной вымышленной компании, что по легенде делает cloud-based CRM.

В самом начале авторы рассказывают как выглядит их подход к описанию указанных выше паттернов, куда входят как стандартные аттрибуты вида: Name, Context, Problem, Forces, Solution, Rationale и Consequences, а также расширенный список
- Specializes: описывает, как текущий стандарт специализируется или расширяет существующие стандарты, уточняя их связь и адаптацию для решения конкретных задач или контекстов.
- Statement template: предоставляет краткое описание или структурированное резюме стандарта, позволяя быстро понять его суть.
- Concrete statement example: приводит реальный пример использования шаблона описания, демонстрируя его применение на практике.
- Related patterns: содержит информацию о других паттернах, связанных с текущим, включая зависимости, предпосылки и рекомендации по совместному использованию (связанные паттерны вынесены в приложение к статье)
- Usage example: приводит практический пример из реальной жизни, показывающий применение паттерна и его полезность в конкретной ситуации.
- Known uses: представляет исторические или текущие примеры успешной реализации паттернов, подтверждая их эффективность и предоставляя ссылку на выполненный запрос для получения дополнительных деталей.

Сам flow работы с паттернами и Gen AI инструментами по мнению авторов статьи выглядит так
1) Архитектор ищет подходящие паттерны из списка выше
2) Дальше он применяет их для своего конкретного проекта и получает подсказки и предложения
3) Дальше он принимает решения после анализа сгенерированных подсказок и своего знания проекта

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

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

How To Build The Future: Aravind Srinivas (Рубрика #AI)

Интересное интервью CEO и ко-основателя Perplexity ребятам из Y Cominator. Я сам с большим удовольствием пользуюсь Perplexity как основным поисковым движком, а также ассистентом для размышлений. Именно поэтому мне было интересно глянуть историю о том, а как была создана компания, как она развивалась и куда идет сейчас. В итоге, основные идеи этого выступления примерно следующие

1) Происхождение Perplexity и путь основателя
Аравинд начал свой путь в ИИ с обучения в Индии, после чего переехал в США, где стажировался в OpenAI под руководством Ильи Суцкевера. Именно Суцкевер указал ему на важность обучения без учителя и обучения с подкреплением. После работы в Беркли над неконтролируемыми и генеративными моделями и стажировки в Google, Аравинд пришел к идее, что создание компании с ИИ и разработка продукта неразрывно связаны. Идея Perplexity родилась из поста Дэниела Гросса о создании следующего Google и концепции улучшения формулировки запросов с помощью суффиксов. Первоначально команда экспериментировала с вертикальным поиском и базами данных, используя модели OpenAI Codex для создания SQL-запросов. Это был продукт b2b для поиска по базам данных внутри компаний-закачиков
2) Эволюция продукта
Первый прототип Perplexity был создан за выходные и вдохновлен статьей WebGPT. Хотя изначально использовалась медленная модель 175 AGP, команда применила эвристический подход, выбирая первые k ссылок и краткие описания из кэша. Аравинд отмечает парадоксальный момент: "глупый подход сработал, когда модели стали лучше следовать инструкциям". Это позволило решить проблемы с задержкой в пользовательском интерфейсе, сократив время ответа с 7 секунд до приемлемого значения. Ключевым фактором успеха стала возможность задавать дополнительные вопросы, что удвоило время взаимодействия пользователей с продуктом.
3) Конкурентное преимущество и стратегия
Аравинд не видел прямой конкуренции с Google из-за перегруженности их интерфейса, хотя запуск чата Bing от Microsoft вызвал некоторое беспокойство. В отличие от Google, Perplexity фокусируется на том, что "пользователь всегда прав", требуя уточнений от ИИ. Потребительские продукты, по мнению Аравинда, должны быть проще и удобнее для пользователей.
4) Корпоративная культура и подход к разработке
Основной показатель эффективности компании — количество запросов в день. Еженедельные и ежемесячные данные помогают управлять командой без жесткой иерархии. Компания активно использует Twitter для общения с клиентами, ценя прямолинейную критику больше, чем комплименты. Аравинд подчеркивает важность "дотошных и одержимых людей в команде" и постоянной "борьбы с энтропией" для поддержания качества.
5) Будущее и видение
Аравинд видит Perplexity как "более интеллектуальный поиск", чем Google, стремясь создать место для полного пользовательского опыта. Он планирует построить систему из небольших моделей и графов знаний, уделяя особое внимание управлению ИИ и новым моделям монетизации. В отличие от Google, компания позиционирует себя как организация, "заботящаяся о пользователях и продукте", способная быстро внедрять новейшие модели и обучать их. Это дает Perplexity преимущество в конкуренции с технологическими гигантами, которым сложнее интегрировать инновации из-за их размера и устоявшихся бизнес-моделей.

#AI #Software #Engineering #Storytelling #ML #Architecture

[3/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Продолжим рассмотрение статьи про developer productivity (1 и 2) обсуждение независимых переменных, а также построением самой модели.

Независимые переменные
Авторы взяли в качестве гипотезы 42 независимые переменные, которые по их мнению могли влиять на продуктивность. Эти 42 переменные схлопнулись до 39 после проверки на мультиколлинеарность. Эти данные были доступны из логов и результатов опросов. Все эти переменные были разбиты на 6 категорий
1) Code quality & technical debt - эти факторы связаны с качеством кода и техническим долгом, которые дальше разбираются в деталях. Кстати дальше авторы написали отдельные интересные статьи
- "Developer productivity for Humans, Part 7: Software Quality" - статья про качество, которую я уже разбирал
- "Defining, measuring and managing technical debt" - которую я разбирал с Димой Гаевским в подкасте Research Insights Made Simple, а также разбирал в отдельной статье
2) Infrastructure tools & support - здесь история про выбор инструментов, а также работу инфраструктуры. Часть из этих факторов были разобраны отдельно
- "Build Latency, Predictability, and Developer Productivity" - статья про важность не просто build time, а его предсказуемости и как это влияет на продуктивность, о которой я уже рассказывал
3) Team communication - здесь авторы говорят про коммуникации, дистанцию от менеджеров, код ревью. Кое-что авторы из этого разобрали в дальнейших статьях
- "Developer Productivity for Humans, Part 2: Hybrid Productivity" - это статья про то, как удаленная работа и удаленные коммуникации во время COVID повлияли на продуктивностьЯ рассказывал про нее раньше
- "Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up" - это статья про то, как работает процесс онбординга и как на него повлиял COVID. Я рассказывал про нее раньше
4) Goals & priorities - это про ясность целей и про изменение приоритетов
5) Interruptions - здесь авторы замеряют влияние встреч
6) Organizational & process factors - проблемы из-за процессов, реорганизации и перемещения людей

Дальше авторы использовали квази-экспериментальный метод использования панельных данных для построения связи между воспринимаемой инженерами продуктивностью и независимыми переменными: 𝑦𝑖𝑡 =𝛼𝑖 +𝜆𝑡 +𝛽 * 𝐷𝑖𝑡 + 𝜖𝑖𝑡
Где
- 𝑦 - это самооценка продуктивности для инженера i в момент t
- 𝛼 - это независимые от времени необозреваемые параметры инженера, такие как образование или уровень навыков
- 𝜆 - это независимые от инженера эффекты от времени, например, изменение политики на всю компанию или сезонные эффекты (как январские каникулы в России)
- 𝐷𝑖𝑡 - это измеренные факторы продуктивности для инженера i в момент времени t
- 𝛽 - это причинно-следственныые эффекты факторов продуктивности 𝐷𝑖𝑡 в момент времени t
- 𝜖𝑖𝑡 - это ошибка во время t

Дальше авторы берут производную и получают формулу Δ𝑦𝑖𝑡 = Δ𝜆𝑡 + 𝛽 * Δ𝐷𝑖𝑡 + Δ𝜖𝑖𝑡 , где
- Δ𝜆𝑡 = 𝛾0 + 𝛾1 * 𝑇 и Δ означает разницу между соседними временными промежутками
- T - это категорийная переменная, что означает разницу между периодами
- после дифференцирования 𝛼𝑖 исчезает из уровнения, а Δ𝜆 можно явно контролировать, что говорит о том, что 𝛼𝑖 и 𝜆𝑡 не искажают результаты

Дальше авторы берут метод Feasible Generalized Least Squares (FGLS) и строят корреляции между зависимой и независимыми переменными и оценивают абсолютный эффект и статистическую значимость. Про результаты и ограничения исследования будет в последней части обзора.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Интервью с Глебом Михеевым про Individual Contributors, Site Reliability Engineering и надежность

Летом прошлого года мы записали выпуск подкаста "Фичи Катятся" с Глебом Михеевым, автором канала "Уставший техдир" (@tired_glebmikheev). Примерно в это время Глеб поменял работу и занялся AI-ассистентом в Сбере, поэтому снятое отправилось на полку. А сегодня Глеб опубликовал эту запись, где мы с ним много общались про развитие инженеров, проектирование систем, обеспечение их надежности и безопасности. В общем, за час мы успели обсудить много интересных тем. Вообще, мы часто с Глебом встречаемся на разнообразных конференциях и часто такие разговоры получаются очень насыщенными. Рад, что в этот раз мы записали такое общение на камеру:)

Сам выпуск доступен почти везде: ВК, Rutube, Spotify, Apple Podcast.

#Engineering #Software #Reliability #Architecture #Management #Processes #Leadership