Claude Certified Architect – Foundations: Руководство по подготовке к экзамену

О руководстве

Это руководство составлено на основе детального разбора вопросов в формате экзамена для сертификации Claude Certified Architect – Foundations. В нём разобраны мультиагентные архитектуры, управление контекстом, проектирование инструментов и принципы пакетной обработки с акцентом на архитектурные компромиссы и лучшие практики, а не на техники промптинга.

Как устроен экзамен

Экзамен Claude Architect Foundations проверяет способность проектировать отказоустойчивые, готовые к продакшену AI-системы. Он состоит из сценарных вопросов с множественным выбором, охватывающих Domain 1: Agentic Architecture, Domain 4: API & Orchestration и Domain 5: Context Management. Экзамен отдаёт приоритет структурным, детерминированным решениям (например, проектирование схем и границы инструментов) над вероятностными подходами (например, инструкции в промпте).

Рассматриваемые сценарии

Руководство охватывает ключевые архитектурные сценарии, с которыми вы, скорее всего, столкнётесь:

• Агентные архитектуры: порождение субагентов, параллелизм и декомпозиция рабочих процессов.
• Управление контекстом: устранение эффекта «потери в середине», раздувания контекста и сохранение происхождения данных через суммаризацию.
• Проектирование инструментов и схем: применение бизнес-правил, стандартизация вывода и проектирование машиночитаемых идентификаторов для цепочек инструментов.
• Пакетная обработка и состояние: возобновление упавших сессий, оптимизация буферов SLA и обработка частичных сбоев в батчах.

---

Вопросы и ответы

Q1: Обработка семантических ошибок в итогах извлечения

Сценарий: Проектирование схем и самокоррекция

Вопрос: Автоматизированный пайплайн извлечения счетов-фактур иногда выдаёт структурированный JSON, в котором сумма извлечённых позиций не совпадает с итоговой суммой, извлечённой из счёта. Какой архитектурный подход лучше всего подходит для обработки этой семантической ошибки?

Варианты:

• A) Добавить поле calculated_total рядом с полем stated_total, сравнивать их и отправлять несоответствия на проверку человеком.
• B) Автоматически корректировать значения позиций так, чтобы их сумма математически совпадала с заявленным итогом.
• C) Добавить вторичный шаг с LLM для устранения математических ошибок.
• D) Добавить больше few-shot примеров с правильной математикой в промпт.

✅ Правильный ответ: A — извлекать calculated_total и помечать расхождения

Почему это правильно: JSON-схемы предотвращают синтаксические ошибки, но не семантические (например, неверные вычисления). Наиболее надёжный паттерн самокоррекции — извлекать одновременно то, что документ явно указывает (stated_total), и то, что модель вычисляет из позиций (calculated_total). При несовпадении запись помечается для проверки человеком. Это повышает надёжность без фабрикации данных.

Почему остальные варианты слабее:

• B) Корректировка позиций создаёт значения, не подтверждённые документом, нарушая целостность данных.
• C) Добавляет излишние архитектурные накладные расходы, когда доступна явная детерминированная валидация.
• D) Few-shot примеры не могут гарантировать детерминированную согласованность для арифметики.

💡 Вывод для экзамена: Проектируйте потоки самокоррекции, извлекая одновременно заявленное и вычисленное значения, и направляйте несоответствия на проверку человеком, а не «исправляйте» ошибки исходного документа молча.

---

Q2: Масштабирование доработки промптов vs. пакетная обработка

Сценарий: Пакетная обработка и оптимизация затрат

Вопрос: Вы готовитесь обработать 50 000 устаревших документов с помощью Batch API. Первоначальный тест на 500 документах показывает, что 18% из них требуют 2–3 итерации доработки промпта для корректного извлечения данных. Какая стратегия наиболее экономически эффективна для масштабирования этой нагрузки?

Варианты:

• A) Интерактивно доработать промпт на репрезентативной выборке для максимизации успеха с первого прохода, затем обработать все 50 000 документов через Batch API.
• B) Использовать Batch API для немедленной обработки всех 50 000 документов, выявить сбои в масштабе и повторно отправить их.
• C) Обработать 50 000 документов через синхронный API для динамической доработки промпта по каждому документу.
• D) Начать отправку батчей по 5 000 документов для постепенного изучения режимов сбоев в продакшене.

