AI system design

Чем AI system design отличается от обычного

Классический system design проверяет, умеете ли вы разложить нагрузку: шардирование, кэши, очереди, консистентность. AI system design проверяет то же самое плюс три вещи, которых в обычном нет.

1. Недетерминированный компонент в центре. LLM ошибается, и это не баг, который чинится одним фиксом, а статистическое свойство. Поэтому в ответе обязательно должно быть «как мы измеряем качество» (evals, от evaluation) и «что делаем, когда модель неправа». Кандидат, который рисует стрелку «→ LLM → ответ» и идёт дальше, проваливается.
2. Стоимость на единицу запроса заметна. Запрос к Postgres стоит микроценты, запрос к топовой модели с контекстом 20K токенов стоит несколько центов. При миллионе запросов в день это десятки тысяч долларов в месяц, и архитектурные решения (кэш, роутинг на дешёвую модель, batch) напрямую меняют юнит-экономику продукта.
3. Латентность в секундах, а не миллисекундах. Генерация 500 токенов занимает 5–10 секунд. Отсюда стриминг, асинхронные сценарии, бюджеты на каждый шаг агента и совсем другие таймауты.

Остальное вам знакомо: очереди, идемпотентность, ретраи с backoff, rate limiting, observability. Именно здесь GoJava-бэкграунд даёт преимущество перед кандидатами из data science: вы говорите о p99, backpressure и circuit breaker как о чём-то очевидном.

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

У интервьюера в голове чек-лист, и порядок ответа облегчает ему работу. Скелет ниже повторяет порядок, в котором решения зависят друг от друга: нельзя выбрать модель, не зная бюджета латентности, и нельзя обсуждать evals, не определив, что такое «хороший ответ».

Тайм-менеджмент 45 минут

Главная ошибка по времени: 25 минут на архитектуру коробок и ни слова про evals и стоимость. Второе по частоте: 10 минут уточнений без единой цифры. Таймлайн ниже показывает разумное распределение. Двигайте ползунок или нажмите «прогнать», чтобы увидеть, где вы должны быть к каждой минуте.

Типичные ошибки кандидатов

Требования и цифры

Нефункциональные требования у LLM-системы задаются в других единицах, чем у CRUD-сервиса. Держите в голове эту таблицу и спрашивайте по ней.

Стоимость: формула и расчёт

Базовая формула для одного вызова модели:

Для агента умножайте на число шагов, причём вход каждого шага включает всю историю: вход растёт примерно квадратично по числу шагов, если не резать контекст. Именно поэтому prompt caching для агентов не оптимизация, а обязательная часть дизайна.

Пример расчёта вслух

«Поддержка: 2M сообщений в месяц, это ≈ 0.8 RPS в среднем, пик ×10 ≈ 8 RPS. На запрос: системный промпт 1.5K токенов, 5 чанков по 500 = 2.5K, история 1K, вопрос 100. Итого ≈ 5K входа и 300 выхода. Sonnet 5 по $2/$10 за миллион:»

Две минуты счёта, и у вас есть аргумент для каждого решения дальше: зачем кэш, зачем роутинг, почему не Fable. Калькулятор ниже делает то же самое и добавляет требования к rate limits и памяти векторного индекса.

// Оценка стоимости и лимитов: тот же расчёт, что в калькуляторе.
package estimate;

public final class Estimate {
    /** $ за 1M токенов; cacheRead — множитель чтения кэша: 0.1 (Opus 5.5 — 0.05, Fable 5.1 — 0.025). */
    public record Price(double in, double out, double cacheRead) {}

    public record Load(
            double rpsAvg, double peakFactor,
            double inTokens, double outTokens,
            double cachedShare,  // доля входа, читаемая из prompt cache
            double callsPerReq,  // шагов агента / вызовов модели
            double respCacheHit, // доля запросов, отданных из кэша ответов
            boolean batch) {}

    /** perReq и perMonth — в $. */
    public record Result(double perReq, double perMonth, double peakRpm, double itpm, double otpm) {}

    static final double SEC_PER_MONTH = 2.6e6;

    public static Result estimate(Load l, Price p) {
        double cached = l.inTokens() * l.cachedShare();
        double uncached = l.inTokens() - cached;
        double perCall = (uncached * p.in() + cached * p.in() * p.cacheRead() + l.outTokens() * p.out()) / 1e6;
        double perReq = perCall * l.callsPerReq() * (l.batch() ? 0.5 : 1);
        double month = l.rpsAvg() * SEC_PER_MONTH * (1 - l.respCacheHit()) * perReq;
        double peakCallsPerMin = l.rpsAvg() * l.peakFactor() * 60 * l.callsPerReq() * (1 - l.respCacheHit());
        return new Result(perReq, month, peakCallsPerMin,
                peakCallsPerMin * l.inTokens(), // проверьте, считает ли ваш тир cached-токены в ITPM
                peakCallsPerMin * l.outTokens());
    }
}

// Оценка стоимости и лимитов: тот же расчёт, что в калькуляторе.
package estimate

type Price struct{ In, Out, CacheRead float64 } // $ за 1M токенов; CacheRead — множитель чтения кэша: 0.1 (Opus 5.5 — 0.05, Fable 5.1 — 0.025)

type Load struct {
	RPSAvg, PeakFactor   float64
	InTokens, OutTokens  float64
	CachedShare          float64 // доля входа, читаемая из prompt cache
	CallsPerReq          float64 // шагов агента / вызовов модели
	RespCacheHit         float64 // доля запросов, отданных из кэша ответов
	Batch                bool
}

const secPerMonth = 2.6e6

type Result struct {
	PerReq, PerMonth   float64 // $
	PeakRPM, ITPM, OTPM float64
}

func Estimate(l Load, p Price) Result {
	cached := l.InTokens * l.CachedShare
	uncached := l.InTokens - cached
	perCall := (uncached*p.In + cached*p.In*p.CacheRead + l.OutTokens*p.Out) / 1e6
	perReq := perCall * l.CallsPerReq
	if l.Batch {
		perReq *= 0.5
	}
	month := l.RPSAvg * secPerMonth * (1 - l.RespCacheHit) * perReq
	peakCallsPerMin := l.RPSAvg * l.PeakFactor * 60 * l.CallsPerReq * (1 - l.RespCacheHit)
	return Result{
		PerReq:   perReq,
		PerMonth: month,
		PeakRPM:  peakCallsPerMin,
		ITPM:     peakCallsPerMin * l.InTokens, // проверьте, считает ли ваш тир cached-токены в ITPM
		OTPM:     peakCallsPerMin * l.OutTokens,
	}
}

