Модуль 14

Подготовка к собеседованию

Как устроен найм на позицию AI engineer, что спрашивают на каждом этапе, 63 концептуальных вопроса с эталонными ответами — от основ LLM до безопасности, своих моделей, context engineering, governance и senior-практик. Три системных дизайн-кейса по новым темам, рассказ о проектах с цифрами, take-home, который выделяется, и план последних двух недель.

≈ 10 часов + практикаGoJava + Python3 визуализации63 вопроса + 3 дизайн-кейсана момент написания: октябрь 2026

Этапы собеседования

Процессы различаются, но у продуктовых компаний и AI-стартапов в 2025–2026 сложилась типичная воронка из пяти этапов. Роль «AI engineer» почти везде означает «сильный бэкенд-инженер, который умеет строить продукты на LLM», поэтому обычная инженерная планка никуда не делась, к ней добавились AI-специфичные раунды.

Этап	Длительность	Что проверяют	Как готовиться
Скрининг (рекрутер или hiring manager)	30–45 мин	Мотивация, релевантный опыт, ожидания, базовая грамотность в терминах: чем RAG отличается от fine-tuning, что такое evals.	История «почему AI engineer» на 60 секунд, два проекта по 2 минуты, вилка.
Кодинг	45–90 мин, часто два раунда	(1) Обычный кодинг: алгоритмы средней сложности или практическая задача (парсер, rate limiter, LRU). (2) LLM-интеграция: написать вызов API, стриминг, tool use, мини-RAG, парсинг structured output, обработку ошибок и ретраи — нередко с разрешённым AI-ассистентом.	Руками написать без подсказок: клиент с ретраями, цикл tool use, косинусную близость и top-k, чанкер. Это модули 2, 5, 6. Работу с AI-ассистентом на раунде тренируйте по модулю 4.
AI system design	45–60 мин	Спроектировать LLM-систему: требования, данные, evals, надёжность, безопасность, стоимость.	Модуль 12: скелет ответа, 6 разборов, расчёты на салфетке. Кейсы по новым темам — ниже.
Deep dive по проектам	45–60 мин	Один-два ваших проекта вглубь: почему такие решения, какие были альтернативы, как измеряли, что сломалось, что сделали бы иначе. Отличает реальный опыт от пересказа туториала.	Сквозные проекты курса и капстоун (модуль 15) + рассказ по шаблону ниже. Знать свои цифры наизусть.
Поведенческое	30–60 мин	Ownership, работа с неопределённостью, конфликты, влияние без полномочий, как принимаете решения при неполных данных (для AI это ежедневная реальность).	6–8 историй в формате STAR, каждая покрывает 2–3 типовых вопроса.

Что изменилось в AI-найме

Всё чаще разрешают (или требуют) использовать Claude Code, Cursor и подобные инструменты на кодинге. Проверяют уже не память синтаксиса, а умение декомпозировать, проверять сгенерированный код и замечать ошибки модели.
Take-home стал популярнее: «сделайте маленький RAG / агент / классификатор с evals за 4–8 часов». Оценивают прежде всего evals и README.
На deep dive спрашивают про метрики: «как вы знаете, что стало лучше?». Ответ «пользователям понравилось» — сигнал джуна.

Что меняется на senior-уровне

На system design безопасность, evals и стоимость ожидают без подсказки. Модель угроз (модуль 7), SLO (модуль 9) и план отката версии модели вы называете сами, а не после вопроса интервьюера.
Половина поведенческого раунда, а иногда и отдельный раунд, посвящены решениям и влиянию: ADR, design review, постмортемы, спор о метрике с продактом, менторство, найм (модуль 13).
Deep dive доходит до цифр: доверительный интервал на eval, ASR на red-team, $ на запрос, p95 TTFT. Капстоун (модуль 15) построен так, чтобы эти цифры у вас были.

Ваше преимущество как Java-разработчикаМногие кандидаты на AI engineer приходят из data science и слабы в продакшн-инженерии: конкурентность (virtual threads, пулы, backpressure), таймауты, circuit breaker и graceful degradation (Resilience4j), observability (Micrometer, OpenTelemetry), нагрузка. Используйте это: в каждом ответе про LLM-систему упоминайте, что происходит на p99, при отказе провайдера и при ×10 нагрузки. Отдельный козырь — enterprise: большая часть корпоративных систем живёт на JVM, и встроить LLM в существующий Spring-ландшафт с транзакциями, Spring Security, аудитом и миграциями схемы умеют немногие. Это ровно то, чего не хватает командам.

Ваше преимущество как Go-разработчикаМногие кандидаты на AI engineer приходят из data science и слабы в продакшн-инженерии: конкурентность, таймауты, graceful degradation, observability, нагрузка. Используйте это: в каждом ответе про LLM-систему упоминайте, что происходит на p99, при отказе провайдера и при ×10 нагрузки. Это ровно то, чего не хватает командам.

Кодинг с LLM-интеграцией: типовые задачи

Задачи этого раунда почти всегда вариации пяти тем. Если вы можете написать каждую за 20–30 минут без документации, раунд пройден.

Вызвать модель, распарсить ответ, обработать 429/5xx с экспоненциальным backoff и jitter, уважать retry-after.
Стриминг: прочитать SSE, собрать текст из content_block_delta, корректно обработать обрыв и отмену через context(закрыть стрим в try-with-resources, уважать прерывание потока).
Цикл tool use: выполнить инструменты (параллельно, если их несколько), вернуть все tool_result одним сообщением, ограничить число шагов.
Мини-RAG в памяти: чанкинг, эмбеддинги (или заглушка), косинусная близость, top-k, промпт с цитатами.
Извлечение структуры: JSON Schema, валидация, повтор при невалидном ответе, eval на 10 примерах.

// Классика раунда: вызов с ретраями. Интервьюер смотрит на дедлайн, jitter, retry-after и типы ошибок.
static final Set<Integer> RETRYABLE = Set.of(408, 409, 429, 500, 502, 503, 504, 529);

static HttpResponse<String> callWithRetry(HttpClient client, HttpRequest req, Instant deadline)
        throws IOException, InterruptedException {
    final int maxAttempts = 4;
    Duration backoff = Duration.ofMillis(500);
    for (int attempt = 1; ; attempt++) {
        HttpResponse<String> resp = null;
        IOException err = null;
        try {
            resp = client.send(req, HttpResponse.BodyHandlers.ofString());
            if (resp.statusCode() < 300) {
                return resp;
            }
        } catch (IOException e) {
            err = e; // сетевые ошибки ретраим
        }
        boolean retryable = err != null;
        Duration wait = backoff.plusMillis(ThreadLocalRandom.current().nextLong(backoff.toMillis())); // full jitter поверх базы
        if (resp != null && RETRYABLE.contains(resp.statusCode())) {
            retryable = true;
            var retryAfter = resp.headers().firstValue("retry-after");
            if (retryAfter.isPresent() && retryAfter.get().matches("\\d+")) {
                wait = Duration.ofSeconds(Long.parseLong(retryAfter.get()));
            }
        }
        if (!retryable || attempt == maxAttempts) {
            if (err != null) {
                throw err;
            }
            throw new IOException("status %d after %d attempts".formatted(resp.statusCode(), attempt));
        }
        if (Instant.now().plus(wait).isAfter(deadline)) {
            throw new HttpTimeoutException("deadline exceeded before attempt " + (attempt + 1));
        }
        Thread.sleep(wait); // прерывание потока = отмена вызывающим, InterruptedException уходит наверх
        backoff = backoff.multipliedBy(2);
    }
}

// Классика раунда: вызов с ретраями. Интервьюер смотрит на context, jitter, retry-after и типы ошибок.
func callWithRetry(ctx context.Context, do func(context.Context) (*http.Response, error)) (*http.Response, error) {
	const maxAttempts = 4
	backoff := 500 * time.Millisecond
	for attempt := 1; ; attempt++ {
		resp, err := do(ctx)
		if err == nil && resp.StatusCode < 300 {
			return resp, nil
		}
		retryable := err != nil // сетевые ошибки ретраим
		wait := backoff + time.Duration(rand.Int63n(int64(backoff))) // full jitter поверх базы
		if resp != nil {
			switch resp.StatusCode {
			case 408, 409, 429, 500, 502, 503, 504, 529:
				retryable = true
				if s, perr := strconv.Atoi(resp.Header.Get("retry-after")); perr == nil {
					wait = time.Duration(s) * time.Second
				}
			}
			resp.Body.Close()
		}
		if !retryable || attempt == maxAttempts {
			if err == nil {
				err = fmt.Errorf("status %d after %d attempts", resp.StatusCode, attempt)
			}
			return nil, err
		}
		select {
		case <-time.After(wait):
			backoff *= 2
		case <-ctx.Done():
			return nil, ctx.Err()
		}
	}
}

В продакшене это делает SDK (по умолчанию 2 ретрая на 408/409/429/5xx), но на интервью просят написать самому и объяснить, почему нельзя ретраить 400 и почему без jitter получится синхронный шторм.

Частые концептуальные вопросы

63 вопроса, которые встречаются чаще всего на скрининге, в начале system design и на deep dive. Ответы здесь — эталон уровня сеньора: суть, компромиссы, цифры. Не заучивайте дословно: научитесь воспроизводить структуру ответа своими словами за 60–90 секунд. Все вопросы доступны ниже в режиме флеш-карточек.

Первые категории — база, которую спрашивают на любом уровне. Безопасность, свои модели, context engineering, evals в глубину, данные и governance, senior-практики отличают сеньора. В этих вопросах к эталону добавлен блок «На что смотрит интервьюер»: по нему видно, какие слова и мысли в ответе отделяют «знает термин» от «делал сам».

LLM-основы

Что такое токен и почему инженеру важно о нём думать?

Токен — единица, на которую токенизатор (обычно BPE) режет текст; модель видит и генерирует токены, а не символы. От числа токенов зависят стоимость (цена за 1M вход/выход), латентность (генерация идёт по токену), лимиты (контекстное окно, max_tokens, ITPM/OTPM). Для английского ≈ 4 символа на токен, для русского и кода токенов больше, поэтому одна и та же фича на русском стоит дороже. Токенизация объясняет и странности: модели плохо считают буквы в слове, потому что не видят букв.

Как работают temperature и top_p, и как управлять поведением на новых моделях Claude?

Модель выдаёт распределение над словарём; temperature делит логиты перед softmax (меньше — распределение острее, ближе к greedy), top_p оставляет минимальный набор токенов с суммарной вероятностью p. На open-source моделях (vLLM, Ollama) и у ряда провайдеров это основные ручки. На новейших моделях Anthropic (Opus 4.7+, Sonnet 5, Fable) temperature и top_p удалены из API (запрос с ними вернёт 400); поведение управляется промптом, effort (output_config.effort) и structured outputs. Важно понимать: даже temperature=0 не даёт полного детерминизма из-за батчинга и численных эффектов на GPU, поэтому тесты строятся на evals, а не на точном совпадении.

Контекстное окно 1M токенов — почему бы не класть туда всё?

Потому что это дорого, медленно и не всегда качественно. 500K токенов входа на Sonnet 5 стоят $1 за запрос, TTFT растёт с длиной промпта, а качество поиска нужного факта в середине длинного контекста ниже, чем в начале и конце (эффект lost in the middle, у новых моделей слабее, но есть). Длинный контекст хорош для разовых задач над одним большим документом, особенно с prompt caching. Для частых запросов к большой базе RAG дешевле на порядки и даёт цитаты.

Что такое эмбеддинг и чем эмбеддинг-модель отличается от генеративной?

Эмбеддинг — вектор фиксированной длины (768–3072 чисел), в котором семантически близкие тексты находятся близко по косинусной мере. Эмбеддинг-модель (обычно энкодер) обучена contrastive-задаче: сближать пары «запрос — релевантный документ». Генеративная модель предсказывает следующий токен. Эмбеддинги дешевле на порядки и используются для поиска, кластеризации, дедупликации, классификации. Важно: векторы разных моделей несравнимы, смена модели означает полную переиндексацию.

Почему LLM галлюцинирует и как это снижать в продукте?

Модель обучена порождать правдоподобное продолжение, а не проверять истинность; когда знания нет или оно размыто, правдоподобный текст всё равно генерируется. Снижение: заземление (RAG с требованием цитат и разрешением сказать «не знаю»), порог по retrieval-скору, чтобы не генерировать без источников, structured output с полями-цитатами и программной проверкой, проверка утверждений отдельным вызовом, более сильная модель на критичных шагах, человек в контуре при высокой цене ошибки. И измерение: faithfulness-метрика на golden set, а не ощущения.

Чем KV-cache отличается от prompt caching?

