Расшифровка рассказа о курсе «Проектирование ИТ-решений с использованием Cursor AI»
(Из ленты Архитектура информационных систем)
Я транскрибировал текст прошедшего вебинара про курс «Проектирование ИТ-решений с использованием Cursor AI» , но решил не выкладывать целиком 28 страниц текста, а выбрать некоторые ключевые моменты. Получилось существенно меньше
Фрагмент 1. Забегая вперед, я позволю себе сформулировать одно очень распространенное заблуждение, которое касается Cursor и похожих программ. Почему-то многие думают, что эти программы пишут код на основании того, что мы напишем в prompt-е. Но на самом деле Cursor, Windsurf и всякие другие инструменты не менее внимательно вычитывают все наши файлы, которые у нас есть в текущем каталоге и подкаталогах. Даже если эти файлы явно не указать в качестве контекста, он изучают, что там написано и генерят вот это самое новое содержание с учетом того, что уже успели подсмотреть, прочитать в наших существующих описаниях. Это, на мой взгляд, крайне неплохо для архитектуры решения. Ну просто потому, что архитектура решения в значительной степени строится на типовых решениях на тех программных интерфейсах, источниках данных, подходах, технологиях, которые уже есть в организации, то есть нам очень важно, чтобы вот эта преемственность была соблюдена.
Возможно, многие из вас заметили в начале года панические настроения, рассказы о том, что всех нас уволят, всех нас заменят: разработчиков, тестировщиков, аналитиков, архитекторов, всех заменит искусственный интеллект. Вот эти разговоры они достигли какого-то определенного пика и даже во ряде компаниях в ИТ-отделах началось определенное замешательство. Все не понимали, что делать, стали звучать слова Shadow AI. Т.е. мы попали в ситуацию, когда некоторой растерянности. На мой взгляд, ситуация изменилась и во второй половине года. Уже этой растерянности нет. Я общаюсь со многими компаниями и в значительном количестве из них говорят примерно одни и те же слова, наверное, чаще других звучит слово RAG (retrieval-augmented generation).
Фрагмент 2. Я постарался на одну картинку собрать список идей о том, почему RAG вселяет во всех такой оптимизм. На самом деле не только в корпоративной среде, но мне интересно в первую очередь про корпоративные информационные системы поговорить. И в качестве первого пункта в этой истории я отметил, что что RAG решения занимает потенциально выгодную позицию между пользователями и технологиями. Если сделать ретроспективу того, чем занимались корпоративные айтишники предыдущие 50 лет, посмотреть на эту историю под определенным углом зрения, то можно понять, что все это время корпоративные ИТ вставали между пользователем и технологией, и определенным образом помогали пользователю правильно, контролируемо, безопасно использовать ту или иную технологию.
То есть можно прямо начать, с каких-нибудь реляционных баз данных, которые появились в начале 70-х годов. Изначально предполагалось, что с ними непосредственно будет работать пользователь: юрист, финансист, бухгалтер. На SQL-образном языке он будет писать запросы, создавать таблички и так далее. Потом выяснилось, что у пользователей это получается не очень хорошо. Что им нужно помогать правильные таблички создать и правильные запросы, написать и появились корпоративные информационные системы. Поначалу еще даже без графического интерфейса просто с command line interface, которые позволяли правильные команды пользователям отправлять и просматривать ответы системы. Точно так же случилось практически с любой другой технологией. Между интернетом и пользователем вырос кеширующий прокси. Между мобильным телефоном и пользователем выросло приложение корпоративной мобильности и так далее. Не буду эту историю размусоливать.
А второй, на мой взгляд, важный момент. То, что RAG до сих пор не работает в режиме, что называется “из коробки”. Там постоянно нужно экспериментировать, подкручивать, настраиваться на контент, заниматься всеми этими вещами. То есть корпоративным айтишникам занятий хватит на несколько лет вперед. Потому, что нельзя пойти и что-то такое готовое запустить, так, чтобы все работало. Скорее наоборот, если вы послушаете, что обсуждают люди, которые уже встали на этот путь, и им занимаются то, услышите, что постоянно вылезают те или иные нюансы. Постоянно можно где то, что-то улучшить. И шаг влево, шаг вправо из предметной области приводит к тому, что половину решения нужно, вообще говоря, если не переделывать, то донастраивать.
И эта настройка включает обязательную интеграцию с имеющимися корпоративными данными. Получение данных из существующих корпоративных систем тоже любимое занятие корпоративных айтишников взять, вытащить данные из одной, другой, третьей, четвертой существующей системы, отдайте их какому-нибудь новому приложению; сделать новое решение с использованием того, что уже имеется.
Следующий, на мой взгляд, не менее важный момент связан с тем, что нам очень хочется сохранять инвариантность относительно моделей, относительно технологий, относительно векторных баз данных и пр. Всякие вот такие хорошие вещи делать, и здесь тоже как бы нужен человек, который за всем этим делом будет следить.
Ну и давайте я, наверное, с этого слайда буду постепенно уходить, чтобы на нем не зависать. Т.е. есть определенная перспектива у этого направления и у agentic RAG и у похожих вещей. Т.е. сформировался некоторый мейнстрим, с которым более-менее интересно разбираться, а главное, что это полезно. Я думаю, открывается перспектива на некоторое количество лет вперед.
Фрагмент 3. Давайте посмотрим результаты, то есть артефакты, которые мы будем создавать в ходе этого учебного курса. Вот у меня список из пять таких результатов. Причем традиционные архитектурные вещи, то есть то, что архитекторы обычно разрабатывают, то, о чем я говорил в других учебных курсах, я написал справа. По сути, в курсе “Мастерская проектирование ИТ решений” мы говорим об архитектурных диаграммах, которые так или иначе формируют архитектурное описание или High Level Design. Практически не говорим мы про architecture vision и очень вскользь, затрагиваем записи архитектурных решений. Просто потому, что создание всех этих артефактов требует усилий, требует некоторого времени, и в короткий курс не очень просто это поместить.
Теперь нам все это доступно, теперь мы можем создать и High Level Design и Architecture Vision и набор архитектурных решений ADRs и диаграммы включить во все эти документы. Сделать общие диаграммы, частные диаграммы, связать это все с описанием постановки задачи. Обвешать это оценками вот то, что называется evaluations(evals) в ИИ, некоторые проверочные оценки, которые позволяют нам ответить на вопрос, а правильный или неправильный мы результат получили. Так как результаты работы моделей, вероятностные, нам постоянно нужно себя проверять. Ну а заодно и проверять то, что там люди напишут руками. В общем, это тоже не всегда хорошие результаты. То есть мы выстраиваем некую систему.
Я бы здесь обратил внимание на записи архитектурных решений. В значительной степени это становится наиболее продвинутым инструментом формирования архитектуры. Просто потому, что можно, конечно, попросить языковую модель, написать нам архитектурное описание на сто страниц. И она нам напишет какое-нибудь большое архитектурное описание. В нем будет много чего, а потом мы будем долго и нудно его править, потому что оно будет не вполне актуально. Лучше править небольшое архитектурное решение — запись на страничку; иметь набор архитектурных решений, из которых выбирать те, которые нужно отразить, допустим, в vision и те, которые нужно включить в более объемные документы — в описание архитектуры, это крайне полезно. То есть вот разбив задачку на такие вот маленькие кусочки и сочетая их между собой, можно добиться, на мой взгляд, достаточно хороших результатов.
C другой стороны, если мы хотим делегировать написание каких то ADRs моделям, то это нужно каким то образом контролировать и направлять. Для этого, конечно, в первую очередь нужно использовать шаблоны, но architecture vision тоже не лишняя штука. Так что два основных новых артефакта, на котором мы сделаем акцент в курсе “Проектирование ИТ решений…” – это записи архитектурных решений (architecture decision records, ADRs) и формулирование именно architecture vision. Это своеобразные рельсы, по которым поедет наша архитектура, а архитектурные описания будут неким обобщением, неким результатом, который будет из ADRs получаться.
Фрагмент 4. Три ключевые характеристики нового учебного курса, на которых я хочу расставить акценты:
Во-первых, это полноценный курс по архитектуре решений. Как я сказал раньше, это продолжение “Мастерской проектирования ИТ-решений”, в котором мы больше акцент делаем на конкретные архитектурные документы. Еще раз повторю, в “Мастерской…” я бы очень хотел сделать сквозной пример — практическую работу по созданию некоего архитектурного описания. Раньше, за 24 академических часа это было сделать крайне затруднительно. Сейчас мы можем замахиваться на такие истории, но просто потому, что часть вещей мы сделаем своими руками, а часть вещей нам помогут нагенерить соответствующие приложения.
А второй факт, касающийся курса, состоит в том, что мы изучим Cursor. Мы разберемся, что это за штуковина такая, построенная на базе VSCode, что она умеет, как она организована, как она сконструирована на самом деле, что умеет или не умеет делать, в каком объеме может генерить диаграммы, создавать и оценивать документы. Может быть, немножко кода мы тоже погенерим. Но совсем чуть-чуть если мы и будем код генерить, то просто для того, чтобы какие-то архитектурные вещи проиллюстрировать. А на самом деле я хочу обратить ваше внимание, что изменение подходов к разработке софта, все эти замечательные среды: курсоры, антигравитации и прочее, они достаточно сильно влияют на те ожидания, которые у разработчиков формируются относительно архитектуры. Те, по сути, архитектура теперь должна помогать моделям создавать код. Как это сделать, что там уже работает, а что еще не очень работает, где и как нужно поправлять, как запустить вот этот итерационный процесс улучшения — это то, что мы в ходе курса непременно обсудим.
Ну и последнее, как бы вишенка на торте. Тот самый сквозной пример, о котором я давно мечтал. и для курса по solution architecture. У нас есть в других курсах сквозные примеры. Заявки на подключение домашнего интернета — в курсе про распределенные архитектуры (курс про микросервисы) или ArchiShurance Case Study в корпоративной архитектуре. А вот в курсе про архитектуру ИТ-решений у меня такого примера не было. Но в этом курсе он будет.
Мы будем проектировать (обращаю ваше внимание, не разрабатывать, а проектировать) некое корпоративный RAG решение, которое называется aiExpert, которое позволяет отвечает на вопросы относительно нашей корпоративной архитектуры. Не какой-то абстрактной, не про то что там в Интернет написано. aiExpert будет рассказывать о том, как на нашем предприятии все устроено. Какие у нас есть принципы, правила ограничения системы, какие типовые решения мы можем использовать. Какие-то вещи он будет проверять из того, что мы наделаем, будет помогать создавать картинки, точно так же как это умеет делать курсор. Это, в общем, не очень сложно. Вот такое приложение мы будем проектировать. Естественно, оно будет находиться не в безвоздушном пространстве, естественно, оно будет там интегрироваться с корпоративными информационными системами и взаимодействовать с внешними интерфейсами и источниками данных. Я в эту историю непременно включу спеки внешних интерфейсов, мы обязательно их подложим в нужные места, в нужные каталоги определенным образом предоставим нашей системе и попросим, с использованием этих интерфейсов чего-нибудь нам нагенерить.