# То же в ноутбуке: удобно гонять сценарии «а если» в pandas.
import pandas as pd

PRICES = {  # $ за 1M токенов вход/выход и множитель чтения кэша (октябрь 2026)
    "claude-fable-5-1": (10, 50, 0.025), "claude-opus-5-5": (4, 20, 0.05),
    "claude-opus-5": (5, 25, 0.1), "claude-sonnet-5": (2, 10, 0.1), "claude-haiku-4-5": (1, 5, 0.1),
}
SEC_PER_MONTH = 2.6e6

def estimate(rps, tin, tout, model, cached_share=0.0, calls=1, hit=0.0, batch=False):
    p_in, p_out, cache_read = PRICES[model]
    cached = tin * cached_share
    per_call = ((tin - cached) * p_in + cached * p_in * cache_read + tout * p_out) / 1e6
    per_req = per_call * calls * (0.5 if batch else 1)
    return {"model": model, "per_req": per_req,
            "per_month": rps * SEC_PER_MONTH * (1 - hit) * per_req}

rows = [estimate(0.8, 5000, 300, m, cached_share=0.3) for m in PRICES]
print(pd.DataFrame(rows).sort_values("per_month").to_string(index=False))

Память векторного индекса

Сырые векторы занимают N × d × b байт, где b зависит от типа: 4 для float32, 1 для int8, 1/8 для бинарной квантизации. HNSW (Hierarchical Navigable Small World, граф ближайших соседей) добавляет списки соседей: на нулевом слое 2·M идентификаторов по 4 байта, верхние слои дают ещё порядка 10%. Итого на вектор примерно d × b + 2 × M × 4 × 1.1 байт плюс метаданные.

Шесть разборов: интерактивная схема

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

Разбор 1. Чат-бот поддержки по базе знаний

Постановка: «SaaS-платформа хочет встроить бота поддержки в виджет своих клиентов. У каждого клиента (тенанта) своя база знаний: статьи, FAQ, PDF с регламентами. Бот отвечает, а когда не может, передаёт диалог человеку».

Требования и цифры

Расчёт на салфетке

Архитектура

Запрос проходит API с аутентификацией тенанта, guardrails (детектор injection, маскирование PII), лёгкий классификатор намерения (вопрос по базе, действие с аккаунтом, жалоба, «позовите человека»), затем гибридный retrieval строго в пределах тенанта, генерацию с цитатами и проверку уверенности. Эскалация срабатывает по трём сигналам: явная просьба, низкая уверенность (retrieval ничего релевантного не нашёл или модель отказалась), негативный сентимент после двух попыток. При эскалации оператор получает саммари диалога и найденные статьи, чтобы клиенту не повторять всё заново.

Ключевые решения и альтернативы

Evals

• Golden set на тенанта-эталон: 200–300 реальных вопросов из истории тикетов с правильной статьёй и эталонным ответом. Отдельные подмножества: вопросы без ответа в базе (правильное поведение — эскалация), вопросы с опечатками, вопросы на другом языке.
• Retrieval: recall@5 и MRR по размеченным статьям. Генерация: faithfulness (каждое утверждение подкреплено цитатой), answer relevance, корректность цитат. Судья — LLM, откалиброванный на 100 размеченных людьми примерах (согласие ≥ 85%).
• Изоляция: отдельный тест-набор, где вопрос тенанта A пересекается с документами тенанта B; ожидаемая утечка ровно ноль, тест в CI.
• Online: доля решённых без эскалации, повторные обращения в течение 24 ч (скрытая нерешённость), 👍/👎, выборочная разметка 1% диалогов.

Режимы отказов

Масштабирование

×10 по сообщениям — в первую очередь rate limits провайдера и стоимость: переговоры о тирах, распределение по двум провайдерам через gateway, кэш ответов на частые вопросы (в поддержке 20–30% вопросов повторяются почти дословно). ×10 по документам — векторный индекс перестаёт влезать в один Postgres: партиции по тенантам на нескольких инстансах или выделенная векторная БД. Ingest масштабируется горизонтально воркерами из очереди, как любой ETL.

Что спросит интервьюер

• Как гарантируете, что тенант A не увидит данные тенанта B? — фильтр в запросе к индексу, который формирует код из аутентифицированного контекста, а не модель; тест на утечку в CI; RLS в Postgres как второй рубеж.
• Как решаете, когда эскалировать? — порог по rerank-скору, явные намерения, сентимент; порог калибруем по кривой «доля автоответов vs доля ошибок» на golden set.
• Как обновить промпт, не сломав 2 000 клиентов? — версия промпта в конфиге, прогон golden set в CI, канареечный rollout на 5% тенантов, сравнение онлайн-метрик.
• Клиент удалил статью. Когда бот перестанет её цитировать? — удаление по webhook синхронно помечает чанки, фильтр deleted_at IS NULL; кэш ответов инвалидируется по id документа.

Разбор 2. Семантический поиск по миллионам документов

Постановка: «Юридическая или медиа-компания: 10M документов, нужен поиск по смыслу с фильтрами, для внутренних пользователей и API партнёров».

Требования и цифры

Расчёт на салфетке

Архитектура

Два независимых пути. Индексация: события о новых и изменённых документах → очередь → воркеры: парсинг, чанкинг с учётом структуры (разделы, статьи закона), эмбеддинг батчами, запись в векторный индекс и в BM25-индекс, метаданные и ACL в документное хранилище. Поиск: нормализация запроса, эмбеддинг (с кэшем), параллельно ANN по всем шардам с pre-filter по метаданным и ACL и BM25, слияние через RRF (Reciprocal Rank Fusion), rerank top-50 cross-encoder'ом, гидратация документов и финальная проверка ACL.

Ключевые решения и альтернативы

Evals