KV-cache — механизм внутри одного запроса: при генерации каждого нового токена ключи и значения attention для предыдущих токенов не пересчитываются. Он делает генерацию линейной по длине вместо квадратичной и занимает много памяти GPU. Prompt caching — сохранение KV-cache префикса между запросами на стороне провайдера: если следующий запрос начинается с тех же байт (tools → system → messages), префикс не пересчитывается. У Anthropic чтение кэша ≈ 0.1× цены входа, запись 1.25× (TTL 5 мин) или 2× (1 ч), до 4 breakpoint'ов. Любое изменение в префиксе (timestamp в system prompt) инвалидирует всё после него; проверка — usage.cache_read_input_tokens.

RAG

Опишите RAG-пайплайн end to end.

Офлайн: загрузка источников → парсинг (PDF, HTML, таблицы) → чанкинг с учётом структуры → эмбеддинги → запись в индекс вместе с метаданными (источник, дата, ACL). Онлайн: (опционально) переписывание запроса → эмбеддинг → гибридный поиск (вектор + BM25) с фильтром по правам → слияние (RRF) → rerank → сборка контекста с идентификаторами → генерация с требованием цитат → проверка цитат. Вокруг: evals на каждом шаге (retrieval отдельно от генерации), инкрементальный ingest, трейсинг. На интервью важно сказать, что большинство проблем RAG — это проблемы retrieval, а не генерации.

Как выбрать размер чанка?

Компромисс: маленькие чанки (200–300 токенов) точнее матчатся с запросом, но теряют контекст; большие (800–1500) несут контекст, но размывают эмбеддинг и тратят окно. Стартовая точка 400–600 токенов с перекрытием 10–15%, разбиение по структуре документа (заголовки, абзацы, функции в коде), а не по символам. Приёмы: small-to-big (ищем по мелким, отдаём родительский раздел), добавление заголовка документа и раздела в чанк (contextual chunking). Окончательно — по eval: recall@k на golden set для 2–3 вариантов.

Зачем гибридный поиск и что такое RRF?

Векторный поиск хорош в синонимах и перефразах, но плохо находит точные строки: коды ошибок, артикулы, имена функций, редкие термины. BM25 наоборот. Гибрид запускает оба и сливает результаты. RRF (Reciprocal Rank Fusion) складывает 1/(k + rank) по каждому списку (k ≈ 60): не требует калибровки скоров разной природы и устойчив. На практике гибрид даёт заметный прирост recall почти всегда, когда в корпусе есть идентификаторы.

Bi-encoder и cross-encoder: в чём разница и зачем rerank?

Bi-encoder кодирует запрос и документ независимо, документы можно закодировать заранее — это и есть эмбеддинги для ANN; быстро, но документ сжат в один вектор без знания запроса. Cross-encoder получает пару (запрос, документ) целиком и выдаёт скор релевантности — точнее, но надо прогонять каждую пару в момент запроса. Поэтому двухстадийно: ANN достаёт top-50..100, cross-encoder переранжирует до top-5..10. Цена — 50–200 мс и GPU или вызов rerank-API; выигрыш — обычно несколько пунктов nDCG и меньше мусора в контексте.

RAG дал плохой ответ. Как вы будете отлаживать?

По трейсу, послойно. (1) Был ли нужный документ в индексе вообще (ingest, парсинг, права)? (2) Попал ли он в top-k retrieval? Если нет — проблема запроса (переписывание), чанкинга, эмбеддингов или фильтров. (3) Попал, но rerank его опустил? (4) Был в контексте, но модель его не использовала или исказила — промпт, порядок, длина контекста, модель. Каждую найденную причину превращаю в кейс golden set, чтобы регрессия ловилась в CI. Отдельные метрики retrieval (recall@k) и генерации (faithfulness) позволяют не гадать.

RAG, fine-tuning или длинный контекст: как выбрать?

RAG — для знаний, которые меняются, большие по объёму, требуют прав доступа и цитат. Длинный контекст — для разовой работы с конкретными документами целиком, особенно с prompt caching, и для небольших стабильных баз. Fine-tuning — не для знаний, а для поведения: формат, стиль, узкая задача (классификация, извлечение), где нужно снизить цену и латентность, перейдя на маленькую модель. Они комбинируются: fine-tuned маленькая модель как reranker или классификатор внутри RAG.

Агенты и MCP

Чем workflow отличается от агента, и что вы выберете по умолчанию?

По определению Anthropic, workflow — LLM и инструменты оркестрируются по заранее заданным путям в коде (цепочки, роутинг, параллелизация, orchestrator-workers, evaluator-optimizer). Агент — модель сама решает, какие шаги делать и когда остановиться, в цикле с инструментами. По умолчанию workflow: он дешевле, быстрее, предсказуемее и тестируется как обычный код. Агент оправдан, когда путь решения нельзя предсказать заранее (исследование кодовой базы, отладка, открытые задачи), и стоит лимитов на шаги, бюджет и чёткой среды с обратной связью.

Как работает tool use на уровне API?

В запросе передаются описания инструментов (имя, описание, JSON Schema входа). Модель отвечает блоком tool_use с id и аргументами, stop_reason: "tool_use". Код исполняет инструмент и отправляет следующее user-сообщение с блоком tool_result (tool_use_id, содержимое, is_error: true при ошибке). Если модель запросила несколько инструментов в одном ответе, их выполняют конкурентно и возвращают все результаты одним сообщением. Цикл продолжается до end_turn или лимита шагов. Модель ничего не исполняет сама — все побочные эффекты и права в вашем коде.

Что такое MCP и какую проблему он решает?

Model Context Protocol — открытый протокол (JSON-RPC 2.0) для подключения инструментов и данных к LLM-приложениям. Сервер предоставляет tools, resources и prompts; клиент (Claude Code, Claude Desktop, IDE, ваш агент) их обнаруживает и вызывает. Транспорты: stdio для локальных серверов и Streamable HTTP для удалённых. Решает проблему M×N интеграций: вместо того чтобы каждое приложение писало свой коннектор к каждой системе, система публикует один MCP-сервер. Для Go есть официальный SDK github.com/modelcontextprotocol/go-sdk.Для Java есть официальный SDK io.modelcontextprotocol.sdk:mcp, на нём построены MCP-стартеры Spring AI. Риски: сторонний сервер — это чужой код и чужие описания инструментов в вашем контексте (tool poisoning), поэтому allowlist и ревью.

Как ограничить агента, чтобы он не натворил дел?

Бюджеты: максимум шагов, токенов, времени и денег на задачу. Права: least privilege у каждого инструмента, отдельные креды на агента, read-only по умолчанию, песочница для исполнения кода (контейнер без сети или с egress allowlist). Подтверждение человеком для необратимых действий (отправка, удаление, платежи). Валидация аргументов инструментов в коде. Аудит всех вызовов. Детектор зацикливания. И evals на траекториях, а не только на финальном ответе.

Что такое «lethal trifecta» и как с ней жить?

Термин Саймона Уиллисона: агент опасен, когда одновременно (1) имеет доступ к приватным данным, (2) обрабатывает недоверенный контент (веб, письма, документы, issue), (3) может передавать данные наружу (HTTP-запросы, отправка писем, даже markdown-картинки с URL). Prompt injection в недоверенном контенте тогда может увести данные. Надёжного детектора инъекций нет, поэтому защита архитектурная: разорвать одну из трёх ног для конкретного сценария — например, убрать внешние запросы или разделить агента на читающего недоверенное без доступа к секретам и действующего без доступа к недоверенному.

Context engineering и long-horizon агенты

Что такое context engineering и чем он отличается от prompt engineering?

Prompt engineering отвечает на вопрос, как сформулировать инструкцию. Context engineering управляет всем, что попадает в окно модели на каждом шаге: системным промптом, описаниями инструментов, историей, результатами инструментов, найденными документами, памятью. Anthropic формулирует цель так: найти минимальный набор высокосигнальных токенов, который максимизирует вероятность нужного результата. Отдельной дисциплиной это стало из-за агентов: у них контекст растёт с каждым шагом, а качество падает с длиной входа задолго до лимита окна (context rot: отчёт Chroma 2025 года, 18 моделей). Удобная таксономия — write / select / compress / isolate: вынести наружу (заметки, память), подтянуть нужное в момент использования, сжать (резюме, обрезка результатов инструментов), изолировать (субагенты, песочницы). В дизайне это бюджет токенов на шаг, а в трейсе — метрика размера контекста по шагам (модуль 6).

На что смотрит интервьюер: не сводит ли кандидат тему к «длинному промпту»; называет ли конкретные техники и их цену (потеря деталей, инвалидация кэша); думает ли о контексте как о ресурсе с бюджетом и метрикой.

Агент к 40-му шагу начинает повторяться и забывать принятые решения. Что делаете?

Сначала трейс: размер контекста по шагам и что в нём занимает место. Обычно это сырые результаты инструментов: листинги, логи, диффы. Дальше иду от дешёвого к дорогому. (1) Инструменты возвращают меньше: пагинация, выжимки, ссылки вместо содержимого. (2) Just-in-time: агент хранит пути и id, а не содержимое, и дочитывает по необходимости. (3) Context editing: старые tool_result вычищаются редко и пачками, чтобы не ломать кэш префикса на каждом шаге. (4) Компакция с явной схемой резюме: цель, принятые решения и их причины, открытые вопросы, пути к файлам, что уже проверено. (5) Файл с планом и прогрессом, который переживает компакцию. (6) Субагенты для «грязной» работы. Параллельно — детектор зацикливания (одинаковый вызов с теми же аргументами или одна и та же ошибка 3 раза) и лимит шагов. Эффект проверяю eval по траекториям: доля решённых задач, шаги и $ на задачу до и после.

На что смотрит интервьюер: начинает ли кандидат с диагностики, а не с «возьму модель с окном побольше»; знает ли, что компакция теряет детали и что именно сохранять; связывает ли решение с кэшем и с измерением.

Как устроить агента, который работает над задачей часами или днями?

Окно контекста конечно, поэтому состояние живёт вне его: в файлах, в git и в БД. Хороший ориентир — схема из инженерного блога Anthropic (ноябрь 2025) для многосессионной разработки. Инициализирующий агент в первой сессии раскладывает задачу в список проверяемых фич (JSON с полем passes: модель реже «правит» JSON не по делу, чем Markdown), пишет скрипт запуска окружения и файл прогресса. Каждая следующая сессия читает git log и прогресс, запускает базовую проверку, берёт одну фичу, тестирует её end-to-end, коммитит и обновляет прогресс. Git здесь одновременно память и механизм отката. Сверху инженерная обвязка: идемпотентные шаги и чекпойнты (рестарт с места падения), бюджет в $ и шагах на всю задачу с алертами на 50 и 80%, подтверждение человеком для необратимых действий, трейс на сессию со сквозным task id. Типичные отказы, которые описывает Anthropic: агент пытается сделать всё сразу и упирается в окно, объявляет работу законченной слишком рано, отмечает фичу готовой без проверки.

На что смотрит интервьюер: понимает ли кандидат, что память — это файлы, git и БД, а не большое окно; есть ли чекпойнты, бюджет и критерий «готово», который проверяет код; знает ли реальные режимы отказа длинных агентов.

Субагенты: когда они помогают, а когда вредят?

Помогают, когда подзадачи независимы и «шумные»: поиск по большой кодовой базе, параллельное исследование нескольких источников. Субагент тратит десятки тысяч токенов в своём окне и возвращает выжимку в пару тысяч. Основной контекст остаётся чистым, работа идёт параллельно. Вредят, когда подзадачи связаны (правки в общем коде, решения одного влияют на другого): на границе теряются детали, и агенты принимают несовместимые решения. Цена тоже заметная: по данным Anthropic (июнь 2025), агенты расходуют порядка ×4 токенов относительно чата, а мультиагентные системы — порядка ×15. Поэтому у субагента должен быть контракт возврата (структура, источники, лимит длины), а решение «один агент с хорошей компакцией или оркестратор с субагентами» принимается по eval: качество, $ и латентность на одном наборе задач.

На что смотрит интервьюер: называет ли кандидат цену в токенах и проблему связанных подзадач; есть ли контракт выдачи субагента; решает ли по измерению, а не по моде на мультиагентность.

Evals

Как построить golden set с нуля?

Начать с реальных данных: логи запросов, тикеты, вопросы пользователей; если продукта ещё нет — вопросы от экспертов домена и синтетика, сгенерированная по документам и отфильтрованная людьми. Стратифицировать по типам запросов и сложности, обязательно включить edge cases: нет ответа в базе, неоднозначные, adversarial. Для каждого — ожидаемый результат в проверяемой форме (правильные документы, ключевые факты, эталонный SQL). 50–100 примеров для старта, 300–500 для уверенных сравнений. Версионировать как код, пополнять из прод-ошибок. Главное — посмотреть глазами на 100+ реальных ответов до того, как придумывать метрики (error analysis).