✅ Правильный ответ: A — сначала доработать интерактивно, затем запустить пакетную обработку

Почему это правильно: Руководство явно рекомендует дорабатывать промпты на репрезентативной выборке до пакетной обработки больших объёмов. Итеративные повторные отправки в масштабе уничтожают экономию затрат от Batch API. Устранив режимы сбоев на локальной выборке, вы обеспечиваете надёжность промпта и максимизируете успех с первого прохода при запуске батча на 50 000 документов.

Почему остальные варианты слабее:

• B) Оплата обучения промпту на батчах продакшен-размера приводит к масштабным дорогостоящим циклам повторных отправок.
• C) Синхронный API лишает вас 50% экономии затрат от Batch API.
• D) По-прежнему оплачивает итеративное изучение сбоев в большом масштабе.

💡 Вывод для экзамена: Сначала доработайте промпты на репрезентативной выборке для максимизации успеха с первого прохода, затем запустите полный объём через Batch API, чтобы минимизировать дорогостоящие повторные отправки.

---

Q3: Расписание Batch API для SLA

Сценарий: Управление SLA и асинхронные API

Вопрос: Ваша система обрабатывает асинхронные пользовательские запросы со строгим соглашением об уровне обслуживания (SLA), требующим выдачи результатов в течение 30 часов с момента отправки. Вы планируете использовать Message Batches API, выполнение которого может занимать до 24 часов. Какое расписание отправки батчей лучше всего соответствует SLA при максимальной экономической эффективности?

Варианты:

• A) Отправлять батчи каждые 6 часов.
• B) Отправлять один большой батч в конце каждого дня.
• C) Использовать синхронный API для гарантированного соблюдения SLA.
• D) Отправлять батчи каждые 4 часа.

✅ Правильный ответ: D — отправлять батчи каждые 4 часа

Почему это правильно: Общее время обработки в худшем случае — это время ожидания документом следующего окна батча плюс максимальное время выполнения батча (24 часа). При окне в 4 часа: 4 + 24 = 28 часов — укладывается в SLA 30 часов с буфером 2 часа. При окне в 6 часов: 6 + 24 = 30 часов — ровно на границе SLA без буфера на задержки.

Почему остальные варианты слабее:

• A) 6 + 24 = 30 часов — нет буфера на задержки обработки.
• B) До 24 + 24 = 48 часов — грубое нарушение SLA.
• C) Синхронный API соблюдает SLA, но лишает вас 50% экономии затрат от Batch API.

💡 Вывод для экзамена: При проектировании расписания батчей для SLA используйте формулу: окно_батча + макс_время_выполнения ≤ SLA. Выбирайте наибольшее окно, которое оставляет разумный буфер.

---

Q4: Возобновление упавшей пакетной задачи

Сценарий: Отказоустойчивость и управление состоянием

Вопрос: Пакетная задача на 10 000 документов завершилась сбоем после обработки 6 000 документов из-за системного сбоя. Какой подход наиболее эффективен для возобновления работы без повторной обработки уже завершённых документов?

Варианты:

• A) Перезапустить весь батч с нуля, чтобы обеспечить согласованность.
• B) Вести внешний реестр обработанных идентификаторов документов и отправить новый батч только с необработанными документами.
• C) Использовать синхронный API для оставшихся документов, чтобы избежать повторного сбоя батча.
• D) Разделить оставшиеся 4 000 документов на несколько меньших батчей для снижения риска.

✅ Правильный ответ: B — вести внешний реестр и повторно отправить только необработанные документы

Почему это правильно: Batch API не предоставляет встроенного механизма возобновления. Правильный паттерн — хранить внешний реестр (например, в базе данных или файле состояния) обработанных идентификаторов документов. При сбое вы вычисляете разницу между полным набором и обработанными документами и отправляете новый батч только с оставшимися.

Почему остальные варианты слабее:

• A) Повторная обработка 6 000 документов удваивает затраты без необходимости.
• C) Переключение на синхронный API лишает вас экономии затрат и не решает проблему управления состоянием.
• D) Разбиение на меньшие батчи снижает риск, но не решает проблему идемпотентного возобновления.

💡 Вывод для экзамена: Всегда проектируйте пакетные пайплайны с внешним отслеживанием состояния. Идемпотентность — ключевое свойство надёжных систем пакетной обработки.

---

Q5: Устранение эффекта «потери в середине»

Сценарий: Управление контекстом

Вопрос: Ваш агент обрабатывает длинные документы и демонстрирует снижение точности для информации, расположенной в середине контекстного окна. Какой архитектурный подход лучше всего устраняет эту проблему?

Варианты:

• A) Увеличить размер контекстного окна, чтобы вместить весь документ.
• B) Разбить документ на фрагменты, обработать каждый независимо и агрегировать результаты.
• C) Переместить наиболее важную информацию в начало и конец промпта.
• D) Использовать более высокую температуру для повышения внимания модели к средней части.

✅ Правильный ответ: B — разбить на фрагменты и агрегировать результаты

Почему это правильно: Эффект «потери в середине» — задокументированное явление, при котором модели хуже обрабатывают информацию из середины длинных контекстов. Разбиение документа на фрагменты гарантирует, что каждый фрагмент информации занимает позицию начала или конца в своём собственном контексте, устраняя проблему структурно.

Почему остальные варианты слабее:

• A) Большее контекстное окно усугубляет проблему, а не решает её.
• C) Помогает для известных ключевых фактов, но не масштабируется на произвольные документы.
• D) Температура влияет на случайность вывода, а не на механизмы внимания.

💡 Вывод для экзамена: Для длинных документов предпочитайте архитектуры разбиения на фрагменты с агрегацией результатов вместо попыток вместить всё в один контекст.

---

Q6: Проектирование идентификаторов для цепочек инструментов

Сценарий: Проектирование инструментов и машиночитаемые идентификаторы

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

Варианты:

• A) Использовать имена клиентов как идентификаторы между агентами.
• B) Использовать структурированные уникальные идентификаторы (например, CUST-12345) и передавать их явно между вызовами инструментов.
• C) Позволить каждому агенту самостоятельно искать клиентов по контексту.
• D) Использовать адреса электронной почты как уникальные идентификаторы.

✅ Правильный ответ: B — структурированные уникальные идентификаторы с явной передачей

Почему это правильно: Машиночитаемые структурированные идентификаторы (например, CUST-12345) детерминированы, однозначны и устойчивы к вариациям естественного языка. Явная передача идентификаторов между вызовами инструментов устраняет неоднозначность и делает цепочки инструментов надёжными и отлаживаемыми.

Почему остальные варианты слабее:

• A) Имена не уникальны и подвержены вариациям написания.
• C) Самостоятельный поиск по контексту вводит недетерминированность и риск ошибочного сопоставления.
• D) Адреса электронной почты могут меняться и не всегда доступны во всех системах.

💡 Вывод для экзамена: Проектируйте цепочки инструментов вокруг структурированных, стабильных, машиночитаемых идентификаторов. Явная передача идентификаторов предпочтительнее неявного разрешения по контексту.

---

Ключевые архитектурные принципы

Принцип	Применение
Детерминированность над вероятностностью	Предпочитайте схемы, валидацию и явные идентификаторы инструкциям в промпте
Внешнее отслеживание состояния	Всегда ведите реестры состояния вне модели для возобновляемых пайплайнов
Разбиение на фрагменты для длинных контекстов	Структурно устраняйте эффект «потери в середине»
Доработка промптов до масштабирования	Оптимизируйте на выборке перед запуском полных батчей
Буферы SLA	Проектируйте расписания батчей с явными временными буферами
Явная передача идентификаторов	Передавайте структурированные идентификаторы между агентами, не полагайтесь на разрешение по контексту

---

Вклад в проект

Если вы готовитесь к экзамену и хотите добавить разборы вопросов, исправить объяснения или расширить охват сценариев — pull request'ы приветствуются.