• Размеченный набор 500–1 000 запросов с оценками релевантности (0–3) от экспертов; метрики nDCG@10, recall@50 (важен для rerank), MRR.
• Отдельно измерять ANN-recall: доля истинных top-10 (по точному перебору) в ответе HNSW. Это метрика инфраструктуры, она ловит «подкрутили ef_search и потеряли качество».
• LLM-judge для масштабирования разметки: судья оценивает релевантность пары запрос–документ, калибруется по экспертам.
• Online: CTR на позициях, reformulation rate (пользователь переформулировал запрос), время до клика, A/B против старого поиска.

Режимы отказов

Масштабирование

Память растёт линейно с N, поэтому рычаги по порядку: квантизация (×4–32), уменьшение размерности (Matryoshka-эмбеддинги позволяют обрезать вектор), tiering (горячие данные в RAM, архив на SSD через DiskANN или binary + rescoring), шардирование. QPS масштабируется репликами. Rerank выносится в отдельный пул GPU с батчингом запросов.

Что спросит интервьюер

• Сколько памяти нужно и почему? — посчитать N × d × 4 плюс граф, предложить квантизацию, назвать цену в recall.
• Как выбираете ef_search? — по кривой recall/латентность на eval-наборе, фиксируем минимальный ef, дающий ANN-recall ≥ 0.95.
• Как меняете эмбеддинг-модель без даунтайма? — новый индекс, backfill, shadow-трафик, сравнение метрик, переключение алиаса.
• Зачем rerank, если есть хорошие эмбеддинги? — bi-encoder сжимает документ в один вектор до запроса, cross-encoder видит пару целиком и точнее; на top-50 это +5–15% nDCG ценой 50–200 мс.

Разбор 3. Text-to-SQL агент

Постановка: «Аналитики и менеджеры хотят задавать вопросы к хранилищу данных на естественном языке: “какая выручка по регионам за прошлый квартал без возвратов?”».

Требования и цифры

Расчёт на салфетке

Архитектура

Агент в цикле tool use с узким набором инструментов: search_tables(query) ищет по каталогу схемы (описания таблиц и колонок, примеры запросов, бизнес-глоссарий: что такое «выручка» и «активный клиент»), describe_table(name) отдаёт колонки и 3 примера строк, run_sql(sql) исполняет. Всё, что возвращает run_sql, проходит валидатор и исполнитель, которые живут в коде, а не в промпте.

// Исполнитель SQL от агента: read-only транзакция, таймаут, EXPLAIN-гейт, лимит строк.
// Парсинг AST (JSqlParser) и allowlist функций выполняются до вызова run.
package sqlexec;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import javax.sql.DataSource;

public final class Executor {
    public static final class TooExpensiveException extends SQLException {
        TooExpensiveException(double cost, double max) {
            super("query plan too expensive: %.0f > %.0f".formatted(cost, max));
        }
    }

    private static final ObjectMapper JSON = new ObjectMapper();

    private final DataSource db; // пул к read-only реплике, роль без прав на запись
    private final double maxCost;
    private final int maxRows;

    public Executor(DataSource db, double maxCost, int maxRows) {
        this.db = db;
        this.maxCost = maxCost;
        this.maxRows = maxRows;
    }

    /**
     * Возвращает не больше maxRows строк, уже прочитанных в память: соединение не утекает к вызывающему.
     * userRole берётся из аутентификации (не от модели) и проверен по allowlist ролей.
     * SQLException (синтаксис, права, дорогой план) уходит агенту как is_error.
     */
    public List<Map<String, Object>> run(String userRole, String query) throws SQLException {
        try (Connection c = db.getConnection()) {
            c.setReadOnly(true);
            c.setAutoCommit(false);
            try (Statement st = c.createStatement()) {
                st.setQueryTimeout(15); // секунды, на каждый statement
                st.execute("SET LOCAL statement_timeout = '10s'");
                st.execute("SET LOCAL ROLE \"" + userRole + "\""); // RLS применится к роли пользователя

                double cost = planCost(st, query);
                if (cost > maxCost) {
                    throw new TooExpensiveException(cost, maxCost);
                }

                List<Map<String, Object>> out = new ArrayList<>();
                try (ResultSet rs = st.executeQuery("SELECT * FROM (" + query + ") q LIMIT " + maxRows)) {
                    ResultSetMetaData md = rs.getMetaData();
                    while (rs.next()) {
                        Map<String, Object> row = new LinkedHashMap<>();
                        for (int i = 1; i <= md.getColumnCount(); i++) {
                            row.put(md.getColumnLabel(i), rs.getObject(i));
                        }
                        out.add(row);
                    }
                }
                return out;
            } finally {
                c.rollback(); // только чтение: всегда откат
            }
        }
    }

    private static double planCost(Statement st, String query) throws SQLException {
        try (ResultSet rs = st.executeQuery("EXPLAIN (FORMAT JSON) " + query)) {
            if (!rs.next()) throw new SQLException("explain: empty result");
            double cost = JSON.readTree(rs.getString(1)).path(0).path("Plan").path("Total Cost").asDouble(Double.NaN);
            if (Double.isNaN(cost)) throw new SQLException("explain parse: no Total Cost");
            return cost;
        } catch (JsonProcessingException e) {
            throw new SQLException("explain parse", e);
        }
    }
}

// Исполнитель SQL от агента: read-only транзакция, таймаут, EXPLAIN-гейт, лимит строк.
// Парсинг AST (pg_query_go) и allowlist функций выполняются до вызова Run.
package sqlexec

import (
	"context"
	"database/sql"
	"encoding/json"
	"errors"
	"fmt"
	"time"
)

var ErrTooExpensive = errors.New("query plan too expensive")

type Executor struct {
	DB      *sql.DB // пул к read-only реплике, роль без прав на запись
	MaxCost float64
	MaxRows int
}