LLM-as-a-judge: какие проблемы и как их решать?

Проблемы: позиционный bias (в попарном сравнении предпочитает первый вариант), bias к длинным ответам, self-preference (любит ответы своей модели), нестабильность шкал 1–10. Решения: бинарные или узкие критерии («каждое утверждение подкреплено контекстом: да/нет») вместо общей оценки; попарное сравнение с перестановкой порядка; рассуждение перед вердиктом; судья сильнее или другого семейства, чем генератор. И калибровка: 100–200 примеров размечают люди, считаем согласие судьи с людьми (accuracy, Cohen's kappa), итерируем промпт судьи, пока согласие не станет сопоставимым с согласием между людьми.

Offline и online evals: зачем оба?

Offline — на фиксированном наборе до релиза: быстро, воспроизводимо, гейт в CI, но набор отстаёт от реальности. Online — на реальном трафике: явный фидбек, неявные сигналы (переформулировки, эскалации, копирование ответа), judge на выборке, A/B. Ловит дрейф входов и то, чего нет в наборе. Цикл: online находит новые классы ошибок → они попадают в offline-набор → регрессия больше не пройдёт незамеченной.

Какие метрики retrieval вы знаете и когда какую использовать?

Recall@k — доля релевантных документов, попавших в top-k; главная для RAG, потому что генератор не увидит то, что не нашли. Precision@k — доля релевантных среди top-k; важна, когда контекст дорог или шум путает модель. MRR — средний 1/ранг первого релевантного; для сценариев «нужен один правильный ответ». nDCG@k — учитывает градации релевантности и позицию; стандарт для поиска с ранжированием. Плюс ANN-recall — насколько приближённый поиск совпадает с точным, это метрика инфраструктуры.

Как встроить evals в CI и не получить flaky-тесты?

Не требовать 100% прохождения отдельных кейсов: гейт по агрегированной метрике с порогом и допуском (например, faithfulness не ниже baseline − 2 п.п.). Детерминированные проверки (схема, наличие цитат, запрещённые строки) — жёсткие, как unit-тесты. Кэшировать ответы модели по хэшу (промпт, модель, вход), чтобы повторные прогоны без изменений были бесплатными и стабильными. Быстрый smoke-набор (30–50 кейсов) на каждый PR, полный — ночью или перед релизом. Отчёт с диффом по кейсам, а не только числом.

Как посчитать доверительный интервал для метрики eval и корректно сравнить две версии?

Для доли (pass rate) подходит интервал Уилсона. Для любой метрики (средний скор судьи, nDCG) — bootstrap: тысячи раз выбираем примеры с возвращением, считаем метрику, берём 2.5-й и 97.5-й перцентили. Две версии на одном наборе сравниваю парно: bootstrap по разнице на одних и тех же примерах или McNemar для бинарных исходов. Парность убирает разброс сложности примеров, и интервал разницы заметно сужается. Если примеры сгруппированы (несколько вопросов к одному документу, несколько прогонов одного кейса), ресемплировать нужно кластеры, иначе интервал будет обманчиво узким. Гейт в CI формулирую как «нижняя граница интервала разницы не ниже −допуска», а не «метрика больше baseline». Порядок величин: на 200 примерах при 85% полуширина 95%-интервала около ±5 п.п., так что разница в 2 п.п. неотличима от шума (модуль 8).

На что смотрит интервьюер: знает ли кандидат парное сравнение и кластерный bootstrap; формулирует ли гейт через интервал; может ли прикинуть, сколько примеров нужно для нужной чувствительности.

Что такое Cohen's κ и зачем он при калибровке LLM-судьи?

Это согласие с поправкой на случайность: κ = (p_o − p_e) / (1 − p_e), где p_o — наблюдаемая доля совпадений, а p_e — ожидаемая при независимых разметчиках с теми же частотами меток. При перекосе классов голое согласие обманывает. Если 90% ответов хорошие, судья, который всегда говорит «хорошо», согласен с человеком в 90% случаев, но κ у него равен 0. Процедура калибровки: 100–200 примеров размечают два человека, их κ задаёт потолок; затем считаем κ судьи против консенсуса людей и итерируем промпт судьи, пока его κ не приблизится к межчеловеческому. Дополнительно смотрю матрицу ошибок: пропуск плохого ответа (false pass) обычно дороже ложной тревоги. Словесные шкалы вроде «0.6–0.8 — существенное согласие» условны, поэтому сравнивать надо с людьми.

На что смотрит интервьюер: может ли кандидат объяснить κ на примере с перекосом классов; сравнивает ли судью с межчеловеческим согласием; смотрит ли на тип ошибок, а не только на одно число.

Как спроектировать A/B-тест новой модели или промпта в проде?

Начинаю с гипотезы и одной основной метрики (решено без эскалации, конверсия). Заранее фиксирую guardrail-метрики, которые не должны ухудшиться: стоимость запроса, p95 латентности, жалобы, долю отказов, инциденты безопасности. Рандомизирую по пользователю или диалогу, а не по запросу: иначе один человек видит обе версии, и эффекты смешиваются. Мощность считаю до старта: минимальный важный для бизнеса эффект (MDE) даёт размер выборки и длительность, обычно не меньше недели, чтобы покрыть недельную сезонность. Перед чтением результатов проверяю SRM (sample ratio mismatch). Если при разбивке 50/50 на миллионе пользователей вышло 50.8/49.2, это баг в назначении или логировании, и результат интерпретировать нельзя. Не останавливаю тест, «как только стало значимо», или использую последовательные методы. Специфика LLM: эффект новизны, длина ответа сама меняет поведение пользователей, а рост качества может стоить денег, поэтому итоговое решение принимается по юнит-экономике. В A/B попадает только то, что уже прошло offline-гейт.

На что смотрит интервьюер: рандомизация по пользователю, guardrail-метрики, проверка SRM, мощность до старта; связь A/B с offline evals; понимание, что «значимо» и «выгодно» — разные вещи.

Как оценивать агента по траектории, а не только по финальному ответу?

Финальный ответ бывает верным при плохом пути (лишние 30 шагов, опасный вызов, который случайно ничего не сломал) и неверным при почти правильном пути. Поэтому оцениваю на четырёх уровнях. (1) Итоговое состояние среды, проверяемое кодом: в τ-bench сравнивают состояние БД в конце диалога с эталонным. (2) Траектория: нужные инструменты вызваны (recall), лишних нет (precision), аргументы корректны, порядок соблюдён там, где он важен, запрещённые действия не вызывались ни разу. (3) Эффективность: шаги, токены и $ на задачу против эталона. (4) Надёжность: pass^k — доля задач, решённых во всех k повторах. В τ-bench у сильной модели pass^8 в домене retail был ниже 25%, хотя одиночный прогон выглядел заметно лучше. Данные берутся из трейсов со спанами инструментов. Судья нужен там, где правил нет, например оценить, разумен ли шаг. Точного совпадения траектории с эталоном не требую: правильных путей обычно несколько (модуль 8).

На что смотрит интервьюер: различает ли кандидат pass@k и pass^k; есть ли нулевая терпимость к опасным действиям; использует ли трейсы как источник данных; не требует ли точного совпадения пути.

Продакшн

Как вы обрабатываете 429, 5xx и 529 от провайдера?

429 (rate limit) — ретрай с экспоненциальным backoff и jitter, с учётом retry-after; на уровне системы — собственный rate limiter перед провайдером, чтобы не упираться в лимит, и приоритизация трафика. 5xx и 529 (overloaded) — ретрай с backoff, circuit breaker на модель/провайдера, fallback на другую модель или регион. 400 не ретраить: это ошибка запроса. Общий бюджет ретраев, чтобы не устроить шторм, и согласование ретраев на разных уровнях (SDK, gateway, клиент), иначе они перемножаются. Для стрима — ретрай возможен только до первого отданного пользователю токена.

Зачем стриминг и какие у него сложности?

Стриминг сокращает воспринимаемую латентность: пользователь видит первые слова через TTFT (сотни мс) вместо полного ответа через 5–15 с; для длинных выводов он ещё и нужен, чтобы не упереться в HTTP-таймауты. Сложности: прокси и балансировщики буферизуют ответ (нужно отключать буферизацию), таймауты на idle-соединения (события ping), обрыв посередине (что показать, как учесть токены), модерация и валидация вывода, который уже ушёл пользователю, парсинг частичного JSON для tool use (input_json_delta), отмена генерации при уходе клиента через context.

Как гарантировать, что модель вернёт валидный JSON?

Использовать structured outputs: у Anthropic — output_config.format с JSON Schema или strict: true у tools; декодирование ограничено схемой, и невалидный по синтаксису JSON не возвращается. Инструкция «ответь JSON» без этого даёт битый вывод в доле процента, что на миллионах запросов превращается в тысячи ошибок. Prefill ответа на новых моделях Claude не поддерживается (400). Но валидность по схеме не равна правильности значений: семантическая проверка (диапазоны, существование id, согласованность полей) остаётся в коде.

Что должно быть в observability LLM-системы?

Трейс на запрос (OpenTelemetry с атрибутами gen_ai.*): спаны retrieval, rerank, каждого вызова модели и инструмента; модель, версия промпта, токены (вход, выход, cache read/write), стоимость, stop_reason, латентность и TTFT, id найденных документов. Метрики: p50/p95/p99, ошибки по типам, $ по фичам, доля cache hit. Качество: фидбек, онлайн-judge, эскалации. Хранилище промптов и ответов с контролем доступа из-за PII. Инструменты: Langfuse, Arize Phoenix, LangSmith или своё на OTel + ClickHouse + Grafana.

Какие виды кэширования есть в LLM-системах?

(1) Prompt caching провайдера — повторное использование префикса, 0.1× цены входа, почти всегда включать для стабильных системных промптов и инструментов. (2) Точный кэш ответов — хэш от модели, параметров и сообщений; безопасен, но хит-рейт низкий, кроме FAQ-подобных сценариев. (3) Семантический кэш — ответ на «похожий» запрос по близости эмбеддингов; высокий хит-рейт, но риск неверного ответа на похожий по форме, но другой по смыслу вопрос и утечки между пользователями — только с высоким порогом и там, где ответ не персональный. (4) Кэш эмбеддингов и результатов retrieval.

Стоимость

Как быстро оценить стоимость LLM-фичи?

Запросов в месяц × (токены входа × цена входа + токены выхода × цена выхода) / 1M, с поправками: доля кэшированного префикса по 0.1×, число вызовов модели на запрос (агенты), доля хитов кэша ответов, −50% для batch. Пример: 1M запросов, 4K вход, 400 выход на Sonnet 5 ($2/$10): $8K + $4K = $12K/мес. Дальше сравнить с ценностью: выручка на пользователя, сэкономленное время сотрудников, стоимость живого оператора.

Как снизить стоимость в 5 раз без потери качества?

По порядку эффекта: (1) роутинг — простые запросы на маленькую модель (Haiku 4.5 в 2–5 раз дешевле Sonnet/Opus), решает классификатор или каскад с эскалацией по уверенности; (2) prompt caching стабильного префикса — вход дешевеет до 10 раз на кэшированной части; (3) сокращение контекста — rerank и меньше чанков, обрезка истории; (4) короче вывод — structured output, лимиты; (5) batch для всего, что не интерактивно (−50%); (6) кэш ответов для повторяющихся запросов. Каждый шаг проверяется eval-набором: «без потери качества» — это измеряемое утверждение, а не надежда.

Когда self-hosted модель выгоднее API?

Когда загрузка GPU высокая и стабильная (амортизация железа), задача узкая и маленькая модель (7–30B, после fine-tuning) достигает нужного качества, или есть требования к данным и латентности. TCO включает GPU (часы или покупку), инференс-сервер (vLLM, TGI), инженеров, мониторинг, обновления моделей, резервирование. Типичная ошибка — сравнивать цену GPU-часа с ценой токенов при 100% загрузке, хотя реальная загрузка 20–40%. Для большинства продуктов API выгоднее до очень большого объёма.

Когда использовать Batch API?

Для любых задач, где результат не нужен сразу: ночная обработка документов, суммаризация звонков, генерация описаний, прогон evals, разметка данных, бэкфилл эмбеддингов. Скидка 50%, асинхронно, результат до 24 часов (обычно быстрее), не конкурирует с синхронными лимитами. Нюансы: результаты приходят в произвольном порядке — матчить по custom_id; часть запросов может завершиться с ошибкой или истечь — нужен повтор; prompt caching тоже работает внутри батча.

Почему агенты так дорого стоят и что с этим делать?

Каждый шаг агента заново отправляет всю историю: системный промпт, описания инструментов, все прошлые вызовы и результаты. Суммарный вход растёт примерно квадратично по числу шагов, а результаты инструментов бывают огромными (листинг файлов, ответ API). Меры: prompt caching (префикс и история кэшируются), обрезка и суммаризация результатов инструментов, компактизация истории, лимиты шагов, субагенты с чистым контекстом для подзадач, дешёвая модель для рутинных шагов и сильная для планирования.

Безопасность

Пройдитесь по OWASP Top 10 for LLM 2026: что критично для RAG-агента с инструментами?

Редакция 2026 (вышла 4 августа 2026): LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. По сравнению с 2025 годом Excessive Agency поднялась с 6-го на 3-е место, Improper Output Handling опустилась с 5-го на 10-е, а System Prompt Leakage расширена до Hidden Context Exposure. Для RAG-агента с инструментами на первом месте LLM01: непрямые инъекции через документы и результаты инструментов. Дальше LLM09 (утечка между тенантами через индекс, отравление индекса), LLM03 (инструменты шире, чем нужно), LLM10 (вывод модели уходит в SQL, HTML, shell или markdown без обработки), LLM02 (PII и чужие данные в ответах и логах), LLM08 (утекает скрытый контекст: system prompt, инструкции разработчика, схемы инструментов, правила, подмешанные из RAG) и LLM06 (агент в цикле сжигает бюджет). Сеньорский ответ — не перечисление, а модель угроз. Какие активы (данные, деньги, действия), где проходят границы доверия (где недоверенный текст попадает в контекст), кто атакующие (внешний пользователь, автор документа, сторонний MCP-сервер). Для каждого риска нужен контроль в коде и тест в red-team наборе (модуль 7).

На что смотрит интервьюер: знает ли кандидат актуальную редакцию списка (2026) и что в ней поменялось; привязывает ли риски к конкретной архитектуре; начинает ли с модели угроз и заканчивает ли тестами.

Почему prompt injection нельзя закрыть промптом или классификатором и что делать вместо этого?

Модель получает инструкции и данные в одном потоке токенов, и аналога параметризованного SQL-запроса у неё нет. Классификаторы и спотлайтинг снижают долю успешных атак, но только вероятностно. Атакующий адаптивен и делает много попыток, а защитнику нужно 100%. Поэтому защита строится архитектурой. (1) Права: агент действует с правами пользователя и не может сделать больше него. (2) Для каждого сценария разрывается lethal trifecta. (3) Паттерны из работы Beurer-Kellner и соавторов (2025): action-selector — модель только выбирает из фиксированных действий; plan-then-execute — план фиксируется до чтения недоверенных данных; dual LLM — привилегированная модель не видит недоверенный текст и оперирует переменными, а карантинная работает без инструментов; code-then-execute — CaMeL от Google DeepMind строит поток управления из доверенного запроса и проверяет политики на потоках данных. (4) Подтверждение человеком для необратимых действий. (5) Контроль исходящих соединений. Детекторы остаются слоем глубокой обороны и источником сигналов для мониторинга.

На что смотрит интервьюер: говорит ли кандидат «модель — не граница безопасности»; знает ли хотя бы два архитектурных паттерна; признаёт ли их цену: паттерны ограничивают полезность агента.

Что такое excessive agency и как вы проектируете против неё?

OWASP LLM03 (в редакции 2026; в 2025 — LLM06): агент может сделать больше, чем нужно для задачи. У риска три корня. Лишняя функциональность: инструмент send_email, когда нужен только черновик, или shell вместо узкого run_tests. Лишние права: сервисный аккаунт с доступом ко всем клиентам. Лишняя автономия: необратимое действие без подтверждения. Контроли: узкие инструменты под задачу вместо универсальных; read-only по умолчанию; действия в контексте пользователя (его OAuth-токен с минимальным scope, а не общий сервисный ключ); авторизация в downstream-системе, а не «модель решит». Опасные действия делаются в две фазы: агент готовит предложение, человек подтверждает его в доверенном интерфейсе, код исполняет с ключом идемпотентности. Плюс лимиты на суммы и частоту. Логи и rate limit не предотвращают риск, но ограничивают ущерб. Весь подход целиком разобран в Разборе 6 модуля 12 на примере банковского ассистента.

На что смотрит интервьюер: называет ли кандидат три корня; выносит ли авторизацию за пределы модели; отличает ли подтверждение текстом в чате от подтверждения в доверенном интерфейсе.

Как вы организуете red-teaming LLM-системы?

Как eval-набор, а не разовую акцию. (1) Из модели угроз выводятся категории атак: прямые и непрямые инъекции (через документы, письма, комментарии, результаты инструментов), извлечение системного промпта и PII, обход прав (чужой тенант), excessive agency (заставить вызвать опасный инструмент), DoS по стоимости (бесконечные циклы), вредный контент. (2) Набор собирается из ручных атак команды, сгенерированных вариаций (promptfoo, garak, PyRIT) и реальных инцидентов; у каждой атаки размечено ожидаемое поведение. (3) Метрика — ASR (attack success rate, доля успешных атак) по категориям, с интервалом. Для критичных категорий (утечка данных, несанкционированное действие) гейт — ноль. Помните правило трёх: ноль успехов из n даёт верхнюю границу 95%-интервала около 3/n. (4) Прогон в CI на каждое изменение промпта, модели или инструментов, полный набор — перед релизом. (5) Каждая найденная атака становится регрессионным кейсом. Статичный набор устаревает, поэтому раз в квартал нужна ручная адаптивная сессия или внешняя команда (модуль 7).

На что смотрит интервьюер: ASR как метрика с порогами по категориям; связь с CI и регрессией; понимание ограничений статичного набора; знание инструментов без сведения задачи к ним.

Какие угрозы несёт подключение стороннего MCP-сервера?

Это чужой код и чужой текст в вашем контексте. Tool poisoning: в описании инструмента спрятаны инструкции для модели, а описание читает модель, не человек. Rug pull: сервер меняет описания после того, как его одобрили. Shadowing: описание одного сервера влияет на то, как модель использует инструменты другого. Supply chain (LLM04): скомпрометирован пакет сервера. И слишком широкие права токена. Контроли: allowlist серверов и пиннинг версий; ревью описаний инструментов, их хэш и алерт на изменение; минимальные OAuth-scope; никакого token passthrough (спецификация MCP запрещает серверу принимать токены, выпущенные не для него); изоляция в контейнере с allowlist исходящих соединений; подтверждение действий и журнал вызовов (модуль 6, модуль 7).

На что смотрит интервьюер: понимает ли кандидат, что описания инструментов — канал инъекции; знает ли rug pull; говорит ли про пиннинг версий, минимальные scope и изоляцию.

Свои модели: serving и адаптация

Какие метрики serving вы мониторите и что такое goodput?

TTFT (время до первого токена) определяют очередь и prefill, а prefill упирается в вычисления. TPOT, или ITL (время на выходной токен), определяет decode: он упирается в пропускную способность памяти и растёт с размером батча. Полная латентность ≈ TTFT + TPOT × число выходных токенов. Throughput — суммарные токены в секунду. Goodput — пропускная способность с учётом SLO: сколько запросов в секунду система обслуживает так, что TTFT и TPOT укладываются в пороги (в этом смысле термин использует работа DistServe, OSDI 2024). Goodput нужен потому, что с ростом батча throughput растёт, но вместе с ним растёт TPOT. С какого-то момента запросы нарушают SLO: throughput красивый, а пользователи недовольны. Ёмкость реплики — максимальная конкурентность при соблюдении SLO по p95 или p99. Её получают нагрузочным тестом на реальном профиле длин входа и выхода. Дополнительно мониторю заполнение KV-cache, длину очереди, вытеснение последовательностей (preemption) и hit rate prefix cache (модуль 10).

На что смотрит интервьюер: разделяет ли кандидат prefill и decode, TTFT и TPOT; объясняет ли конфликт throughput и латентности; меряет ли на своём профиле нагрузки.

Сколько одновременных запросов выдержит один GPU? Посчитайте.

Обычно конкурентность ограничивает память под KV-cache, а не вычисления. Размер KV на токен = 2 × число слоёв × число KV-голов × head_dim × байт на элемент. Для модели класса Llama-3-8B (32 слоя, 8 KV-голов, head_dim 128, bf16) это 128 КБ на токен. На GPU 80 ГБ при gpu-memory-utilization 0.9 доступно 72 ГБ. Минус 16 ГБ весов и запас на активации — под KV остаётся около 50 ГБ, это примерно 400K токенов. Если средняя последовательность (вход + выход) занимает 4K токенов, параллельно поместится около 100 запросов, а при 32K — около 12. Рычаги: квантизация KV-cache в FP8 (вдвое больше места), ограничение max-model-len, prefix caching (общий системный промпт хранится один раз), PagedAttention против фрагментации. Дальше нужен нагрузочный тест: при большой конкурентности растёт TPOT, и SLO может закончиться раньше памяти.

На что смотрит интервьюер: считает ли кандидат вслух по формуле; понимает ли, что конкурентность ограничивает KV, а не веса; называет ли рычаги и необходимость проверки нагрузкой.

Квантизация: что она даёт в инференсе и как понять, что качество не пострадало?

Веса хранятся в 8 или 4 битах вместо 16. Это даёт меньше памяти (8B-модель: 16 ГБ в bf16 → около 8 ГБ в 8 битах → около 4–5 ГБ в 4 битах), более быстрый decode (он упирается в чтение весов из памяти) и больше места под KV-cache. Варианты: FP8 с аппаратной поддержкой на новых GPU, INT8, 4-битные GPTQ и AWQ для GPU, GGUF для llama.cpp и Ollama; отдельно квантуется KV-cache. Цена — деградация качества, и она неравномерна. Средние бенчмарки почти не меняются, а длинные рассуждения, код, редкие для модели языки и строгое следование формату могут просесть сильнее. Поэтому проверяю на своём eval-наборе, а не по perplexity из README: прогон до и после, с доверительным интервалом и отдельными срезами (длинные входы, русский язык, structured output). Выигрыш в скорости тоже меряю нагрузочным тестом на своём профиле (модуль 10).

На что смотрит интервьюер: понимает ли кандидат, почему ускоряется decode; различает ли форматы; требует ли eval на своей задаче со срезами, а не верит средним бенчмаркам.

LoRA, QLoRA или full fine-tuning: когда что?

Full fine-tuning обновляет все веса. Выразительность максимальная, но градиенты и состояния оптимизатора занимают в разы больше памяти, чем сами веса, и на каждую задачу получается полная копия модели. LoRA замораживает веса и обучает низкоранговые добавки к матрицам. В оригинальной статье для GPT-3 175B обучаемых параметров стало в 10 000 раз меньше, памяти GPU — в 3 раза меньше, а после слияния добавок с весами латентность не растёт. Адаптер весит мегабайты, поэтому поверх одной базовой модели можно обслуживать десятки адаптеров (multi-LoRA serving, например в vLLM). QLoRA держит базовую модель в 4 битах (NF4) и обучает LoRA поверх: авторы дообучали 65B-модель на одном GPU 48 ГБ. Выбор: LoRA по умолчанию для формата, стиля и узких задач; full fine-tuning — когда поведение нужно сдвинуть глубоко и есть бюджет; ни то ни другое — для добавления знаний, это задача RAG. Всегда сравниваю с промпт-бейзлайном на eval и проверяю забывание на общих задачах.

На что смотрит интервьюер: понимает ли кандидат механику (низкий ранг, заморозка весов) и порядок цифр по памяти; знает ли про multi-LoRA в serving; не предлагает ли fine-tuning для знаний.

SFT, RLHF, DPO: в чём разница и что вы выберете?

SFT обучает на парах «вход → эталонный выход». Он учит формату и навыку и требует хороших эталонов. RLHF обучает reward-модель на человеческих предпочтениях, затем дообучает модель через RL со штрафом за отход от исходной. Это мощно, но сложно и нестабильно. DPO (Rafailov и соавторы, 2023) решает ту же задачу без отдельной reward-модели и без сэмплирования во время обучения: учится прямо на парах «предпочтительный / отвергнутый ответ» с классификационной функцией потерь. На практике SFT нужен, чтобы научить формату, а DPO — когда проще сказать, какой из двух ответов лучше, чем написать идеальный (тон, краткость, отказ, где он нужен). Пары берут из логов с фидбеком, из ранжирования людьми или от модели-судьи, откалиброванной по людям. Риск — модель учится «взламывать» предпочтения (например, длиннее значит лучше), поэтому в eval нужен контроль длины. Отдельно проверяю лицензию: условия провайдеров часто ограничивают обучение на выходах их моделей.

На что смотрит интервьюер: может ли кандидат объяснить DPO без reward-модели; знает ли, откуда брать пары, и про reward hacking; помнит ли про лицензии и условия использования.

Данные и governance

Как не допустить утечки PII через LLM-систему?

Защищать нужно весь путь данных, а не одну точку. На ingest: классификация источников, редакция или токенизация PII до индексации, если в ответах она не нужна, ACL в метаданных. В запросе: маскирование перед отправкой внешнему провайдеру, если этого требует политика (обратимая подстановка, когда ответ должен содержать данные), и договор с провайдером о хранении данных и регионе. На выходе: детектор PII в ответе, особенно в мультитенантных системах. Логи и трейсы — главный источник утечек. В общий лог-стек пишутся только метаданные, а полные промпты — в отдельное хранилище с ролевым доступом, сроком хранения и аудитом. Детекторы: регулярки и контрольные суммы (алгоритм Луна для карт) для структурированных PII, NER (Presidio и аналоги) для имён и адресов. Качество NER на русском и на ваших форматах измеряйте на своих данных. Eval: набор с синтетическими PII, метрика — доля просочившихся в логи и ответы, для критичных классов гейт ноль (модуль 11).

На что смотрит интервьюер: видит ли кандидат весь жизненный цикл (ingest → запрос → ответ → логи → eval-датасеты); измеряет ли качество детектора; понимает ли, что главный риск — логи.

Что вы как инженер должны знать про EU AI Act?

Это Регламент (ЕС) 2024/1689, он построен на категориях риска. Ключевые даты по состоянию на октябрь 2026: запрещённые практики действуют со 2 февраля 2025 года; обязанности поставщиков GPAI-моделей — со 2 августа 2025 года (это в основном про провайдеров, но их документация нужна и вам); прозрачность по статье 50 — со 2 августа 2026 года: пользователь должен знать, что общается с ИИ (если это не очевидно из обстоятельств), а синтетический контент маркируется. Требования к high-risk системам из Annex III (найм, кредитный скоринг, образование и другие) Digital Omnibus (Регламент (ЕС) 2026/1744) перенёс на 2 декабря 2027 года, требования по Annex I — на 2 августа 2028 года. Для high-risk нужны управление рисками, качество данных, логирование, техническая документация, человеческий надзор, точность и устойчивость. Инженерные следствия: классифицировать систему в начале проекта, а не перед релизом; трейсы и логи как доказательная база; документация системы (system card); механизм вмешательства человека; evals как свидетельство точности. Применимость к конкретной системе определяет юрист (модуль 11).

На что смотрит интервьюер: не делает ли кандидат юридических выводов за юриста; знает ли категории риска и ключевые даты; переводит ли требования в инженерные артефакты.

Как хранить логи диалогов: что, сколько и как удалять?

Исходный принцип — минимизация: храним то, что нужно для заявленной цели, и не дольше (GDPR, статья 5; у 152-ФЗ та же логика). Классы хранения разделяю. Метаданные и метрики хранятся долго и без текста. Полные тексты для отладки и evals — коротко, в отдельном хранилище, с ограниченным доступом и аудитом. Обезличенные выборки для датасетов — только после редакции PII и с записью происхождения. Удаление по запросу субъекта (GDPR, статья 17) должно доставать до всех копий: логов, трейсов, кэшей, eval-датасетов, векторного индекса, бэкапов по политике. Значит, идентификатор пользователя нужен во всех хранилищах, а для датасетов нужен lineage. Для данных граждан РФ требования локализации (ч. 5 ст. 18 152-ФЗ) и порядок трансграничной передачи (ст. 12) влияют на выбор провайдера и региона. Конкретные сроки и основания определяет юрист (модуль 11).

На что смотрит интервьюер: минимизация и разные классы хранения; удаление «насквозь», включая датасеты и индексы; понимание, как требования к данным влияют на выбор провайдера.

Что такое data flywheel и как его построить, не испортив данные?

Это цикл: продакшн-трафик → сигналы (явный фидбек, эскалации, переформулировки, правки пользователя) → отбор и разметка проблемных случаев → пополнение eval-набора и обучающих данных → улучшение (промпт, retrieval, fine-tuning) → снова прод. Ценность в том, что набор растёт из реального распределения и закрывает реальные ошибки. Риски: смещение выборки (фидбек чаще оставляют недовольные), PII в датасетах, контаминация eval-набора обучающими данными, дрейф гайдлайнов разметки. Контроли: стратифицированный отбор; версионирование датасетов (DVC, lakeFS или неизменяемые JSONL в объектном хранилище с манифестом); гайдлайны разметки с примерами и κ между разметчиками; разделение train и eval по пользователям или по времени; редакция PII до попадания в датасет.

На что смотрит интервьюер: видит ли кандидат цикл целиком; знает ли про смещение фидбека и контаминацию; есть ли версионирование и контроль качества разметки.

Senior-практики: решения, процесс, команда

Эти вопросы задают в поведенческом раунде или в конце system design. Отвечать нужно своей историей в формате STAR. Ниже — структура сильного ответа и пример. Шаблоны документов и разборы — в модуле 13.

Расскажите про ADR: что вы пишете в нём для решения в AI-системе?

ADR (architecture decision record) в формате Майкла Найгарда (2011) — короткий документ на одно решение: заголовок, контекст (силы и ограничения), решение, статус (предложено, принято, заменено) и последствия, хорошие и плохие. Для AI-решений добавляю то, чего нет в обычных ADR. Какие варианты сравнивали на eval-наборе и с какими цифрами: качество с интервалом, $ на запрос, p95. Какие допущения о модели сделаны: версия, цена на дату. И триггеры пересмотра, например «пересматриваем, если новая модель даёт +3 п.п. на наборе или цена падает вдвое»: модели меняются каждые полгода. Пример: «pgvector вместо отдельной векторной БД: 60K чанков, фильтр по ACL в том же SQL-запросе; пересмотр при 50M+ векторов». ADR лежит в репозитории рядом с кодом и ревьюится как PR (модуль 13).

На что смотрит интервьюер: пишет ли кандидат ADR на практике; есть ли в них альтернативы с цифрами и триггеры пересмотра; понимает ли, что AI-решения устаревают быстрее обычных.

Как вы проводите design review чужой LLM-системы?

По чек-листу, а не по вкусу, и вопросами, а не вердиктами. Порядок такой. (1) Проблема и метрика успеха: есть ли измеримое определение «хорошо» и eval-набор. (2) Почему здесь LLM и почему такая сложность, например агент вместо workflow. (3) Модель угроз и права инструментов. (4) Стоимость на запрос и в месяц с явными допущениями. (5) Отказы: что видит пользователь при падении провайдера, таймауте, плохом ответе. (6) Наблюдаемость и откат версии промпта или модели без деплоя. (7) Данные: PII, сроки хранения, ACL. Замечания раскладываю по уровням: блокирующие (нет eval, модель служит границей безопасности), важные, предложения. Автор уходит с решениями и владельцами, а не с ощущением экзамена. Через месяц сверяемся, какие риски сработали.

На что смотрит интервьюер: есть ли структура и приоритизация замечаний; фокус на рисках, которые дорого исправлять потом; умение провести ревью, не задавив автора.

Расскажите о постмортеме AI-инцидента.

Структура по blameless-культуре из SRE-книги Google: таймлайн; влияние в цифрах (сколько пользователей, какие ответы, сколько денег); обнаружение (кто заметил — мониторинг или жалоба, и почему не раньше); корневые причины (обычно их несколько); что сработало; действия с владельцами и сроками. Специфика AI в том, что корень чаще в процессе, а не в коде. Промпт поменяли без прогона evals. Провайдер обновил модель за алиасом. В индекс попал документ с инъекцией. Входы дрейфуют. Действия должны быть системными: закрепить версию модели, поставить eval-гейт на изменения промпта, добавить кейс инцидента в регрессионный набор, завести алерт на онлайн-метрику, которая поймала бы проблему раньше. Пример ответа: «после правки промпта бот начал обещать возвраты; заметили через 2 дня по жалобам; причина — убрали инструкцию без прогона набора; сделали гейт в CI, добавили 20 кейсов про обещания и детектор обещаний без успешного вызова инструмента на выходе» (модуль 13).

На что смотрит интервьюер: blameless-подход и системные действия вместо «будем внимательнее»; есть ли метрика обнаружения; превращается ли инцидент в тест.

Продакт требует поднять метрику, которую вы считаете неправильной. Что делаете?

Пример: продакт хочет довести «долю диалогов без эскалации» до 90%. Сначала выясняю, какую бизнес-цель представляет метрика: снизить нагрузку на операторов. Затем на данных показываю, как метрику можно «улучшить» во вред. Бот перестанет предлагать оператора и начнёт уверенно ошибаться: эскалаций станет меньше, а повторных обращений и жалоб больше (закон Гудхарта). Предлагаю пару: целевая метрика плюс guardrail-метрики (решено с первого раза, повторные обращения в течение 24 часов, CSAT, доля уверенных ошибок на размеченной выборке), а пороги согласуем до эксперимента. Если договориться не вышло, эскалирую с данными. Решение фиксируется в ADR или протоколе, и я его поддерживаю, продолжая следить за guardrail-метриками. Тон разговора — «как мы узнаем, что победили по-настоящему», а не «вы неправы».

На что смотрит интервьюер: переводит ли кандидат спор в данные; знает ли про guardrail-метрики; умеет ли не согласиться, а потом поддержать принятое решение (disagree and commit).

Расскажите, как вы решили, что LLM здесь не нужна.

Структура: задача → данные → baseline без LLM → сравнение на одном наборе → решение с цифрами. Пример ответа: «Команда хотела LLM-классификатор обращений по 12 категориям. Я посмотрел данные: 85% обращений приходят из формы с выпадающим списком, а в свободном тексте 70% случаев ловят 30 правил. Сделали правила плюс логистическую регрессию на эмбеддингах для хвоста, а LLM вызываем только для „прочего“. На наборе из 500 обращений точность сопоставима, латентность в миллисекундах, стоимость близка к нулю». Сильный ответ формулирует принцип. LLM оправдана, когда вход неструктурированный и разнообразный, правила не масштабируются, а ошибка допустима или её ловит проверка. И всегда есть baseline без LLM на том же наборе. Хорошо, если в истории есть и обратный случай, где LLM потом всё-таки понадобилась.

На что смотрит интервьюер: есть ли baseline и измерение; понимает ли кандидат критерии применимости; звучит ли как инженер, выбирающий инструмент, а не как противник AI.

Как вы растите джунов и мидлов в AI-команде?

Через конкретные механизмы. Промпты и evals ревьюятся как код: PR с прогоном набора и комментарии по сути — где проверка, где регрессия. Error analysis делаем в паре: вместе смотрим 50 ответов и учимся видеть категории ошибок. Ownership передаю постепенно: сначала кейс в eval-наборе, потом фича с метрикой, потом дизайн с ADR. Стандарты записаны: как версионируем промпты, что обязательно в трейсе, шаблон design doc. Для coding agents есть правила: что можно генерировать, что обязательно ревьюить руками, тесты до мержа. Прогресс меряю по результату: через квартал человек сам ведёт фичу от eval до продакшна.

На что смотрит интервьюер: механизмы вместо «я всегда помогаю»; связь с практиками качества; как кандидат меряет рост людей.

Как бы вы собеседовали AI engineer в свою команду?

Этапы повторяют реальную работу. (1) Практический кодинг с LLM-интеграцией (ретраи, стриминг, tool use) с разрешёнными AI-ассистентами: смотрим, как кандидат проверяет сгенерированный код. (2) System design с обязательными evals, безопасностью и стоимостью. (3) Error analysis: даём 20 ответов системы и просим разложить ошибки по категориям. Это быстро отличает практика от теоретика. (4) Deep dive по проекту с цифрами. Рубрика готовится заранее, с поведенческими якорями для каждого уровня. Оценки пишутся независимо до обсуждения, чтобы не работал эффект первого мнения, а интервьюеры регулярно калибруются. Красные флаги: в рассказе о проекте нет ни одного числа; «качество смотрели глазами»; модель как граница безопасности.

На что смотрит интервьюер: рубрика и калибровка; задания, близкие к работе; понимание, как не нанять человека, который пересказывает туториалы.

Какие стандарты вы бы ввели в команде, которая строит LLM-фичи?

Минимальный набор, который ловит большинство проблем. Промпт — это код: git, владелец, PR, версия в каждом трейсе. Любое изменение промпта, модели или retrieval проходит eval-гейт в CI с доверительным интервалом. Модель закреплена по полной версии, а смена модели — это релиз с evals. Откат промпта или модели делается флагом без деплоя. На каждый запрос пишется трейс с атрибутами gen_ai.*, стоимостью и версией. У каждого агента есть бюджеты на шаги и $. Для фич с инструментами есть модель угроз и red-team набор. PII не попадает в общие логи. Ключевые решения оформлены как ADR. На каждый инцидент пишется постмортем с регрессионным кейсом. Вводить постепенно, начиная с того, что болит, и автоматизировать (шаблон репозитория, линтер, CI), а не выпускать документ на 30 страниц.

На что смотрит интервьюер: приоритизация и автоматизация вместо бюрократии; покрыты ли качество, безопасность, стоимость и наблюдаемость.

Как вы работаете с coding agents и как не теряете качество кода?

Как с сильным инженером, который только пришёл в проект. Чёткая постановка: цель, ограничения, критерий готовности в виде тестов. Маленькие проверяемые шаги, для больших изменений — план до кода. Контекст проекта лежит в файле правил (CLAUDE.md, AGENTS.md): команды сборки, конвенции, что нельзя трогать. Агент сам запускает тесты и линтер: обратная связь от среды важнее формулировки промпта. Дифф ревьюю как чужой PR, особенно границы доверия, обработку ошибок, конкурентность, удалённые тесты и «упрощённые» проверки. Агент работает в песочнице без прод-секретов, опасные команды требуют подтверждения. Меряю время до мержа и долю возвратов на ревью, а не строки кода. Типичные риски: незамеченные регрессии, разрастание кода, тесты, подогнанные под реализацию (модуль 4).

На что смотрит интервьюер: есть ли процесс и критерии, а не «пишу промпт и принимаю»; знает ли кандидат типичные ошибки агентов; думает ли о безопасности среды.

Флеш-карточки: все 63 вопроса

Сформулируйте ответ вслух, откройте эталон и честно отметьте «знал» или «не знал». Прогресс сохраняется в этом браузере; режим «повторить незнакомые» гоняет только то, что вы не знали. Кнопки категорий помогают добить слабую тему.

Системные дизайн-кейсы по новым темам

Шесть полных разборов с калькулятором и схемами — в модуле 12. Здесь три кейса, которые на senior-интервью задают всё чаще: свой инференс против API, длинный агент и безопасность агента с доступом к чужим данным. Формат короче: вопрос интервьюера → скелет ответа с цифрами → на что смотрят. Скелет из 9 шагов модуля 12 никуда не девается. Ниже подчёркнуто только то, что в этих кейсах отличает сильный ответ.

Кейс 1. Self-host или API: 2 млрд токенов в день

Вопрос интервьюера«Мы обрабатываем около 2 млрд токенов в день: ночное извлечение полей из документов и чат-ассистент для сотрудников. Счёт за API растёт, финансы предлагают купить свои GPU и перейти на open-weight модель. Что посоветуете?»

Скелет ответа.

Разрезать трафик по классам. Офлайн-извлечение и интерактивный чат — разные задачи с разными SLO. Для чата: TTFT p95 ≤ 1 с, TPOT ≤ 50 мс. Для извлечения: результат в течение нескольких часов. Уточнить качество (текущие evals) и ограничения на данные: можно ли отправлять их наружу.
Посчитать базу и применить дешёвые рычаги до покупки железа. Batch API для офлайна и prompt caching часто меняют базу сравнения сильнее, чем кажется.
Честно посчитать self-host: $/1M = GPU $/ч ÷ (ток/с × утилизация × 3600) × 10⁶. Отдельно учесть людей, резерв, пики и то, что GPU поднимаются минутами. Пропускную способность брать из нагрузочного теста по goodput, а не из блога (модуль 10).
Качество как гейт. Open-weight модель на 8–30B должна пройти тот же eval-набор, часто после LoRA. Без этого экономия фиктивная.
Serving: vLLM, ёмкость реплики по KV-cache и SLO, FP8, multi-LoRA для нескольких задач на одной базе, prefix caching для общих инструкций.
Маршрутизация через шлюз: трафик идёт на self-host или в API по классу задачи, с fallback в API при перегрузке или отказе GPU-кластера (модуль 9).
Эксплуатация: SLO и error budget для своего кластера (модуль 9), дежурства, обновления моделей и драйверов, доступность GPU в регионе.
Решение и ADR с условиями пересмотра: «переносим извлечение на self-host; чат оставляем на API; пересматриваем при объёме ×3 или при требовании не отправлять данные наружу» (модуль 13).
Миграция: shadow-трафик, сравнение на eval и онлайн-метриках, канарейка по классу трафика, откат флагом.

Трафик: 2B ток/день = 1.6B вход + 0.4B выход извлечение: 1.2B вход + 0.2B выход; чат: 0.4B вход + 0.2B выход API «в лоб», Haiku 4.5 ($1/$5): 1.6B × $1 + 0.4B × $5 = $3.6K/день ≈ $108K/мес Дешёвые рычаги до покупки GPU: Batch API на извлечение (−50% от $66K) ≈ −$33K/мес prompt caching инструкций чата (60% входа) ≈ −$6K/мес → ≈ $70K/мес, из них извлечение ≈ $33K Self-host только извлечения (ровная ночная очередь, утилизация 70–80%): выход 0.2B/день ≈ 2.3K ток/с, вход 1.2B/день ≈ 14K ток/с (prefill дешевле decode) 2–3 GPU + резерв = 4 × $3/ч × 730 ч ≈ $9K/мес + люди и ops ≈ $8K → ≈ $17K/мес экономия ≈ $16K/мес против Batch API — если модель проходит eval-гейт Чат: пики ×5 и жёсткий TTFT → утилизация GPU 20–40% → остаётся на API

Цены API — те же, что во всём курсе (сентябрь 2026). GPU $3/ч, 2 500 ток/с на GPU и $8K/мес на людей — дефолты калькулятора модуля 10, их нужно заменить своими измерениями.

На что смотрятРазрезает ли кандидат трафик по классам вместо «всё или ничего». Применяет ли Batch API и кэш до покупки железа. Учитывает ли утилизацию, людей и резерв. Ставит ли качество open-weight модели как гейт. Приходит ли к гибриду с условиями пересмотра. Сильный финал: «экономия около $16K в месяц реальна, но съедается, если под неё нужна новая команда. Решающими будут требования к данным и рост объёма, а не текущий счёт».

Кейс 2. Агент на 100+ шагов: миграция 300 сервисов

Вопрос интервьюера«Нужно перевести 300 Go-сервисов со старой библиотеки логирования на log/slogJava-сервисов со старой библиотеки логирования (Log4j 1.x) на SLF4J и Logback. Хотим, чтобы это сделал агент: на сервис уходит 50–150 шагов — читать код, править, гонять тесты. Как спроектируете, чтобы это работало, не разорило и было измеримо?»

Скелет ответа.

Критерий готовности, проверяемый кодом: сборка, тесты, линтер, ни одного импорта старой библиотеки, дифф в пределах затронутых файлов, тесты не удалены и не ослаблены. Права: ветка и PR, никаких мержей и деплоя.
Workflow вокруг агента. Оркестратор — обычный код — идёт по списку сервисов. На каждый сервис запускается отдельный агент в песочнице: контейнер с репозиторием, без секретов, сеть только к прокси модулейпрокси Maven-репозитория. Затем детерминированная проверка, PR с отчётом и ревью человеком. Это 300 независимых задач, а не один агент на 300 сервисов: контексты изолированы, работа параллелится.
Context engineering (модуль 6). Инструменты возвращают мало: grep с лимитом, чтение файла по диапазону строк, у тестов — только упавшие. Файл прогресса в репозитории: план, что сделано, проблемы. Компакция по порогу с фиксированной схемой резюме. Старые результаты тестов вычищаются. Для поиска мест использования в большом сервисе подойдёт субагент.
Лимиты и останов (long-horizon в модуле 6): шаги, токены, $ и время на сервис. Детектор зацикливания: одинаковые вызовы или одна и та же ошибка три раза. Когда бюджет исчерпан, агент открывает draft PR с отчётом, а не проваливается молча. Коммиты по ходу работы служат чекпойнтами, перезапуск идёт с последнего.
Evals (модуль 8). Пилот на 20 сервисах с эталонными PR. Метрики: доля успешных, pass^3, шаги и $ на сервис, лишние изменения в диффе, доля PR, принятых без правок. Для «подгонки» — правки тестов ради зелёного прогона, удаления проверок — терпимость нулевая, детектор смотрит дифф.
Наблюдаемость: трейс на сервис со спанами агента и инструментов, размер контекста по шагам, $ по сервисам, дашборд программы.
Раскатка волнами: 20 → 50 → все. Волна останавливается, если доля успеха ниже порога.

Шаг: префикс 10K (system + инструменты) + история; каждый шаг добавляет ≈ 2K Без управления контекстом, 100 шагов: Σ входа = 100 × 10K + 2K × (1 + … + 100) ≈ 1M + 10M ≈ 11M токенов на сервис к 100-му шагу окно ≈ 210K — context rot задолго до лимита Sonnet 5 без кэша: 11M × $2/1M ≈ $22 на сервис с prompt caching (≈ 90% входа читается из кэша) ≈ $5 С компакцией при 60K и файлом прогресса: окно 20–60K, Σ входа ≈ 4M → ≈ $2–3 на сервис 300 сервисов ≈ $600–1 500: деньги не главное, главное — качество и безопасность Бюджет: ≤ 150 шагов и ≤ $10 на сервис, ≤ $3K на программу, алерты на 50% и 80%

На что смотрятРаскладывает ли кандидат задачу на независимые единицы с workflow вокруг агента. Проверяет ли готовность код, а не модель. Называет ли конкретные техники управления контекстом и порог компакции. Есть ли бюджеты и понятное поведение при их исчерпании. Начинает ли с пилота и eval по траекториям. Помнит ли, что агент может «починить» тесты вместо кода. Хороший знак — кандидат сам говорит, что при $2–5 на сервис спорить надо не о цене, а о доле PR, принятых без правок.

Кейс 3. Безопасность корпоративного ассистента с MCP-коннекторами

Вопрос интервьюера«Внутренний ассистент для 5 000 сотрудников: читает почту, календарь, документы на диске и тикеты через MCP-серверы, ищет в вебе, создаёт документы и отправляет письма. Служба безопасности против запуска. Как спроектируете, чтобы её убедить?»

Скелет ответа.

Модель угроз. Активы: почта, документы, контакты, возможность действовать от имени сотрудника. Границы доверия: входящие письма от внешних людей, веб-страницы, документы, описания инструментов сторонних MCP-серверов. Атакующие: внешний отправитель письма, автор веб-страницы, скомпрометированный MCP-сервер, любопытный коллега. Главная угроза — lethal trifecta в одном агенте: приватные данные, недоверенный контент и каналы наружу (письмо, веб-запрос, markdown-картинка).
Разорвать трифекту по сценариям. В сценарии «резюмируй входящие» нет инструментов отправки и веба, либо работает схема dual LLM: карантинная модель без инструментов читает письма, привилегированная видит только переменные. В сценарии «напиши письмо» отправка возможна только после подтверждения в интерфейсе с показом получателя и текста, а внешние домены дают отдельное предупреждение. Веб-поиск — отдельный режим без доступа к почте.
Права: каждый вызов MCP идёт с OAuth-токеном конкретного сотрудника и минимальным scope, read-only по умолчанию. Никакого сервисного аккаунта «на всех». ACL документов проверяет источник.
Цепочка поставок MCP (LLM04): только внутренний реестр одобренных серверов с пиннингом версий, хэш описаний инструментов с алертом на изменение (rug pull), изоляция серверов, allowlist исходящих соединений.
Обработка вывода (LLM10): markdown рендерится без внешних картинок и автоссылок — это канал эксфильтрации; HTML санитизируется.
Неограниченное потребление (LLM06): лимиты шагов и $ на сессию и на пользователя.
Red-team как eval (модуль 7). 200+ атак по категориям: инъекции в письмо, документ и веб-страницу, эксфильтрация через ссылку, отправка без запроса, отравленное описание инструмента. ASR считается по категориям. Гейт в CI — ноль эксфильтраций и несанкционированных действий, а ASR по «мягким» категориям держится ниже согласованного порога.
Обнаружение и реагирование. Аудит всех вызовов инструментов. Алерты на аномалии, например письмо на новый внешний адрес сразу после чтения входящего от внешнего отправителя. Kill switch для инструмента или сервера через флаг. Процесс инцидента с постмортемом (модуль 13).
Данные и прозрачность: логи с PII хранятся отдельно и со сроком хранения. Сотрудники знают, что работают с ИИ: в ЕС статья 50 EU AI Act требует сообщать об этом, если это не очевидно из обстоятельств, а применимость определяет юрист (модуль 11).

Red-team: 0 успешных эксфильтраций из 200 попыток верхняя граница 95%-интервала по правилу трёх ≈ 3/200 = 1.5% → «ноль в отчёте» не означает «ноль в проде»: при 5 000 сотрудников и десятках внешних писем в день атакующий получит тысячи попыток → поэтому опасные действия закрыты архитектурой (подтверждение, права, egress), а red-team проверяет, что архитектура держит

На что смотрятНачинает ли кандидат с модели угроз. Знает ли lethal trifecta и разрывает ли её по сценариям, а не «добавим классификатор». Работает ли агент с правами пользователя, а не сервиса. Думает ли о цепочке поставок MCP и об эксфильтрации через markdown. Есть ли red-team с метрикой и понимание правила трёх. Предусмотрены ли обнаружение и реагирование, а не только предотвращение. И признаёт ли кандидат компромисс: каждое ограничение снижает полезность, поэтому сценарии с низким риском (поиск по своим документам) запускаются первыми.

Как рассказывать о проектах

Deep dive по проектам — раунд, на котором решается уровень. Интервьюер проверяет три вещи: делали ли вы это сами, понимаете ли, почему решения именно такие, и умеете ли измерять результат. Рассказ строится по пяти блокам — это вариация STAR (Situation, Task, Action, Result), адаптированная под инженерные проекты с LLM.

Блок	Что сказать	Время	Типичная ошибка
Задача	Контекст и масштаб: кто пользователи, какая боль, цифры (объём данных, пользователи, сколько времени терялось). Почему это важно бизнесу.	20–30 с	«Мы делали чат-бота» без масштаба и мотивации.
Решение	Архитектура в 3–5 компонентах, ваша роль («я спроектировал», «я написал»), 2–3 ключевых решения и отвергнутые альтернативы с причинами.	40–60 с	Перечисление технологий без «почему»; «мы» вместо «я».
Метрики	Как измеряли качество (набор, метрика, судья и его калибровка), числа до и после, латентность, стоимость, бизнес-эффект.	20–30 с	«Стало лучше», «пользователи довольны».
Ошибки	Что пошло не так и как вы это обнаружили и исправили. Это сигнал реального опыта.	20–30 с	«Всё прошло гладко» — никто не верит.
Улучшения	Что сделали бы дальше или иначе и почему. Показывает, что вы видите ограничения своей системы.	10–20 с	Нет ответа или «ничего бы не менял».

Итого 2–3 минуты на первый проход. Дальше интервьюер будет копать в любую точку, поэтому для каждого решения держите в голове следующий уровень: «почему pgvector, а не Qdrant?», «как калибровали судью?», «откуда 120 вопросов?».

Пример: RAG по документации на Go

Пример: RAG по документации на Java

Задача. У платформенной команды ≈ 3 000 страниц в Confluence и 400 README в репозиториях; 300 инженеров задавали одни и те же вопросы в Slack, дежурный тратил около 15 часов в неделю на ответы.

Решение. Я спроектировал и написал сервис на GoJava (Spring Boot): ingest из Confluence и Git по webhook, чанкинг по заголовкам (≈ 500 токенов, код-блоки не режутся), эмбеддинги в Postgres с pgvector (HNSW), гибридный поиск с tsvector и RRF, rerank top-30, генерация на Sonnet со стримингом через SSE и обязательными цитатами; поверх — Slack-бот. pgvector выбрал вместо отдельной векторной БД: 60K чанков, фильтр по правам в том же SQL-запросе, одна база в эксплуатации. Отдельную векторную БД рассматривал, но на таком объёме она давала только операционную сложность.

Метрики. Собрал golden set из 120 реальных вопросов из истории Slack с правильными страницами. Recall@5 вырос с 0.62 до 0.87 за счёт гибрида и rerank; faithfulness 0.91 по LLM-судье, откалиброванному на 100 ответах, размеченных мной и коллегой (согласие 88%). p95 TTFT 1.2 с, стоимость ≈ $0.004 за вопрос, ≈ $180 в месяц. Повторяющиеся вопросы в канале поддержки сократились на 40% за два месяца.

Ошибки. Сначала резал текст по 1 000 символов — ломались таблицы и примеры кода, recall был 0.48; переход на структурный чанкинг дал самый большой прирост. Второе: бот цитировал страницы из закрытых пространств — нашли на ревью; добавил фильтр по группам пользователя прямо в SQL и тест на утечку в CI.

Улучшения. Переписывание коротких запросов, кэш ответов на топ-50 вопросов, evals на каждый PR вместо ночного прогона, contextual chunking (добавить в чанк заголовок документа и раздела).

Обратите внимание, что в примере нет ни одного прилагательного-оценки («отличный», «эффективный»): только решения, цифры и причины. Конструктор ниже помогает собрать такой рассказ о своём проекте и показывает, где не хватает конкретики.

Конструктор рассказа о проекте

Заполните пять блоков. Справа не будет магии: простые эвристики подсвечивают пропуски — нет цифр, нет «было → стало», «мы» вместо «я», пустые ошибки. Черновик сохраняется в этом браузере.

Проект Задача Пользователи, боль, масштаб в цифрах Решение Архитектура, ваша роль, ключевые решения и отвергнутые альтернативы Метрики Как измеряли, было → стало, латентность, стоимость, эффект Ошибки Что сломалось, как обнаружили, как исправили Улучшения Что бы сделали дальше и почему

Take-home

Типичное задание: «за 4–8 часов сделайте сервис, который отвечает на вопросы по этим документам / извлекает поля из этих писем / классифицирует тикеты». Почти все присылают работающий код. Выделяются те, кто присылает измеренный работающий код с честным описанием компромиссов.

README — половина оценки

Как запустить одной командой (make run / docker compose up), архитектура в 5 строках или схеме, ключевые решения и альтернативы, результаты evals таблицей, стоимость и латентность, известные ограничения, что бы сделали за следующую неделю.

Evals обязательны

Даже если не просили: 20–50 примеров, метрика, скрипт make eval, таблица результатов для 2–3 вариантов (например, разные чанкинги или модели). Это главный дифференциатор.

Компромиссы явно

«Выбрал X, потому что Y; при объёме Z перешёл бы на W». Интервьюер ищет понимание границ решения, а не максимальную сложность.

Стоимость

Сколько стоил прогон evals, сколько будет стоить 1 000 запросов в день, какой рычаг экономии следующий. Одна таблица — и вы выглядите как человек, который уже запускал такое в прод.

Инженерная гигиена

Ключи из env, таймауты и ретраи, обработка ошибок, пара тестов на детерминированные части (чанкер, парсер), линтер. Структура репозитория, понятная за минуту.

Не переусердствовать

Если лимит 6 часов, не тратьте 30: это видно и считается сигналом плохой приоритизации. Лучше честный раздел «не успел, сделал бы так».

# Структура README для take-home
## Запуск            — одна команда, требования (Java 21+, Docker, ANTHROPIC_API_KEY)
## Архитектура       — схема или 5 строк: ingest → index → retrieve → generate
## Решения           — 3–5 пунктов «выбрал X вместо Y, потому что…»
## Evals             — набор (сколько, откуда), метрики, таблица результатов вариантов
## Стоимость и латентность — $ за прогон evals, $ на 1K запросов, p50/p95
## Ограничения       — что не работает и почему
## Что дальше        — план на следующую неделю по приоритету

# Структура README для take-home
## Запуск            — одна команда, требования (Go 1.23+, Docker, ANTHROPIC_API_KEY)
## Архитектура       — схема или 5 строк: ingest → index → retrieve → generate
## Решения           — 3–5 пунктов «выбрал X вместо Y, потому что…»
## Evals             — набор (сколько, откуда), метрики, таблица результатов вариантов
## Стоимость и латентность — $ за прогон evals, $ на 1K запросов, p50/p95
## Ограничения       — что не работает и почему
## Что дальше        — план на следующую неделю по приоритету

Что оценивают на самом делеПо опыту ревьюеров take-home, чаще всего отсеивают за: отсутствие какой-либо проверки качества («работает на трёх примерах, которые я попробовал»), неработающий запуск, ключ API в репозитории, отсутствие обработки ошибок API и README из одной строки. Реже — за выбор технологий: почти любой выбор приемлем, если обоснован.

Вопросы работодателю

Ваши вопросы — тоже часть оценки, и одновременно способ понять, будет ли вам там хорошо. Для AI-ролей особенно важно понять, насколько зрелая у команды практика.

Evals: «Как вы сейчас понимаете, что новая версия промпта или модели не хуже? Есть ли golden set, кто его поддерживает?»
Продакшн: «Какие LLM-фичи уже в проде и какой у них трафик? Что было последним инцидентом, связанным с моделью?»
Стоимость: «Кто отвечает за бюджет на LLM и как его отслеживают? Были ли решения, принятые из-за стоимости?»
Роль: «Как делится работа между AI engineer, ML engineer и бэкендом? Кто владеет данными для evals?»
Модели: «Как вы выбираете провайдера и модель? Как часто переезжаете на новые версии?»
Данные: «Какие ограничения по данным: можно ли отправлять провайдерам, есть ли PII?»
Безопасность: «Кто отвечает за модель угроз и red-team для AI-фич? Были ли инциденты с prompt injection, и что после них изменили?»
Успех: «Как будет выглядеть успех в этой роли через 6 месяцев? Какая метрика?»
Команда: «Что в текущей AI-архитектуре вы бы переделали, если бы начинали заново?»

Красные флаги

Флаг	Что это обычно значит
«У нас нет evals, качество смотрим глазами» (и не планируют)	Каждое изменение промпта будет лотереей, а виноватым в регрессиях окажетесь вы.
«Нужно добавить AI в продукт», но нет конкретной задачи и метрики	Проект ради пресс-релиза; высок риск закрытия через 6 месяцев.
Ожидание, что модель будет «всегда права», и никакого человека в контуре для рискованных решений	Непонимание технологии у руководства; ответственность за вероятностную систему ляжет на вас.
Никто не может сказать, сколько тратится на API	Нет операционной зрелости; первая большая инвойс-неожиданность приведёт к панике.
Роль называется AI engineer, а на деле — поддержка чужого прототипа на Jupyter в проде	Спросите, какой процент времени уходит на новые фичи и какой на пожары.
Собственная «LLM с нуля» у компании без исследовательской команды и бюджета	Нереалистичные ожидания и, скорее всего, выгорание команды.
На интервью не спросили ничего про продакшн, только про промпты	Команда может быть на стадии демо; уточните, есть ли реальные пользователи.
Агенту дали сервисный аккаунт с полными правами, «чтобы быстрее запуститься»	Excessive agency по умолчанию: первая успешная инъекция станет вашим инцидентом, а переделывать права после запуска дороже.
«Модель обновляется сама, мы всегда на последней версии», без закреплённых версий и evals	Регрессии будут приходить без вашего участия, а разбирать их придётся вам.

Чек-лист готовности

Отмечайте только то, что можете сделать или объяснить без подготовки прямо сейчас. Прогресс сохраняется в браузере. Цель перед собеседованием — 80%+ в каждой категории. На senior-позицию категории «Безопасность», «Свои модели», «Данные и governance» и «Senior-практики» обязательны, а не факультативны.

Готовность по категориям

Кольцо показывает общий процент, внутренние дуги — категории. Клик по дуге прокручивает к категории.

План последних двух недель

Предполагается, что модули 0–13 и хотя бы два сквозных проекта готовы. Если вы уже защитили капстоун (модуль 15), он становится главным проектом для deep dive: в нём есть все цифры, о которых спросят. Две недели нужны не для новых знаний, а для скорости воспроизведения и уверенности.

День	Фокус	Конкретно
1	Диагностика	Пройти чек-лист и все флеш-карточки по 11 категориям; записать слабые.
2	Истории	Два проекта через конструктор (капстоун, если готов, — один из них); выучить цифры; 6 поведенческих и 3–4 senior-истории в STAR: ADR, постмортем, спор о метрике.
3	Кодинг LLM	С нуля без подсказок: клиент с ретраями и стримингом на GoJava, цикл tool use с лимитами шагов и $ и компакцией истории. Таймер 30 минут на каждое.
4	Кодинг обычный	4–6 задач среднего уровня (хэш-таблицы, графы, интервалы), rate limiter, LRU.
5	System design	Два разбора из модуля 12 вслух с таймером 45 минут, один из них — Разбор 6 (security-first); запись на видео, разбор.
6	Слабые темы	Повторить модули по слабым категориям чек-листа: безопасность — модуль 7, evals — 8, свои модели — 10, данные — 11, senior — 13; незнакомые карточки.
7	Отдых + лёгкое	Прочитать 2–3 свежих инженерных поста провайдеров и инженерных блогов; ничего не кодить.
8	Мок-интервью	Полный мок system design с другом или коллегой и 20 минут senior-вопросов о решениях и команде; обратная связь по структуре.
9	Мини take-home	За 4 часа: RAG или извлечение с evals, десятком red-team атак и README. Тренировка приоритизации.
10	System design	Три кейса из раздела выше: self-host против API, агент на 100+ шагов, безопасность ассистента. Плюс один кейс вне курса (код-ревью бот). Считать стоимость за 2 минуты.
11	Deep dive	Попросить коллегу задать 20 «почему» по вашему проекту или капстоуну. Доверительный интервал, ASR, $ на запрос и p95 — наизусть. Всё, на что не ответили, — дописать в заметки.
12	Компания	Изучить продукт, инженерный блог, вакансию; подготовить 5 вопросов работодателю; прикинуть, какие AI-фичи у них есть и как бы вы их спроектировали.
13	Прогон	Флеш-карточки «незнакомые», чек-лист до 80%+, рассказ проектов вслух по разу.
14	Отдых	Проверить технику (камера, звук, IDE, доступ к API-ключу для лайв-кодинга). Лечь спать вовремя.

Практика

Задание 1: два проекта в формате рассказа

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

Критерии готовности: конструктор не показывает красных предупреждений; рассказ укладывается в 2–3 минуты; в метриках минимум три числа с «было → стало»; на вопрос «почему не X?» есть ответ для каждого ключевого решения.

Проект 1 готов и проговорён Проект 2 готов и проговорён

Задание 2: флеш-карточки до 90%

Пройдите все карточки, затем режим «незнакомые» до тех пор, пока «знал» не станет ≥ 90%. Для каждого «не знал» вернитесь в соответствующий модуль курса.

≥ 90% карточек «знал»

Задание 3: take-home на время

За 5 часов: сервис на GoJava, который извлекает из писем клиентов (возьмите 50 публичных или синтетических) поля «продукт, проблема, срочность» через structured output; eval на 30 размеченных письмах (точность по полям), сравнение двух моделей, README по структуре выше со стоимостью.

Сделано в лимит времени, README и eval-таблица есть

Задание 4: поведенческие истории

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

Шесть историй записаны и проговорены

Задание 5: три дизайн-кейса по новым темам

Проведите три 45-минутных мок-интервью по кейсам из раздела «Системные дизайн-кейсы». Интервьюер — коллега или LLM, которой вы дали скелет модуля 12 и блок «На что смотрят» как рубрику. Подставляйте цифры своего сквозного проекта: свой объём токенов, свои инструменты агента.

К 8-й минуте на доске есть цифры: трафик по классам, бюджет, SLO.
В кейсе 1 есть расчёт self-host по формуле с утилизацией и людьми, а дешёвые рычаги API применены до сравнения.
В кейсе 2 есть критерий готовности, проверяемый кодом, бюджеты и поведение при их исчерпании, eval на пилоте.
В кейсе 3 есть модель угроз, разрыв трифекты по сценариям, red-team с ASR и правило трёх.
Каждый кейс заканчивается решением с условием пересмотра, как в ADR.

Self-host или API Агент на 100+ шагов Безопасность ассистента с MCP

Задание 6: четыре senior-истории

Подготовьте четыре истории из своей практики или из сквозных проектов и капстоуна: (1) решение, которое вы оформили как ADR и потом пересмотрели или защитили; (2) design review или постмортем, после которого изменился процесс; (3) спор о метрике или «здесь LLM не нужна»; (4) как вы растили человека или вводили стандарт в команде. Используйте структуры ответов из категории «Senior-практики».

Каждая история укладывается в 2 минуты и заканчивается результатом в цифрах или изменением процесса.
В каждой есть ваша роль («я»), альтернатива, которую вы отвергли, и то, что вы сделали бы иначе.
На вопрос «а что, если бы стейкхолдер не согласился?» есть ответ.

Четыре истории записаны и проговорены вслух

Самопроверка

Из каких пяти этапов обычно состоит процесс найма AI engineer?

Скрининг, кодинг (часто обычный + раунд с LLM-интеграцией), AI system design, deep dive по проектам, поведенческое интервью. Порядок и названия варьируются.

Какие пять блоков в рассказе о проекте и какой из них чаще всего пропускают?

Задача, решение, метрики, ошибки, улучшения. Чаще всего пропускают метрики (или заменяют их прилагательными) и ошибки.

Что в take-home выделяет кандидата сильнее всего?

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

Почему в рассказе важно говорить «я», а не «мы»?

Интервьюер оценивает вас, а не команду. «Мы» не позволяет понять, что сделали лично вы. Правильно: «команда из четырёх человек; я отвечал за retrieval и evals, решил…».

Какой вопрос работодателю лучше всего показывает зрелость AI-практики в команде?

«Как вы понимаете, что новая версия промпта или модели не хуже старой?» — наличие или отсутствие evals сразу видно по ответу.

Что делать в последние два дня перед собеседованием?

Лёгкий прогон (незнакомые карточки, рассказы вслух), проверка техники и окружения, отдых. Новые темы не учить: это повышает тревожность и почти не добавляет результата.

Какие темы отличают senior-интервью на AI engineer от middle?

Безопасность как система (модель угроз, OWASP, excessive agency, red-team), свои модели и TCO, context engineering для длинных агентов, статистика evals (интервалы, κ, A/B, траектории), данные и governance, а также решения и процессы: ADR, design review, постмортемы, работа со стейкхолдерами и командой.

Что такое правило трёх и где оно пригодится на интервью?

Если из n попыток не было ни одного «успеха», верхняя граница 95%-интервала для настоящей доли ≈ 3/n. Пригодится, когда говорите о red-team («0 из 200 атак — это не ноль, а ≤ 1.5%») и о редких отказах вроде утечек. Из этого следует, что опасные действия должны быть закрыты архитектурой, а не результатом теста.

Почему в кейсе «self-host или API» сначала применяют Batch API и prompt caching?

Эти рычаги снижают счёт за API без операционных рисков и меняют базу сравнения. Если сравнивать self-host с ценой API «в лоб», выгода self-host завышается вдвое и больше, и решение принимается на неверных цифрах.

Какие три вещи должны прозвучать в любом ответе на дизайн-кейс про безопасность агента?

Модель угроз (активы, границы доверия, атакующие). Контроли вне модели: права пользователя, разрыв lethal trifecta, подтверждение в доверенном интерфейсе. Измерение: red-team с ASR по категориям и гейтом в CI, плюс обнаружение и реагирование в проде.

Вопросы с собеседований

Концептуальные вопросы собраны выше. Senior-вопросы о решениях, процессе и команде — в категории «Senior-практики», дизайн-кейсы — в отдельном разделе. Здесь — мета-вопросы и поведенческие вопросы, специфичные для AI-ролей.

Почему вы переходите из бэкенда в AI engineering?

Честная и конкретная история на 60 секунд: что вы уже построили с LLM (проект с цифрами), что увидели — что узкое место AI-продуктов не в моделях, а в инженерии вокруг них (надёжность, evals, стоимость, данные), и почему ваш бэкенд-опыт прямо в это переносится. Не говорить «потому что это хайп» и не принижать бэкенд.

Расскажите о случае, когда LLM-фича не сработала так, как ожидалось.

STAR с акцентом на то, как обнаружили (метрика, фидбек, инцидент), как нашли корневую причину (трейсы, разбор ошибок по категориям), что изменили (не только промпт, но и процесс: добавили кейсы в golden set, гейт в CI) и какой был результат в цифрах. Сильный ответ показывает, что вы превращаете инциденты в тесты.

Как вы объясните продакт-менеджеру, почему модель иногда ошибается и это нельзя «просто починить»?

Без жаргона: модель статистическая, у неё есть доля ошибок, как у поиска или у человека-оператора; задача — не ноль ошибок, а приемлемая доля при приемлемой цене и понятное поведение при ошибке. Предложить язык метрик: «сейчас 92% ответов корректны на наборе из 300 реальных вопросов; до 96% можно дойти за счёт X за Y недель и Z $/мес; для оставшихся делаем эскалацию на человека». Перевести разговор от «почини» к «какой уровень качества нужен и сколько он стоит».

Как вы решаете, нужна ли LLM для задачи вообще?

Проверяю: есть ли детерминированное решение (правила, регулярки, SQL, классический классификатор), которое даёт нужное качество; какова цена ошибки; какой объём и нужна ли латентность в миллисекундах; есть ли данные для evals. LLM оправдана, когда вход неструктурированный и разнообразный, правила не масштабируются, а ошибка допустима или ловится. Часто лучший ответ — гибрид: правила для 80% простых случаев и LLM для хвоста.

Как вы следите за изменениями в области, которая меняется каждый месяц?

Конкретика вместо «читаю Twitter»: документация и changelog провайдеров, инженерные блоги (Anthropic engineering, блоги практиков вроде Simon Willison, Hamel Husain, Eugene Yan), выборочно пейперы по своей теме. И главное — собственный eval-набор: новая модель или техника проверяется на нём за час, а не по отзывам в соцсетях.

Вы не согласны с решением команды использовать мультиагентную архитектуру. Что сделаете?

Сформулирую несогласие через измеримое: предложу сравнить на общем eval-наборе мультиагентный вариант и простой workflow по качеству, стоимости и латентности; сделаю прототип простого варианта за день-два. Если данные показывают, что сложный вариант лучше — поддерживаю его. Показать, что решение принимается по данным, а не по статусу, и что после решения вы в команде, а не в оппозиции.

Что вы сделаете в первые 90 дней на этой позиции?

30 дней: разобраться в продукте и текущих AI-фичах, прочитать трейсы и 100+ реальных ответов, понять, как сейчас измеряется качество и сколько всё стоит. 60 дней: собрать или улучшить golden set и evals в CI для главной фичи, закрыть самую очевидную проблему (часто это retrieval или отсутствие fallback). 90 дней: измеримое улучшение ключевой метрики или стоимости и план на следующий квартал. Упомянуть, что начнёте с вопросов, а не с переписывания.

Какой ваш самый большой технический компромисс в LLM-проекте?

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

Источники

Anthropic: Building effective agents
Документация Anthropic — tool use, prompt caching, batch, structured outputs
Hamel Husain: Your AI product needs evals
Eugene Yan: Patterns for building LLM-based systems and products
Simon Willison: The lethal trifecta for AI agents
Chip Huyen: AI Engineering (O'Reilly, 2025)
Tech Interview Handbook: поведенческие интервью
Model Context Protocol: спецификация и SDK
OWASP: Top 10 for LLM Applications 2026 (исходный текст на GitHub) — список рисков LLM01–LLM10 и описание каждого
Beurer-Kellner et al.: Design Patterns for Securing LLM Agents against Prompt Injections (2025) — action-selector, plan-then-execute, dual LLM, code-then-execute
Debenedetti et al.: Defeating Prompt Injections by Design (CaMeL, 2025)
Anthropic: Effective context engineering for AI agents (2025) — компакция, заметки, субагенты, just-in-time
Anthropic: Effective harnesses for long-running agents (2025) — инициализирующий агент, файл прогресса, список фич в JSON
Anthropic: How we built our multi-agent research system (2025) — расход токенов агентов и мультиагентных систем
LangChain: Context engineering for agents (2025) — таксономия write / select / compress / isolate
Chroma: Context Rot (2025) — деградация качества с ростом длины входа на 18 моделях
Yao et al.: τ-bench (2024) — оценка агента по итоговому состоянию и метрика pass^k
Zhong et al.: DistServe (OSDI 2024) — goodput при ограничениях на TTFT и TPOT
Kwon et al.: PagedAttention / vLLM (2023)
Hu et al.: LoRA (2021), Dettmers et al.: QLoRA (2023), Rafailov et al.: DPO (2023)
EUR-Lex: Регламент (ЕС) 2024/1689 (AI Act) — первичный текст; даты после Digital Omnibus сверяйте с модулем 11
Michael Nygard: Documenting Architecture Decisions (2011) — формат ADR
Google SRE Book: Postmortem Culture — blameless-постмортемы и критерии, когда их писать
Kohavi, Tang, Xu: Trustworthy Online Controlled Experiments — A/B-тесты, SRM, guardrail-метрики