Вопрос совсем не наивный, я сам такой список себе собирал.
Из того, что реально можно осилить за разумное время и получить именно практическую пользу, а не университетский курс: Ousterhout, «A Philosophy of Software Design» — тонкая книга, читается за пару вечеров, и это единственная из классики, которую я упоминал в статье не для галочки. Она отвечает на вопрос «что вообще такое хорошая архитектура» без сотен страниц теории, довольно приземлённо и с примерами.
Fowler, «Refactoring» — не читать подряд от корки до корки, а держать под рукой как справочник. Ловишь у себя код с запашком, ищешь конкретный паттерн под него, применяешь. Работает даже в кусках.
Из совсем короткого и практического: Sandi Metz, «Practical Object-Oriented Design» (POODR) — заходит легче, чем классика, много живых примеров, объясняет на пальцах, почему одни решения стареют лучше других.
Отдельно стоит сказать, что многое зависит от специфики того, что вы строите. Современная микросервисная архитектура сама по себе снижает требования к теоретической базе: сервис маленький, границы ответственности заданы инфраструктурой, а не вашим умением проектировать модули внутри монолита, и типичные ошибки из книг про большие системы там просто негде совершить. Если ваш кейс это набор небольших независимых сервисов, польза от глубокого погружения в теорию проектирования будет заметно ниже, чем если вы поддерживаете один большой монолит, где как раз и рождаются все классические проблемы связности и разрастания зависимостей.
Честно говоря, для инфраструктурного инженера я бы вообще не стал начинать с книг. Пользы будет больше от того, чтобы взять реальный существующий проект, желательно не свой, и попробовать внести в него небольшое изменение, обращая внимание не на то, работает ли оно, а на то, легко ли было его вносить. Книги дают язык для того, что вы и так почувствуете руками, но без практики они остаются абстракцией.
Продукты на базе LLM это отдельная история, где модель не просто пишет код, а сама является частью работающего продукта. Таких примеров пока правда немного, но у меня в разработке пара идей именно в эту сторону, и если доведу их до продакшена, обязательно напишу отдельную статью с реальным результатом, а не разговором про процесс.
Про экономику согласен лишь частично, но хочу поделиться своим опытом. Раньше я тоже использовал LLM как консультанта, писал на нём мобильную игру на Godot. Но когда попробовал программировать через агента, а не просто спрашивать советы и просить писать куски кода, это оказался совсем другой уровень работы. Рекомендую попробовать самому хотя бы месяц по платной подписке, это не такие большие деньги на фоне того, сколько времени освобождается на дизайн, продвижение, маркетинг и прочие важные части продукта, до которых руки обычно не доходят.
И да, бесплатно это не работает в принципе, потому что за каждый токен кто-то платит. Бесплатные версии существуют либо за счёт лимитов, либо за счёт того, что вы сами становитесь продуктом в каком-то смысле, и это тоже цена, просто не в деньгах.
Опять же это ваше мнение вы имеете на него право, тем более в сослагательном наклонении, не вижу смысла дальше это обсуждать мы с вами не юристы оба поэтому вряд-ли что-то полезное получится.
1) Как это нерелевантные? "В силу указанных обстоятельств суд обоснованно сделал вывод о том, что при создании агитационного рекламного ролика кандидатом в депутаты Андреевой А.Е. закон об авторском праве не нарушался." ее обвиняли в использовании фразы "Комсомолка, активистка, спортсменка и просто красавица" в агитационном ролике.
2) это ваше мнение у меня свое.
3) Конечно не против, с этим не возможно ничего сделать.
В прокуратуру точно не хочу во первых пошлют куда подальше, а если и не пошлют то это может грозить заключением для нарушителя, я точно такое на душу брать не готов.
1. Про цитату. Если развивать вашу логику, то под авторским правом окажется вообще любая фраза, когда-либо прозвучавшая в фильме или книге, и разговаривать станет невозможно. Есть определение Верховного Суда от 29.02.2008 № 74-Г08-14, там правда про другой фильм - «Кавказская пленница», но сути это не меняет, оно освобождает от авторского права фразы которые на протяжении длительного времени использовалась в качестве шутливых крылатых фраз в разговорной речи.
2. Про переработку картинки. Здесь вообще не важно, рисовал я сам, просил художника или использовал ИИ, инструмент на квалификацию не влияет. Важно, что на выходе получилась карикатура, а карикатура по статье 1274 ГК прямо допускается без согласия автора.
3. Про «парадокс». Никакого парадокса нет, и разница здесь ровно та, которую вы почему-то не хотите видеть.
Одно дело хоть как-то потрудиться и переработать материал: карикатура, рерайт, пересказ своими словами это уже чужой творческий труд поверх исходного. Можно спорить, достаточный ли, но труд есть. Другое дело скопировать текст один в один, вообще ничего не сделав. Это разные ситуации и юридически, и по-человечески.
И два момента, которые ломают вашу аналогию окончательно. Первый: картинка в моём посте не несёт никакой смысловой нагрузки, уберите её и пост не изменится ни на йоту. Сравнивать иллюстрацию-заставку с текстом, который и есть всё содержание статьи, некорректно. Второй: я на своём посте ничего не зарабатываю. А украли мой текст ровно для того, чтобы крутить на нём рекламу. Так что это не «тот же способ», это противоположные ситуации: труд против голого копирования и некоммерческое использование против монетизации чужого.
Конечно я радуюсь что моя статья получилась интересной настолько что кто-то решил ее украсть, но меня совершенно не радует что люди зарабатывают деньги на моем труде даже не спросив, при этом на сайте у них даже нет контактов чтобы с ними связаться.
Про «относительно безопасный» соглашусь, так честнее.
И вообще соглашусь по-крупному: отрасль совсем молодая, полного каталога способов сломаться сейчас нет ни у кого. Три слоя не закрывают неизвестное, они лишь ограничивают цену того, что мы ещё не видели.
Гарантий тут никто не даёт, и обещать их было бы враньём. Но мне как раз этим и интересно. Мы сейчас нащупываем практики примерно как индустрия в своё время нащупывала тесты и канареечные выкаты, и хорошо, что не в одиночку: вендоры выкатывают инструменты для этого довольно быстро, от structured outputs до ограничения прав агентов.
Через пару лет всё это будет выглядеть очевидным, а пока каждый инцидент правда учит. Про веру в абсолютную защиту согласен полностью, она сама по себе фактор риска.
По сути мы говорим одно и то же, в заголовке так и написано, что модель не виновата: ошибся тот, кто внедрял. Пугалку я как раз писать не хотел, наоборот, показать, что при нормальной обвязке это скучная инженерия.
Спасибо за комментарий, с таким стажем в ML взгляд со стороны особенно ценен.
Теперь понял точнее, и по сути вы правы. Одна техническая деталь: подтверждение в моём примере это не permission-правило, которое интерпретирует модель. Claude возвращает запрос на вызов, а решение принимает мой код, и request_human_approval живёт внутри него. Проигнорировать его модель не может, она его просто не видит. Но дальше именно то, о чём вы говорите. Работает это только если мой execute_tool единственный путь к возможности. Есть шелл, ключ или сеть, и агент не обходит approval, а идёт мимо. В кейсе BridgeMind так и вышло: агент написал крон, дёргающий Stripe напрямую полным ключом. Подтверждение никто не игнорировал, его на том маршруте просто не было. Отсюда песочница сводит число маршрутов к одному, а обвязка на этом маршруте добавляет гранулярность, которую периметр не выражает: одну отмену можно, все сразу нельзя. Так что согласен, изоляция должна была идти нулевым слоем, а не подразумеваться. Спасибо, что дожали.
Статья про архитектуру с principle of least privilege, и в ней ни слова про sandboxing, интересно.
Изоляция подразумевалась как базовый уровень, но кейс у меня чуть другой, и песочницей он не решается. Допустим агенту по условию задачи нужно уметь отменить подписку, это его прямая работа. Нельзя ему только одно: отменить их все разом. И пеосчницей такое не решается.
С кейсом Шумера согласен полностью, там отказал именно периметр, агенту отдали машину целиком. Изоляция это лучший первый рубеж, и тема тянет на отдельную статью, в эту честно не влезла.
Citations API не защищает от галлюцинаций
Соглашусь, и сформулирую точнее, чем в статье. Citations проверяет не истинность, а атрибуцию: закрывает ровно один класс ошибок, выдуманные ссылки и цитаты, которых в источнике нет. Именно он и утопил Deloitte, там были несуществующие работы и приписанная судье фраза.
Остальные классы требуют других контролей. Неверная интерпретация верной цитаты ловится семантической сверкой и ревью человеком, обрезанная цитата (ваш Черчилль эталонный пример) проверкой контекста вокруг фрагмента, а заражённые источники это вообще про доверие к корпусу, тут нужен whitelist. Ни один механизм не закрывает всё сразу, они набираются послойно. Беда Deloitte не в неправильном выборе инструмента, а в том, что не было ни одного.
провал не в том, что не был использован Citations API, а в том, что отчеты вообще генерируются ИИ
А вот здесь не соглашусь. Вопрос не в том, участвует ли модель, а в том, как устроен процесс вокруг неё.
Deloitte утонула не потому, что применила ИИ, а потому, что применила его без единого контроля и без ответственного, который прочитал бы результат. Сноски никто не открыл, семантику никто не сверил, а подпись под документом всё равно стояла. Замените модель на подрядчика-джуна, которому никто не сделал ревью, и получите ровно тот же скандал, только медленнее.
Мой тезис как раз в том, что при правильно выстроенной обвязке и с человеком в контуре такие отчёты делать можно и нужно. Обвязка не отменяет человека, она сокращает объём того, что ему приходится перепроверять руками: вместо сплошной вычитки двухсот страниц остаётся десяток непроверенных утверждений и итоговые выводы.
Спасибо за разбор, Черчилля заберу себе как пример.
Образование мехмат МГУ, так что с вероятностями всё в порядке. И как раз поэтому скажу: никто не пытается превратить вероятность в единицу, задача другая.
Про Perplexity вы абсолютно правы, это отличный пример. Проверить, что цитата существует, и проверить, что вывод из неё корректен, это два разных контроля, и второй не автоматизируется.
Но часть проверок всё же чисто детерминированная, там вероятности нет вообще. Сравнить цитату с исходным текстом это сравнение строк. Ключ с правами read only не отменит подписку ни при каком настроении модели. А для оставшихся, действительно вероятностных ошибок обвязка ограничивает уже не вероятность, а масштаб: circuit breaker не делает агента умнее, он превращает «отменил все подписки» в «отменил три и остановился». Примерно как TCP поверх ненадёжного IP.
И маленькое уточнение: это не моя архитектура, а набор паттернов, которые рекомендует сам вендор. Ручная проверка один из них, но не единственный, и хорошая обвязка как раз сокращает объём того, что приходится перепроверять руками.
Спасибо за вдумчивый комментарий, такие вопросы полезнее похвалы.
Ваши опасения абсолютно обоснованны, ведь буквально две недели назад они выпустили ещё три сертификата. Но я внимательно посмотрел их программу и думаю, что она станет де-факто стандартом в отрасли ИИ, точно так же, как в своё время сертификационные программы Cisco и AWS.
Да, LLM постоянно развиваются. Но стратегия того же Anthropic не предполагает учить нейронку пользоваться всеми инструментами подряд, тем более инструментами, которые внедрены конкретно у вас в компании. И в этом, собственно, и есть суть их сертификационной программы: Anthropic делает модель, а адаптацию под конкретную инфраструктуру заказчика сознательно перекладывает на плечи сертифицированных партнёров, то есть людей, которые знают и возможности модели, и специфику внедрения. Под это выстраивается партнёрская сеть, и сертификация является её ключевой частью: она гарантирует, что партнёр это не самоназвание, а проверенная квалификация.
Спасибо, приятно слышать!
Вопрос совсем не наивный, я сам такой список себе собирал.
Из того, что реально можно осилить за разумное время и получить именно практическую пользу, а не университетский курс: Ousterhout, «A Philosophy of Software Design» — тонкая книга, читается за пару вечеров, и это единственная из классики, которую я упоминал в статье не для галочки. Она отвечает на вопрос «что вообще такое хорошая архитектура» без сотен страниц теории, довольно приземлённо и с примерами.
Fowler, «Refactoring» — не читать подряд от корки до корки, а держать под рукой как справочник. Ловишь у себя код с запашком, ищешь конкретный паттерн под него, применяешь. Работает даже в кусках.
Из совсем короткого и практического: Sandi Metz, «Practical Object-Oriented Design» (POODR) — заходит легче, чем классика, много живых примеров, объясняет на пальцах, почему одни решения стареют лучше других.
Отдельно стоит сказать, что многое зависит от специфики того, что вы строите. Современная микросервисная архитектура сама по себе снижает требования к теоретической базе: сервис маленький, границы ответственности заданы инфраструктурой, а не вашим умением проектировать модули внутри монолита, и типичные ошибки из книг про большие системы там просто негде совершить. Если ваш кейс это набор небольших независимых сервисов, польза от глубокого погружения в теорию проектирования будет заметно ниже, чем если вы поддерживаете один большой монолит, где как раз и рождаются все классические проблемы связности и разрастания зависимостей.
Честно говоря, для инфраструктурного инженера я бы вообще не стал начинать с книг. Пользы будет больше от того, чтобы взять реальный существующий проект, желательно не свой, и попробовать внести в него небольшое изменение, обращая внимание не на то, работает ли оно, а на то, легко ли было его вносить. Книги дают язык для того, что вы и так почувствуете руками, но без практики они остаются абстракцией.
Продукты на базе LLM это отдельная история, где модель не просто пишет код, а сама является частью работающего продукта. Таких примеров пока правда немного, но у меня в разработке пара идей именно в эту сторону, и если доведу их до продакшена, обязательно напишу отдельную статью с реальным результатом, а не разговором про процесс.
Про экономику согласен лишь частично, но хочу поделиться своим опытом. Раньше я тоже использовал LLM как консультанта, писал на нём мобильную игру на Godot. Но когда попробовал программировать через агента, а не просто спрашивать советы и просить писать куски кода, это оказался совсем другой уровень работы. Рекомендую попробовать самому хотя бы месяц по платной подписке, это не такие большие деньги на фоне того, сколько времени освобождается на дизайн, продвижение, маркетинг и прочие важные части продукта, до которых руки обычно не доходят.
И да, бесплатно это не работает в принципе, потому что за каждый токен кто-то платит. Бесплатные версии существуют либо за счёт лимитов, либо за счёт того, что вы сами становитесь продуктом в каком-то смысле, и это тоже цена, просто не в деньгах.
И вы считаете что я должен, чисто по человечески, на это забить?
Юридическую тренировку лучше начинать с теории государства и права, это вам любой юрист скажет.
Вот, давайте лучше на этом уровне обсудим.
Вы действительно по сути разницы не видите между картинкой не важной и полным копированием текста?
Опять же это ваше мнение вы имеете на него право, тем более в сослагательном наклонении, не вижу смысла дальше это обсуждать мы с вами не юристы оба поэтому вряд-ли что-то полезное получится.
1) Как это нерелевантные? "В силу указанных обстоятельств суд обоснованно сделал вывод о том, что при создании агитационного рекламного ролика кандидатом в депутаты Андреевой А.Е. закон об авторском праве не нарушался." ее обвиняли в использовании фразы "Комсомолка, активистка, спортсменка и просто красавица" в агитационном ролике.
2) это ваше мнение у меня свое.
3) Конечно не против, с этим не возможно ничего сделать.
В прокуратуру точно не хочу во первых пошлют куда подальше, а если и не пошлют то это может грозить заключением для нарушителя, я точно такое на душу брать не готов.
1. Про цитату. Если развивать вашу логику, то под авторским правом окажется вообще любая фраза, когда-либо прозвучавшая в фильме или книге, и разговаривать станет невозможно. Есть определение Верховного Суда от 29.02.2008 № 74-Г08-14, там правда про другой фильм - «Кавказская пленница», но сути это не меняет, оно освобождает от авторского права фразы которые на протяжении длительного времени использовалась в качестве шутливых крылатых фраз в разговорной речи.
2. Про переработку картинки. Здесь вообще не важно, рисовал я сам, просил художника или использовал ИИ, инструмент на квалификацию не влияет. Важно, что на выходе получилась карикатура, а карикатура по статье 1274 ГК прямо допускается без согласия автора.
3. Про «парадокс». Никакого парадокса нет, и разница здесь ровно та, которую вы почему-то не хотите видеть.
Одно дело хоть как-то потрудиться и переработать материал: карикатура, рерайт, пересказ своими словами это уже чужой творческий труд поверх исходного. Можно спорить, достаточный ли, но труд есть. Другое дело скопировать текст один в один, вообще ничего не сделав. Это разные ситуации и юридически, и по-человечески.
И два момента, которые ломают вашу аналогию окончательно. Первый: картинка в моём посте не несёт никакой смысловой нагрузки, уберите её и пост не изменится ни на йоту. Сравнивать иллюстрацию-заставку с текстом, который и есть всё содержание статьи, некорректно. Второй: я на своём посте ничего не зарабатываю. А украли мой текст ровно для того, чтобы крутить на нём рекламу. Так что это не «тот же способ», это противоположные ситуации: труд против голого копирования и некоммерческое использование против монетизации чужого.
Конечно я радуюсь что моя статья получилась интересной настолько что кто-то решил ее украсть, но меня совершенно не радует что люди зарабатывают деньги на моем труде даже не спросив, при этом на сайте у них даже нет контактов чтобы с ними связаться.
Хорошо вы правы и вы меня убедили, я не буду использовать это изображение.
Я действую в рамках ГК РФ Статья 1274 и я никакой выгоды коммерческой от этого не имею в отличие от сайта который полностью украм мою статью.
Про «относительно безопасный» соглашусь, так честнее.
И вообще соглашусь по-крупному: отрасль совсем молодая, полного каталога способов сломаться сейчас нет ни у кого. Три слоя не закрывают неизвестное, они лишь ограничивают цену того, что мы ещё не видели.
Гарантий тут никто не даёт, и обещать их было бы враньём. Но мне как раз этим и интересно. Мы сейчас нащупываем практики примерно как индустрия в своё время нащупывала тесты и канареечные выкаты, и хорошо, что не в одиночку: вендоры выкатывают инструменты для этого довольно быстро, от structured outputs до ограничения прав агентов.
Через пару лет всё это будет выглядеть очевидным, а пока каждый инцидент правда учит. Про веру в абсолютную защиту согласен полностью, она сама по себе фактор риска.
По сути мы говорим одно и то же, в заголовке так и написано, что модель не виновата: ошибся тот, кто внедрял. Пугалку я как раз писать не хотел, наоборот, показать, что при нормальной обвязке это скучная инженерия.
Спасибо за комментарий, с таким стажем в ML взгляд со стороны особенно ценен.
Теперь понял точнее, и по сути вы правы. Одна техническая деталь: подтверждение в моём примере это не permission-правило, которое интерпретирует модель. Claude возвращает запрос на вызов, а решение принимает мой код, и request_human_approval живёт внутри него. Проигнорировать его модель не может, она его просто не видит. Но дальше именно то, о чём вы говорите. Работает это только если мой execute_tool единственный путь к возможности. Есть шелл, ключ или сеть, и агент не обходит approval, а идёт мимо. В кейсе BridgeMind так и вышло: агент написал крон, дёргающий Stripe напрямую полным ключом. Подтверждение никто не игнорировал, его на том маршруте просто не было. Отсюда песочница сводит число маршрутов к одному, а обвязка на этом маршруте добавляет гранулярность, которую периметр не выражает: одну отмену можно, все сразу нельзя. Так что согласен, изоляция должна была идти нулевым слоем, а не подразумеваться. Спасибо, что дожали.
Изоляция подразумевалась как базовый уровень, но кейс у меня чуть другой, и песочницей он не решается. Допустим агенту по условию задачи нужно уметь отменить подписку, это его прямая работа. Нельзя ему только одно: отменить их все разом. И пеосчницей такое не решается.
С кейсом Шумера согласен полностью, там отказал именно периметр, агенту отдали машину целиком. Изоляция это лучший первый рубеж, и тема тянет на отдельную статью, в эту честно не влезла.
Соглашусь, и сформулирую точнее, чем в статье. Citations проверяет не истинность, а атрибуцию: закрывает ровно один класс ошибок, выдуманные ссылки и цитаты, которых в источнике нет. Именно он и утопил Deloitte, там были несуществующие работы и приписанная судье фраза.
Остальные классы требуют других контролей. Неверная интерпретация верной цитаты ловится семантической сверкой и ревью человеком, обрезанная цитата (ваш Черчилль эталонный пример) проверкой контекста вокруг фрагмента, а заражённые источники это вообще про доверие к корпусу, тут нужен whitelist. Ни один механизм не закрывает всё сразу, они набираются послойно. Беда Deloitte не в неправильном выборе инструмента, а в том, что не было ни одного.
А вот здесь не соглашусь. Вопрос не в том, участвует ли модель, а в том, как устроен процесс вокруг неё.
Deloitte утонула не потому, что применила ИИ, а потому, что применила его без единого контроля и без ответственного, который прочитал бы результат. Сноски никто не открыл, семантику никто не сверил, а подпись под документом всё равно стояла. Замените модель на подрядчика-джуна, которому никто не сделал ревью, и получите ровно тот же скандал, только медленнее.
Мой тезис как раз в том, что при правильно выстроенной обвязке и с человеком в контуре такие отчёты делать можно и нужно. Обвязка не отменяет человека, она сокращает объём того, что ему приходится перепроверять руками: вместо сплошной вычитки двухсот страниц остаётся десяток непроверенных утверждений и итоговые выводы.
Спасибо за разбор, Черчилля заберу себе как пример.
Спасибо, очень рад что вам откликнулось.
Образование мехмат МГУ, так что с вероятностями всё в порядке. И как раз поэтому скажу: никто не пытается превратить вероятность в единицу, задача другая.
Про Perplexity вы абсолютно правы, это отличный пример. Проверить, что цитата существует, и проверить, что вывод из неё корректен, это два разных контроля, и второй не автоматизируется.
Но часть проверок всё же чисто детерминированная, там вероятности нет вообще. Сравнить цитату с исходным текстом это сравнение строк. Ключ с правами read only не отменит подписку ни при каком настроении модели. А для оставшихся, действительно вероятностных ошибок обвязка ограничивает уже не вероятность, а масштаб: circuit breaker не делает агента умнее, он превращает «отменил все подписки» в «отменил три и остановился». Примерно как TCP поверх ненадёжного IP.
И маленькое уточнение: это не моя архитектура, а набор паттернов, которые рекомендует сам вендор. Ручная проверка один из них, но не единственный, и хорошая обвязка как раз сокращает объём того, что приходится перепроверять руками.
Спасибо за вдумчивый комментарий, такие вопросы полезнее похвалы.
Спасибо, поправил
Ваши опасения абсолютно обоснованны, ведь буквально две недели назад они выпустили ещё три сертификата. Но я внимательно посмотрел их программу и думаю, что она станет де-факто стандартом в отрасли ИИ, точно так же, как в своё время сертификационные программы Cisco и AWS.
Да, LLM постоянно развиваются. Но стратегия того же Anthropic не предполагает учить нейронку пользоваться всеми инструментами подряд, тем более инструментами, которые внедрены конкретно у вас в компании. И в этом, собственно, и есть суть их сертификационной программы: Anthropic делает модель, а адаптацию под конкретную инфраструктуру заказчика сознательно перекладывает на плечи сертифицированных партнёров, то есть людей, которые знают и возможности модели, и специфику внедрения. Под это выстраивается партнёрская сеть, и сертификация является её ключевой частью: она гарантирует, что партнёр это не самоназвание, а проверенная квалификация.
Например тут https://www.claudecertifiedarchitects.com/