// Run возвращает строки и close, который вызывающий обязан вызвать после чтения.
// userRole берётся из аутентификации (не от модели) и проверен по allowlist ролей.
func (e *Executor) Run(ctx context.Context, userRole, query string) (*sql.Rows, func(), error) {
	ctx, cancel := context.WithTimeout(ctx, 15*time.Second)
	tx, err := e.DB.BeginTx(ctx, &sql.TxOptions{ReadOnly: true})
	if err != nil {
		cancel()
		return nil, nil, fmt.Errorf("begin: %w", err)
	}
	closeFn := func() { _ = tx.Rollback(); cancel() } // только чтение: всегда откат
	fail := func(err error) (*sql.Rows, func(), error) { closeFn(); return nil, nil, err }

	for _, stmt := range []string{
		"SET LOCAL statement_timeout = '10s'",
		fmt.Sprintf(`SET LOCAL ROLE "%s"`, userRole), // RLS применится к роли пользователя
	} {
		if _, err := tx.ExecContext(ctx, stmt); err != nil {
			return fail(fmt.Errorf("%s: %w", stmt, err))
		}
	}

	var raw string
	if err := tx.QueryRowContext(ctx, "EXPLAIN (FORMAT JSON) "+query).Scan(&raw); err != nil {
		return fail(fmt.Errorf("explain: %w", err)) // синтаксис/права → агенту как is_error
	}
	var plan []struct {
		Plan struct {
			TotalCost float64 `json:"Total Cost"`
		}
	}
	if err := json.Unmarshal([]byte(raw), &plan); err != nil || len(plan) == 0 {
		return fail(fmt.Errorf("explain parse: %v", err))
	}
	if c := plan[0].Plan.TotalCost; c > e.MaxCost {
		return fail(fmt.Errorf("%w: %.0f > %.0f", ErrTooExpensive, c, e.MaxCost))
	}

	rows, err := tx.QueryContext(ctx, fmt.Sprintf("SELECT * FROM (%s) q LIMIT %d", query, e.MaxRows))
	if err != nil {
		return fail(err)
	}
	return rows, func() { rows.Close(); closeFn() }, nil
}

Текст ошибки (синтаксис, нет прав, слишком дорогой план) возвращается агенту как tool_result с is_error: true, и он пробует исправить запрос. Важна идея: все ограничения выражены в коде и БД, модель их не видит и не может обойти.

Ключевые решения и альтернативы

Evals по выполнению

• Execution accuracy: для каждого вопроса golden set есть эталонный SQL; сравнивается не текст запроса, а результат выполнения (мультимножество строк, с допуском на порядок и округление). Разные SQL могут давать верный ответ.
• Golden set из реальных вопросов с эталонами от аналитиков, 200–500 штук, с тегами сложности (одна таблица, JOIN, окна, даты «прошлый квартал»).
• Отдельные наборы: вопросы, на которые нельзя ответить (нет данных) — ожидается честный отказ; вопросы к запрещённым таблицам — ожидается отказ, а не обход.
• Adversarial: «удали таблицу», «покажи зарплаты всех», инъекции в значениях данных (строка в таблице с текстом-инструкцией).
• Online: доля запросов с ошибкой выполнения, число шагов, доля, где пользователь поправил SQL вручную.

Режимы отказов

Масштабирование

Рост пользователей упирается в БД раньше, чем в LLM: кэш результатов по нормализованному SQL и версии данных, материализованные витрины для частых вопросов, лимит конкурентности на пользователя. Рост схемы решается качеством каталога: описания колонок, примеры запросов (few-shot из лога успешных запросов) и семантический слой.

Что спросит интервьюер

• Что если модель сгенерирует DELETE? — не исполнится на четырёх уровнях: AST allowlist, read-only транзакция, роль без прав, реплика.
• Как понять, что ответ правильный? — execution accuracy в offline, показ SQL пользователю, sanity-проверки, фидбек.
• Почему не fine-tuning на парах вопрос–SQL? — схема меняется, retrieval по каталогу и few-shot из лога дают большую часть выигрыша; fine-tuning имеет смысл на стабильной схеме и большом объёме ради цены и латентности.

Разбор 4. Суммаризация звонков и тикетов

Постановка: «Колл-центр: после каждого звонка и по закрытию тикета нужно краткое резюме, причина обращения, итог, следующие шаги и оценка тональности, всё в CRM».

Требования и цифры

Расчёт на салфетке

Архитектура

Полностью асинхронный конвейер: аудио в объектное хранилище, событие в очередь, ASR с диаризацией (кто говорит: оператор или клиент), PII-редакция на тексте (NER + регулярки для карт и телефонов, проверка Луна для номеров карт), затем LLM-суммаризация через Batch API со structured output по JSON Schema, валидация, запись в CRM. «Горячие» звонки (детектор ключевых слов или эскалация оператором) идут в обычный синхронный API с приоритетом.

# Отправка пачки транскриптов в Batch API со структурированным выводом.
import anthropic, json

client = anthropic.Anthropic()

SUMMARY_SCHEMA = {
    "type": "object",
    "properties": {
        "reason": {"type": "string"},
        "outcome": {"type": "string", "enum": ["resolved", "follow_up", "escalated", "unresolved"]},
        "next_steps": {"type": "array", "items": {"type": "string"}},
        "promises": {"type": "array", "items": {"type": "object", "properties": {
            "text": {"type": "string"}, "quote_ts": {"type": "string"}},
            "required": ["text", "quote_ts"], "additionalProperties": False}},
        "sentiment": {"type": "string", "enum": ["negative", "neutral", "positive"]},
    },
    "required": ["reason", "outcome", "next_steps", "promises", "sentiment"],
    "additionalProperties": False,
}

def submit(calls):  # calls: [{"id": ..., "transcript": ...}], PII уже вырезаны
    reqs = [{
        "custom_id": c["id"],
        "params": {
            "model": "claude-haiku-4-5",
            "max_tokens": 1024,
            "system": [{"type": "text", "text": SYSTEM_PROMPT,
                        "cache_control": {"type": "ephemeral"}}],
            "messages": [{"role": "user",
                          "content": f"<transcript>\n{c['transcript']}\n</transcript>"}],
            "output_config": {"format": {"type": "json_schema", "schema": SUMMARY_SCHEMA}},
        },
    } for c in calls]
    return client.messages.batches.create(requests=reqs).id

def collect(batch_id):
    b = client.messages.batches.retrieve(batch_id)
    if b.processing_status != "ended":
        return None
    out, failed = {}, []
    for r in client.messages.batches.results(batch_id):  # порядок произвольный
        if r.result.type == "succeeded":
            out[r.custom_id] = json.loads(r.result.message.content[0].text)
        else:
            failed.append(r.custom_id)  # errored/expired → повторная отправка
    return out, failed

Ключевые решения и альтернативы

Evals

• Супервайзеры размечают 300 звонков: эталонные поля и оценка «пригодно без правки». Это основа и калибровка для судьи.
• Автоматические проверки на каждом резюме: валидность схемы (всегда 100% при structured output), каждая quote_ts существует и текст рядом совпадает по смыслу, нет PII на выходе.
• LLM-judge на faithfulness: каждое утверждение резюме подкреплено транскриптом. Судья сильнее генератора (Sonnet или Opus при генерации на Haiku), прогон на 1% выборке ежедневно.
• Качество ASR отдельно: WER на размеченном наборе, особенно на терминах компании. Плохой ASR — главный источник «галлюцинаций» суммаризатора.

Режимы отказов

Масштабирование

Конвейер масштабируется как любой ETL: партиции очереди, пул воркеров, backpressure. Узкие места по порядку: GPU для ASR, лимиты batch-очереди провайдера, запись в CRM (у внешних CRM бывают жёсткие API-лимиты — нужна своя очередь и батчинг записей).

Что спросит интервьюер

• Почему batch, а не стриминг? — никто не ждёт интерактивно, −50% цены и нет конкуренции за синхронные лимиты.
• Как не выдумать обещание? — обязательная цитата с таймкодом, программная проверка, faithfulness-judge.
• Звонок на 3 часа? — map-reduce по сегментам с перекрытием, финальный шаг получает сегментные резюме и ключевые цитаты.

Разбор 5. LLM-gateway для компании

Постановка: «В компании 40 команд используют LLM напрямую, каждая со своими ключами. Нужен единый шлюз: контроль расходов, безопасность, наблюдаемость, возможность менять провайдеров».

Требования и цифры

Расчёт на салфетке

Архитектура

Stateless-прокси на GoJava (Spring Boot на virtual threads или WebFlux) за балансировщиком. Цепочка middleware на запрос: аутентификация виртуального ключа → определение команды и политики → квоты и rate limit (Redis, token bucket) → классификация данных и PII-маскирование → кэш (точный по хэшу нормализованного запроса, семантический опционально и только для явно разрешённых маршрутов) → роутер (выбор модели и провайдера по политике, fallback, circuit breaker на провайдера) → проксирование со стримингом → подсчёт токенов из usage → асинхронная запись аудита и биллинга в Kafka.

// Middleware шлюза (Spring Boot, servlet-стек на virtual threads):
// ключ → команда → квота → проксирование → учёт токенов.
package gateway;

import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.time.Instant;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.Callable;
import java.util.function.DoubleConsumer;
import org.springframework.web.filter.OncePerRequestFilter;

public final class Gateway {
    public record Team(String id, double monthlyBudget /* $ */, int rpm) {}

    public record Usage(int in, int out, double costUsd) {}

    public record AuditEvent(String team, String model, String requestId,
                             int inTok, int outTok, double costUsd, Instant at) {}

    public interface Keys { Team lookup(String key); } // null — ключ неизвестен

    /** Возвращает release(actualUsd); бросает BudgetExceededException, если бюджет исчерпан. */
    public interface Quota { DoubleConsumer reserve(String team, double usd); }

    public interface Limit { boolean allow(String team, int rpm); }

    public static final class AuthFilter extends OncePerRequestFilter {
        private final Keys keys;
        private final Limit limit;

        public AuthFilter(Keys keys, Limit limit) {
            this.keys = keys;
            this.limit = limit;
        }

        @Override
        protected void doFilterInternal(HttpServletRequest req, HttpServletResponse resp, FilterChain chain)
                throws ServletException, IOException {
            Team team = keys.lookup(req.getHeader("x-api-key"));
            if (team == null) {
                error(resp, HttpServletResponse.SC_UNAUTHORIZED, "invalid key");
                return;
            }
            if (!limit.allow(team.id(), team.rpm())) {
                resp.setHeader("retry-after", "1");
                error(resp, 429, "rate limited");
                return;
            }
            req.setAttribute(Team.class.getName(), team);
            chain.doFilter(req, resp);
        }

        private static void error(HttpServletResponse resp, int status, String msg) throws IOException {
            resp.setStatus(status);
            resp.setContentType("application/json");
            resp.getWriter().write("{\"error\":\"" + msg + "\"}");
        }
    }

    public static final class BudgetGuard {
        private final Quota quota;
        // Ограниченная очередь → Kafka; при переполнении пишем в локальный WAL.
        private final BlockingQueue<AuditEvent> audit;

        public BudgetGuard(Quota quota, BlockingQueue<AuditEvent> audit) {
            this.quota = quota;
            this.audit = audit;
        }

        // Бюджет резервируется по худшему случаю (max_tokens × цена выхода),
        // после ответа резерв корректируется до фактической стоимости из usage.
        public Usage withBudget(Team team, double worstUsd, Callable<Usage> call) throws Exception {
            DoubleConsumer release = quota.reserve(team.id(), worstUsd); // исчерпан → 402/429 с понятным сообщением
            Usage u = new Usage(0, 0, 0);
            try {
                u = call.call();
                return u;
            } finally {
                release.accept(u.costUsd()); // при ошибке cost = 0 или фактически списанное провайдером
                // offer не блокирует запрос из-за аудита; false → метрика dropped + WAL
                audit.offer(new AuditEvent(team.id(), null, null, u.in(), u.out(), u.costUsd(), Instant.now()));
            }
        }
    }
}

// Middleware шлюза: ключ → команда → квота → проксирование → учёт токенов.
package gateway

import (
	"context"
	"net/http"
	"time"
)

type Team struct {
	ID            string
	MonthlyBudget float64 // $
	RPM           int
}

type Deps struct {
	Keys   interface{ Lookup(ctx context.Context, key string) (*Team, error) }
	Quota  interface{ Reserve(ctx context.Context, team string, usd float64) (release func(actual float64), err error) }
	Limit  interface{ Allow(ctx context.Context, team string, rpm int) bool }
	Audit  chan<- AuditEvent // буферизованный канал → Kafka; при переполнении пишем в локальный WAL
}

type AuditEvent struct {
	Team, Model, RequestID string
	InTok, OutTok          int
	CostUSD                float64
	At                     time.Time
}

func (d *Deps) Auth(next func(http.ResponseWriter, *http.Request, *Team)) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		team, err := d.Keys.Lookup(r.Context(), r.Header.Get("x-api-key"))
		if err != nil || team == nil {
			http.Error(w, `{"error":"invalid key"}`, http.StatusUnauthorized)
			return
		}
		if !d.Limit.Allow(r.Context(), team.ID, team.RPM) {
			w.Header().Set("retry-after", "1")
			http.Error(w, `{"error":"rate limited"}`, http.StatusTooManyRequests)
			return
		}
		next(w, r, team)
	}
}

// Бюджет резервируется по худшему случаю (max_tokens × цена выхода),
// после ответа резерв корректируется до фактической стоимости из usage.
func (d *Deps) WithBudget(ctx context.Context, team *Team, worstUSD float64,
	call func(ctx context.Context) (in, out int, cost float64, err error)) error {
	release, err := d.Quota.Reserve(ctx, team.ID, worstUSD)
	if err != nil {
		return err // бюджет исчерпан → 402/429 с понятным сообщением
	}
	in, out, cost, err := call(ctx)
	release(cost) // при ошибке cost = 0 или фактически списанное провайдером
	select {
	case d.Audit <- AuditEvent{Team: team.ID, InTok: in, OutTok: out, CostUSD: cost, At: time.Now()}:
	default: // не блокируем запрос из-за аудита; метрика dropped + WAL
	}
	return err
}

Ключевые решения и альтернативы

Evals и проверки

Шлюз сам не генерирует, но отвечает за то, чтобы переключение моделей не ломало продукты. Поэтому: каждая команда регистрирует свой eval-набор, и смена маршрута по умолчанию (новая модель, новый провайдер для fallback) прогоняет эти наборы. Для самого шлюза — нагрузочные тесты на overhead, chaos-тесты (провайдер отвечает 529, рвёт стрим посередине, отдаёт 30 с TTFT), тесты на маскирование PII с набором реальных форматов.

Режимы отказов

Масштабирование

Прокси масштабируется горизонтально, узкое место — лимиты провайдеров. Решения: пул ключей и организаций у провайдера, распределение по регионам и провайдерам, приоритеты (интерактивный трафик вытесняет фоновый), перевод офлайн-задач команд на Batch API через шлюз. Биллинг: события в Kafka → агрегаты в ClickHouse → дашборды и showback/chargeback по командам.

Что спросит интервьюер

• Как считаете токены в стриме? — из usage в message_start и message_delta; при обрыве — по доле полученного и последующей сверке с отчётами провайдера.
• Что если Redis с квотами недоступен? — локальные лимиты на узле как приближение, fail-open с алертом; бюджеты сверяются постфактум.
• Как дать командам свободу, но не потерять контроль? — политики по умолчанию, override через ревью, showback по расходам, eval-гейт на смену модели.
• Зачем свой шлюз, если есть готовые? — честный ответ: начать с готового; свой, когда требования к комплаенсу, латентности или интеграции с внутренней биллинговой системой перевешивают.

Разбор 6. Ассистент банка с действиями: security-first

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

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

Требования и цифры

Расчёт на салфетке

Пресет «Банк-агент» в калькуляторе выше считает вариант «всё на Sonnet 5 с кэшем» (≈ $70K/мес); роутинг на Haiku снимает ещё 15–20%. Деньги здесь не главная проблема: даже «в лоб» $0.05 за диалог несопоставимо меньше $3–6 за обращение к живому оператору (Разбор 1). Главные затраты — это инженерия безопасности: policy engine, экраны подтверждения, red-team и аудит. Именно их стоит назвать на интервью, когда спросят «что самое дорогое в этой системе».

Архитектура

Сессия приложения (клиент уже аутентифицирован, устройство привязано) → API с rate limit на клиента → входные guardrails (классификатор инъекций, сигналы социальной инженерии, маскирование PII для логов) → роутер намерений на Haiku 4.5 (вопрос о продукте, вопрос об операциях, действие, жалоба, «меня просят перевести деньги») → ассистент на Sonnet 5 с инструментами. Инструменты чтения (счета, операции, статус карты) вызывают core banking с токеном сессии клиента. Инструменты действий ничего не исполняют: они создают объект Proposal. Дальше работает детерминированный код. Policy engine решает, допустимо ли действие. Приложение показывает нативный экран подтверждения, собранный из полей Proposal, а не из текста модели. Для денежных операций клиент вводит PIN или проходит биометрию. Исполнитель вызывает core banking с ключом идемпотентности. Каждое предложение, решение политики и исполнение пишется в неизменяемый аудит.

// Политика действий ассистента: модель предлагает, код решает (imports опущены).
public final class Actions {
    private Actions() {}

    public static final String OWN_TRANSFER = "own_transfer";     // между своими счетами
    public static final String TEMPLATE_PAY = "template_payment"; // по сохранённому шаблону
    public static final String CARD_BLOCK = "card_block";

    /**
     * Собирается из аргументов tool_use: каждое поле — недоверенные данные.
     * kind — строка, а не enum: модель может прислать что угодно, и это надо отклонить, а не упасть.
     */
    public record Proposal(String kind, String from, String to, String template, String card,
                           long amountKop) { // деньги в копейках, без double

        /**
         * Привязывает подтверждение к сумме и получателю, как dynamic linking в SCA:
         * изменилось любое поле — подтверждение недействительно.
         * Каноничная сериализация: длина + значение, чтобы "a|b"+"c" не совпало с "a"+"b|c".
         */
        public String digest() {
            StringBuilder b = new StringBuilder();
            for (String f : new String[] {kind, from, to, template, card, Long.toString(amountKop)}) {
                String v = f == null ? "" : f;
                b.append(v.length()).append(':').append(v).append(';');
            }
            try {
                return HexFormat.of().formatHex(
                        MessageDigest.getInstance("SHA-256").digest(b.toString().getBytes(StandardCharsets.UTF_8)));
            } catch (NoSuchAlgorithmException e) {
                throw new IllegalStateException(e);
            }
        }
    }

    /** То, что банк знает о клиенте из core banking по его сессии, а не со слов модели. */
    public record Client(Set<String> accounts, Set<String> templates, Set<String> cards, long spentTodayKop) {}

    public record Limits(long perOpKop, long dailyKop, long stepUpKop) {}

    public enum Verdict {
        DENY,
        CONFIRM, // подтверждение на нативном экране приложения
        STEP_UP  // подтверждение + PIN или биометрия
    }

    /** reason уходит модели как tool_result, чтобы она объяснила клиенту. */
    public record Decision(Verdict verdict, String reason) {}

    private static Decision deny(String reason) { return new Decision(Verdict.DENY, reason); }

    /** Детерминированная политика: никаких вызовов модели внутри. */
    public static Decision authorize(Client c, Limits l, Proposal p) {
        switch (String.valueOf(p.kind())) {
            case CARD_BLOCK -> {
                if (!c.cards().contains(p.card())) return deny("карта не принадлежит клиенту");
                return new Decision(Verdict.CONFIRM, "блокировка карты");
            }
            case OWN_TRANSFER -> {
                if (!c.accounts().contains(p.from()) || !c.accounts().contains(p.to()) || p.from().equals(p.to())) {
                    return deny("перевод возможен только между разными своими счетами");
                }
            }
            case TEMPLATE_PAY -> {
                if (!c.accounts().contains(p.from()) || !c.templates().contains(p.template())) {
                    return deny("у клиента нет такого счёта или шаблона");
                }
            }
            default -> {
                return deny("действие \"%s\" ассистенту недоступно".formatted(p.kind()));
            }
        }
        if (p.amountKop() <= 0) return deny("сумма должна быть положительной");
        if (p.amountKop() > l.perOpKop()) return deny("превышен лимит на операцию");
        if (c.spentTodayKop() + p.amountKop() > l.dailyKop()) return deny("превышен дневной лимит");
        if (p.amountKop() >= l.stepUpKop()) return new Decision(Verdict.STEP_UP, "крупная сумма");
        return new Decision(Verdict.CONFIRM, "в пределах лимитов");
    }

    /** Приходит с нативного экрана приложения после действия клиента, а не из чата. */
    public record Confirmation(String digest, String id /* уникален для каждого подтверждения */, boolean steppedUp) {}

    public interface Core {
        void execute(String idempotencyKey, Proposal p);
    }

    public static final class DeniedException extends RuntimeException {
        public DeniedException(String reason) { super("отказ: " + reason); }
    }

    public static final class NotConfirmedException extends RuntimeException {
        public NotConfirmedException() { super("подтверждение не совпадает с предложением"); }
    }

    public static void execute(Core core, Client c, Limits l, Proposal p, Confirmation conf) {
        Decision d = authorize(c, l, p); // повторно: с момента предложения могли измениться лимиты
        if (d.verdict() == Verdict.DENY) throw new DeniedException(d.reason());
        if (!p.digest().equals(conf.digest()) || (d.verdict() == Verdict.STEP_UP && !conf.steppedUp())) {
            throw new NotConfirmedException();
        }
        core.execute(conf.id(), p); // ретрай с тем же ID не исполнит операцию дважды
    }
}

// Политика действий ассистента: модель предлагает, код решает (imports опущены).
type Kind string

const (
	OwnTransfer Kind = "own_transfer"     // между своими счетами
	TemplatePay Kind = "template_payment" // по сохранённому шаблону
	CardBlock   Kind = "card_block"
)

// Proposal собирается из аргументов tool_use: каждое поле — недоверенные данные.
type Proposal struct {
	Kind      Kind   `json:"kind"`
	From      string `json:"from,omitempty"`
	To        string `json:"to,omitempty"` // для own_transfer
	Template  string `json:"template,omitempty"`
	Card      string `json:"card,omitempty"`
	AmountKop int64  `json:"amount_kop,omitempty"` // деньги в копейках, без float
}

// Client — то, что банк знает о клиенте из core banking по его сессии, а не со слов модели.
type Client struct {
	Accounts, Templates, Cards map[string]bool
	SpentTodayKop              int64
}

type Limits struct{ PerOpKop, DailyKop, StepUpKop int64 }

type Verdict int

const (
	Deny    Verdict = iota
	Confirm         // подтверждение на нативном экране приложения
	StepUp          // подтверждение + PIN или биометрия
)

type Decision struct {
	Verdict Verdict
	Reason  string // уходит модели как tool_result, чтобы она объяснила клиенту
}

func deny(reason string) Decision { return Decision{Deny, reason} }

// Authorize — детерминированная политика: никаких вызовов модели внутри.
func Authorize(c Client, l Limits, p Proposal) Decision {
	switch p.Kind {
	case CardBlock:
		if !c.Cards[p.Card] {
			return deny("карта не принадлежит клиенту")
		}
		return Decision{Confirm, "блокировка карты"}
	case OwnTransfer:
		if !c.Accounts[p.From] || !c.Accounts[p.To] || p.From == p.To {
			return deny("перевод возможен только между разными своими счетами")
		}
	case TemplatePay:
		if !c.Accounts[p.From] || !c.Templates[p.Template] {
			return deny("у клиента нет такого счёта или шаблона")
		}
	default:
		return deny(fmt.Sprintf("действие %q ассистенту недоступно", p.Kind))
	}
	switch {
	case p.AmountKop <= 0:
		return deny("сумма должна быть положительной")
	case p.AmountKop > l.PerOpKop:
		return deny("превышен лимит на операцию")
	case c.SpentTodayKop+p.AmountKop > l.DailyKop:
		return deny("превышен дневной лимит")
	case p.AmountKop >= l.StepUpKop:
		return Decision{StepUp, "крупная сумма"}
	}
	return Decision{Confirm, "в пределах лимитов"}
}

// Digest привязывает подтверждение к сумме и получателю, как dynamic linking в SCA:
// изменилось любое поле — подтверждение недействительно.
func (p Proposal) Digest() string {
	b, _ := json.Marshal(p) // порядок полей структуры фиксирован
	h := sha256.Sum256(b)
	return hex.EncodeToString(h[:])
}

// Confirmation приходит с нативного экрана приложения после действия клиента, а не из чата.
type Confirmation struct {
	Digest    string
	ID        string // уникален для каждого подтверждения
	SteppedUp bool
}

type Core interface {
	Execute(ctx context.Context, idempotencyKey string, p Proposal) error
}

var ErrNotConfirmed = errors.New("подтверждение не совпадает с предложением")

func Execute(ctx context.Context, core Core, c Client, l Limits, p Proposal, conf Confirmation) error {
	d := Authorize(c, l, p) // повторно: с момента предложения могли измениться лимиты
	if d.Verdict == Deny {
		return fmt.Errorf("отказ: %s", d.Reason)
	}
	if conf.Digest != p.Digest() || (d.Verdict == StepUp && !conf.SteppedUp) {
		return ErrNotConfirmed
	}
	return core.Execute(ctx, conf.ID, p) // ретрай с тем же ID не исполнит операцию дважды
}

Причина отказа возвращается модели как tool_result, и она объясняет клиенту, что можно сделать, например «перевод новому получателю — в разделе “Платежи”». Полная версия с тестами лежит в examples/m12-system-designexamples/java/m12-system-design: таблица случаев для политики, подмена суммы после подтверждения, крупная сумма без step-up. Политика — обычный код, поэтому её тестируют как обычный код, со 100% покрытием правил.

Ключевые решения и альтернативы

Evals и red-team

• Информационные ответы: golden set из 500 реальных обращений по продуктам и операциям, faithfulness и корректность цифр, судья откалиброван по разметке сотрудников поддержки.
• Извлечение параметров действия: 300 диалогов с эталонным Proposal или эталонным «переспросить». Суммы прописью, с валютой, «половину остатка», «как в прошлый раз». Метрика — точное совпадение. Цель — 100%: всё неоднозначное должно уходить в уточнение.
• Траектории (модуль 8): нужные инструменты чтения, ни одного предложения действия без запроса клиента, никаких повторных предложений после отказа.
• Red-team (модуль 7): 300+ атак. Инъекции через назначения платежей и имена получателей, социальная инженерия, попытка сменить получателя после подтверждения, вопросы о чужих счетах, обход лимитов дроблением суммы. Гейт в CI — ноль исполненных несанкционированных действий и ноль утечек чужих данных. При 0 успехах из 300 верхняя граница 95%-интервала по правилу трёх ≈ 3/300 = 1%. Поэтому безопасность обеспечивает архитектура, а red-team проверяет, что она работает.
• Online: доля принятых предложений (низкая — модель предлагает не то), отказы на step-up, жалобы, сигналы антифрода, эскалации к оператору.

Режимы отказов

Масштабирование

×10 по сообщениям — сначала rate limits провайдера и стоимость (роутинг, кэш ответов на частые продуктовые вопросы), затем лимиты API core banking: инструменты чтения кэшируют остатки и выписку на секунды и уважают квоты бэкенда. ×10 по видам действий опаснее, чем ×10 по трафику: каждое новое действие — новая строка в модели угроз, новые правила политики, новые атаки в red-team наборе и ревью безопасности. Поэтому новые действия добавляются по одному, за флагом, с ADR и отдельным релизом.

Что спросит интервьюер

• Что, если модель решит перевести деньги сама? — Не сможет: инструмент только создаёт предложение. Исполнение требует подтверждения клиента на нативном экране, код подтверждения привязан к хэшу суммы и получателя, а политика разрешает только свои счета и шаблоны.
• Почему не разрешить переводы новым получателям? — Это лишняя функциональность и главный вектор мошенничества. Если бизнес требует, то лимит на первый перевод, период охлаждения, step-up и антифрод. Решение фиксируется в ADR, а потери от мошенничества становятся guardrail-метрикой.
• Как доказать службе безопасности, что защита работает? — Модель угроз, тесты политики, red-team с ASR и гейтом в CI, аудит, внешний пентест. И честно про правило трёх: ноль успешных атак из 300 не означает нулевого риска. Поэтому система должна оставаться безопасной даже при успешной инъекции.
• Нужен ли здесь агент? — Для действий нет, нужен workflow с фиксированными шагами. Модель помогает понять намерение и заполнить параметры, а решения принимает код.

Observability для всех кейсов

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

• Трейс на запрос (OpenTelemetry, атрибуты gen_ai.*): спаны retrieval, rerank, каждого вызова модели и инструмента; модель, версия промпта, токены вход/выход/кэш, стоимость, stop_reason, id найденных документов.
• Метрики: TTFT и полная латентность p50/p95/p99 по маршрутам, доля ошибок по типам (429, 5xx, таймаут, refusal, невалидный вывод), $ в час по фичам и командам, доля cache read.
• Качество в проде: фидбек, онлайн-judge на выборке, доля эскалаций и отказов, дрейф распределения входов (новые темы, другой язык).
• SLO и error budget: доступность, TTFT p95 и доля ответов, прошедших онлайн-проверку качества, как SLI; алерты на скорость расхода бюджета, а не на каждый всплеск (модуль 9).
• Для агентов: спан на каждый шаг и вызов инструмента, размер контекста и $ по шагам, число шагов на задачу — иначе зацикливание видно только в счёте за месяц.
• Хранение промптов и ответов с учётом PII: для отладки нужны полные тексты, для комплаенса — ограниченный доступ и сроки хранения.

Практика

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

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

Источники

• Anthropic: Building effective agents — workflows против агентов, паттерны
• Anthropic: Prompt caching
• Anthropic: Batch processing
• Anthropic: Rate limits (RPM, ITPM, OTPM)
• Anthropic: Pricing
• Malkov, Yashunin: Efficient and robust approximate nearest neighbor search using HNSW graphs
• pgvector: документация (HNSW, IVFFlat, фильтрация, квантизация)
• OpenTelemetry: Semantic conventions for generative AI
• Eugene Yan: Patterns for building LLM-based systems and products
• Chip Huyen: Building a generative AI platform
• Spider: бенчмарк text-to-SQL (execution accuracy)
• OWASP: Top 10 for LLM Applications 2026 — карта рисков для шага «Безопасность», в Разборе 6 — LLM01, LLM03, LLM02
• OWASP: LLM03:2026 Excessive Agency — лишняя функциональность, права и автономия; действия в контексте пользователя
• EUR-Lex: Регламент (ЕС) 2018/389, RTS по строгой аутентификации клиента (PSD2) — статья 5 о динамической привязке подтверждения к сумме и получателю
• Google SRE Workbook: Implementing SLOs — SLI, error budget, алерты по скорости расхода
• Michael Nygard: Documenting Architecture Decisions (2011) — исходный формат ADR