Продукт vs коробка

Модуль 2 из 9 — Позиционирование и бизнес-модель интегратора

В М1 мы разобрали, почему заземление — это доверие: бот, который знает реальный каталог, не выдумывает. Теперь следующий вопрос: что именно ты продаёшь клиенту и почему это не то же самое, что коробочный ИИ-оператор?

🎯 Что реально покупает владелец магазина

Интегратор не продаёт «чат-бота». Он продаёт решённую проблему.

⚖️ Четыре отличия от коробочных ИИ-операторов

💰 Бизнес-модель: Setup + абонентская поддержка

Правильная структура для интегратора — два компонента:

• SETUP: покрывает стоимость внедрения — не занижай, это инженерная работа
• Абонентка: обеспечивает предсказуемый cash flow и выравнивает стимулы (см. ниже)
• Не pay-per-lead: принципиально — это не просто другой прайс, это другая механика стимулов

🔬 Глубина: экономика стимулов (misalignment)

Почему pay-per-lead — это структурная проблема, а не просто «дорого»:

🧮 Калькулятор: Pay-per-lead vs абонентка

Посмотри, во сколько реально обходится качественный лид при каждой модели. Подставь свои цифры:

🏷️ Якорение цены: как позиционироваться рядом с коробкой

На рынке есть коробочные решения с понятной ценой в месяц — клиент уже знает этот порядок цифр. Это якорь. Не воюй с ним — используй его.

Ты позиционируешься не дешевле коробки, а above the anchor — done-for-you, заземлённый, с владением данными. Это другой продукт, не дорогой аналог.

❓ Quiz: проверь понимание

Архитектура harness: тонкий kernel + инстансы

Модуль 3 из 9 — поймёшь, почему «построил раз — продаёшь многим» — это не метафора, а инженерное решение.

Пайплайн: от фида до брифа

Как мы видели в M2, переиспользуемость — это производственная мощность. Начнём с того, из каких ступеней состоит пайплайн, который мы будем переиспользовать.

┌─────────────────────────────────────────────────────────────────┐
│                        HARNESS PIPELINE                         │
└─────────────────────────────────────────────────────────────────┘

  Фид каталога           catalog.json              Бриф / эскалация
  (любой источник)            │                    человеку
       │                      │                         ▲
       ▼                      ▼                         │
  ┌─────────┐         ┌──────────────┐         ┌───────────────┐
  │  INGEST │──────►  │  RETRIEVAL   │──────►  │    CONSULT    │
  └─────────┘         └──────────────┘         │   (LLM call)  │
                                               └───────┬───────┘
                                                       │
                                               ┌───────▼───────┐
                                               │     GUARD     │
                                               └───────────────┘

Ступень       Что делает
─────────────────────────────────────────────────────────────────
ingest        Нормализует сырой фид → catalog.json (единый формат)
retrieval     Детерминированно отбирает кандидатов под запрос (→ M5)
consult       LLM-вызов: grounded-ответ только по кандидатам
guard         Проверяет ответ на галлюцинации и ограничения (→ M6)
бриф          Структурированный вывод или передача оператору
─────────────────────────────────────────────────────────────────

Тонкий kernel и сменные инстансы

Ключевая идея: пайплайн работает одинаково для любого магазина. Меняется только наполнение — каталог и личность консультанта. Поэтому мы делим систему на две части.

  Клиент A ──► [ Instance A ] ──┐
  Клиент B ──► [ Instance B ] ──┤──► [ KERNEL ] ──► LLM API
  Клиент C ──► [ Instance C ] ──┘

  Новый клиент = добавить инстанс.  Kernel не трогаем.
  

Граница ядро↔persona: интерфейс-контракт

Kernel работает с инстансом через строгий контракт: набор «слотов», которые persona обязана заполнить. Kernel не знает реализацию слота — только его форму.

  instance/
  ├── catalog.json          # нормализованный список позиций
  ├── persona/
  │   ├── profile.json      # тон, имя, ограничения
  │   ├── calc.js           # СЛОТ: функция calcPower(area, region) → кВт
  │   ├── faq.json          # вопрос→ответ пары
  │   ├── promos.json       # текущие акции
  │   └── routing.json      # правила эскалации (→ оператор)
  └── widget/               # фронт-виджет

  Kernel вызывает: instance.persona.calc.calcPower(area, region)
  Kernel не знает формулу — только сигнатуру вызова.
  

Где живёт API-ключ: модель угроз

Фронт-виджет исполняется в публичном браузере покупателя. Это — самое важное ограничение безопасности в этой архитектуре.

// widget.js — ПУБЛИЧНЫЙ файл
const LLM_KEY = "sk-proj-..."; // украдут!

fetch("https://api.llm.example/...", {
  headers: { "Authorization": "Bearer " + LLM_KEY }
})
      

// widget.js — ПУБЛИЧНЫЙ
fetch("/api/consult", {
  method: "POST",
  body: JSON.stringify({ question: q })
  // ключа здесь нет
})

// server.js — ПРИВАТНЫЙ
const LLM_KEY = process.env.LLM_API_KEY;
// rate-limit + origin-check → LLM API
      

  Браузер покупателя
       │
       │  POST /api/consult  {"question": "..."}
       ▼
  ┌─────────────────────────────────┐
  │   Серверный мост (твой сервер)  │
  │   • rate-limit                  │
  │   • origin-check (CORS)         │
  │   • LLM_KEY = env.LLM_API_KEY   │
  └──────────────┬──────────────────┘
                 │  Authorization: Bearer sk-proj-...
                 ▼
           LLM API endpoint
  

Классификатор: kernel или instance?

Проверь себя — нажми на каждый компонент и узнай, куда он относится.

Проверь себя

Модульная композиция промпта

Модуль 4 из 9 · Антивинегрет: почему промпт — это система блоков, а не монолит

В M3 мы разобрали ядро kernel/persona — откуда берутся блоки base/ и persona/. Сейчас — главный вопрос сопровождения: как складывать эти блоки правильно, почему порядок имеет значение и зачем структурированный вывод вместо свободного текста.

Монолит против блоков: что идёт не так

Представьте системный промпт интернет-магазина отопления: одна стена текста на 1 500 строк — роль, правила, FAQ, таблица мощностей, акции, политика возвратов, формат ответа, эскалация. Как только магазин добавляет новую акцию, инженер ищет нужное место в этой стене. Со временем:

• Интерференция инструкций: две директивы в разных местах начинают противоречить друг другу. Модель «усредняет» их непредсказуемо.
• Lost-in-the-middle: на длинном контексте важные инструкции в середине тонут — модель больше «видит» начало и конец.
• Неподдерживаемость: для N клиентов нужны N расходящихся копий, правки не синхронизируются.

До / После: один и тот же контент

Ниже — фрагмент монолита и тот же контент, разбитый на блоки. Информация одинакова, но структура разная.

Ты — ИИ-консультант магазина отопления.
Отвечай вежливо, на русском языке.
Никогда не выдумывай цены. Если не
знаешь — говори "уточните у менеджера".
Для расчёта мощности: 1 кВт на 10 м²
при высоте потолка 2.7 м.
Рекомендуй котёл с запасом +20%.
Текущая акция: скидка 10% на монтаж
при заказе до конца месяца.
Если клиент просит возврат — переключи
на живого менеджера. Ответ давай в
формате: сначала расчёт, потом вывод,
потом вопрос клиенту. Не забудь...
(ещё 1400 строк в том же духе)

## [base/role]
Ты — ИИ-консультант магазина отопления.

## [base/guardrails]
Никогда не выдумывай цены.
Если не знаешь — "уточните у менеджера".

## [base/output_contract]
Формат: { calc, recommendation, question }

## [persona/calc]
Мощность: 1 кВт / 10 м² (потолок 2.7 м).
Запас котла: +20%.

## [persona/promos]
Скидка 10% на монтаж до конца месяца.

## [persona/routing]
Запрос на возврат → живой менеджер.

Архитектура блоков

Порядок блоков = приоритет

Порядок — не случайный. Модель «видит» начало и конец сильнее середины. Используем это осознанно:

• Guardrails — в самом начале, жёстко. Раньше всего, иначе могут быть «перебиты» поздними инструкциями.
• Role — первая строка: задаёт фрейм для всего остального.
• Output_contract — ближе к концу, прямо перед генерацией — свежо в «памяти» модели в момент вывода.
• Конфликты решай явно внутри блока: «если X противоречит guardrails — приоритет у guardrails».

Output_contract: структура вместо свободного текста

Монолитный промпт часто заканчивается чем-то вроде: «Сначала дай расчёт, потом вывод, потом задай вопрос». Это инструкция для человека. Для парсера это катастрофа:

• Модель чуть переформулировала → регэксп тихо сломался → данные потеряны
• Тесты на «золотых» примерах зелёные — они проверяют старый формат, который модель уже не генерирует
• Баг в проде, невидимый в CI (это разберём подробно в M8)

Output_contract = контракт, который провайдер помогает соблюдать через structured outputs / tool-call schema. Парсинг тривиален: JSON.parse() вместо регэкспов.

Расчёт: площадь 50 м², мощность 5 кВт.
Рекомендация: котёл 7 кВт.
Вопрос: какой тип топлива предпочтителен?

{
  "calc":   { "area": 50, "power_kw": 5 },
  "rec":    "котёл 7 кВт",
  "question": "Какой тип топлива?"
}

🔧 Конструктор промпта

Включайте и выключайте блоки — смотрите, как меняется собранный промпт, оценка токенов и предупреждения.

Token budget: не раздувай блоки

Каждый блок стоит токены. В конструкторе выше можно увидеть, как растёт бюджет. Рекомендации:

• guardrails — лаконично и жёстко, не энциклопедия
• faq — самый жирный блок; отбирай только реально частые вопросы
• calc — формулы, не примеры; примеры клиент даёт в диалоге
• Итого системный промпт: цель ≤ 800 токенов, допустимо до 1 200, выше — ревизия

Проверь себя

Модуль 5: Заземление через Retrieval

Как каталог становится словарём модели — и почему детерминированный отбор точнее нейросети

Связь с M1: заземление = сужение пространства генерации

В модуле 1 мы определили заземление как принцип: вместо того чтобы позволить модели «галлюцинировать» произвольные ответы, мы сужаем пространство допустимых генераций до того, что реально существует в нашей системе.

Retrieval — это конкретный механизм этого сужения. Перед вызовом LLM мы достаём из каталога релевантных кандидатов и передаём модели только их. Бот консультирует исключительно по переданным товарам — ничего за пределами набора он предложить не может.

Ingest: от фида до catalog.json

Перед тем как извлекать кандидатов, нужно привести данные к единой схеме. Фид может прийти из любого источника — XML выгрузка, CSV от поставщика, REST-ответ ERP. Нормализация создаёт один договор, независимо от источника.

{
  "id":      "BOIL-042",
  "name":    "Котёл газовый настенный 24 кВт",
  "price":   47900,
  "url":     "/catalog/boil-042",
  "attrs": {
    "power_kw":    24,
    "fuel":        "gas",
    "area_m2_max": 240,
    "type":        "wall",
    "circuit":     "double"
  }
}

Ingest выполняется порциями, вежливо (rate-limit, retry с backoff), результат — catalog.json, обновляемый по расписанию или по событию. LLM видит только этот нормализованный файл, а не «сырой» фид.

Детерминированный отбор кандидатов ДО LLM

Ключевой архитектурный выбор: кандидаты отбираются обычным кодом, до вызова модели. Для интернет-магазина отопления это выглядит так:

def select_candidates(area_m2: float, fuel: str, catalog: list, n: int = 10):
    # Шаг 1: расчёт требуемой мощности (норма: 1 кВт на 10 м²)
    required_kw = area_m2 / 10.0

    # Шаг 2: детерминированный фильтр по атрибутам
    filtered = [
        p for p in catalog
        if p["attrs"]["fuel"] == fuel
        and p["attrs"]["power_kw"] >= required_kw * 0.85   # -15% допуск
        and p["attrs"]["power_kw"] <= required_kw * 1.30   # +30% запас
    ]

    # Шаг 3: сортировка по цене (или по скорингу)
    filtered.sort(key=lambda p: p["price"])

    return filtered[:n]   # ← это и есть «кандидатный набор»

Почему детерминированный отбор, а не нейросеть?

• Предсказуемо — один и тот же запрос всегда даёт один и тот же набор кандидатов.
• Дёшево — фильтрация по атрибутам работает за O(n), без GPU и API-вызовов.
• Отлаживаемо — можно точно сказать, почему товар попал в набор или нет.
• Гарантирует реальность — кандидаты существуют в каталоге, у них есть цена и наличие.

Кандидатный набор = эффективный словарь LLM

После фильтрации мы передаём отобранные товары в промпт. С этого момента модель может назвать только то, что в наборе. Если товар не попал в retrieval — для бота его не существует.

Ты — консультант интернет-магазина отопления.
Клиент хочет отопить {area_m2} м² газовым котлом.
Отвечай ТОЛЬКО по товарам из списка ниже. Не придумывай другие модели.

СПИСОК ТОВАРОВ:
{json.dumps(candidates, ensure_ascii=False, indent=2)}

Вопрос клиента: {user_question}

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

📊 Трейдофф recall / precision: интерактивный график

Слишком мало кандидатов — нужный товар может не попасть в набор (промах). Слишком много — контекст раздут, модель «тонет» в нерелевантных позициях, фокус падает. Найдём баланс.

Иллюстративные кривые — для демонстрации принципа:

Детерминированный vs семантический (эмбеддинги)

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

✅ Проверь себя

Модуль 6. Runtime-гард и graceful fallback

Defense-in-depth: промпт → retrieval → ассерт → fallback. Когда бот ошибается — деградируем в ценность, не в позор.

Контекст: что уже есть и чего не хватает

В M1 мы провели границу soft/hard grounding — жёсткий слой требует машинной проверки, не веры в промпт. В M5 retrieval подаёт боту только реальных кандидатов из catalog.json. Казалось бы — достаточно?

Defense-in-depth: четыре слоя

Слой 1  ПРОМПТ-ГАРД (soft)
        «Используй только товары из каталога ниже»
        → Снижает частоту галлюцинаций. Не гарантирует.
        → Модель всё равно может «достроить» несуществующее.

Слой 2  RETRIEVAL-ОГРАНИЧЕНИЕ (M5)
        Подаём в контекст только реальных кандидатов.
        → Модель видит правду, а не весь интернет.
        → Всё ещё вероятностный: может смешать артикулы/цены.

Слой 3  RUNTIME-АССЕРТ (hard) ← ключевой слой этого модуля
        После генерации: каждый названный товар/цена
        ДОСЛОВНО проверяется в catalog.json.
        Не прошёл → блокируем ответ до ретрая/fallback.
        → Единственный слой, дающий машинную гарантию.

Слой 4  FALLBACK (graceful degradation)
        Ретрай не помог → НЕ показываем кривой ответ.
        НЕ показываем стектрейс. Вежливо → захват лида.
        → Деградируем в конверсию, не в ошибку.

Связь со спектром заземления из M1: слой 1 — это L1 (soft / промпт), слой 2 — L2 (RAG / реальные кандидаты), слой 3 — L3 (hard / ассерт). А L0 (вообще без заземления) — базовый уровень, который мы в прод не выпускаем. Defense-in-depth — это и есть «подняться по спектру и не выбросить нижние ступени, а сложить их».

Runtime-ассерт: как это выглядит в коде

После получения ответа от LLM harness парсит упомянутые товары и цены, затем сверяет их с эталоном:

def assert_response(answer: str, catalog: list[dict]) -> dict:
    """
    Упрощённый пример runtime-ассерта.
    catalog = [{"sku": "KTL-42", "name": "Котёл Альфа 24кВт", "price": 87000}, ...]
    """
    catalog_names = {item["name"].lower() for item in catalog}
    catalog_prices = {item["price"] for item in catalog}

    violations = []
    for item in catalog:
        # Если имя упомянуто — цена должна точно совпадать
        if item["name"].lower() in answer.lower():
            # Ищем цену рядом с именем товара (упрощённо)
            for price in extract_prices(answer):
                if price not in catalog_prices:
                    violations.append(f"Цена {price} не из каталога")

    return {"ok": len(violations) == 0, "violations": violations}

State-machine: путь каждого запроса

Harness работает как детерминированный автомат. У каждого запроса ровно один исход:

ЗАПРОС
  │
  ▼
[consult] ──────────────────────────────────────────────────────────
  │  LLM генерирует ответ с товарами/ценами
  ▼
[guard.check] ─── PASS ──▶ [показать ответ] ✅
  │
  FAIL (выдуман товар или цена)
  │
  ▼
[retry] ← сужаем кандидатов, усиливаем инструкцию, 1 дополнительный вызов LLM
  │
  ▼
[guard.check] ─── PASS ──▶ [показать ответ после ретрая] ✅
  │
  FAIL снова
  │
  ▼
[graceful fallback]
  НЕ показываем кривой ответ
  НЕ показываем стектрейс
  «Давайте уточню детали и передам менеджеру»
  → захват лида: имя + телефон + brief для менеджера ✅

Экономика ретрая

Контекст: 2000 токенов
Ответ:     300 токенов
Стоимость запроса: ~$0.003

Без ретрая:  1 вызов  = $0.003
С 1 ретраем: 2 вызова = $0.006 (в худшем случае)
С 3 ретраями: 4 вызова = $0.012

→ 1 ретрай удваивает худший случай.
  Больше — раздувает и задержку, и счёт.

Graceful degradation: почему это победа, а не провал

Интуиция подсказывает: «бот не смог — это плохо». Harness-инжиниринг переворачивает:

Честная оговорка: ориентир vs. финальный ответ

Даже пройдя ассерт, расчёт мощности котла или стоимости системы — предварительный ориентир. Реальные параметры зависят от замера, утечек тепла, высоты потолков, типа радиаторов.

🧪 Симулятор гарда

Выберите сценарий — симулятор покажет прохождение по state-machine шаг за шагом.

Проверь себя

🛡️ Щит, не замена: бриф и handoff

Модуль 7 из 9 — как бот доводит лида до горячего состояния и передаёт человеку

Философия: бот — щит менеджера

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

Это не недостаток, а архитектурный выбор. Бот без щита — это бот, который пытается имитировать эксперта на финальных переговорах. На сложном дорогом товаре (котёл отопления — это 40–100 тыс. руб. и инженерное решение на годы) покупатель хочет живого специалиста. Попытка бота «дожать» только вызовет недоверие.

Глубина: handoff = событие конверсии

Какая метрика важна для бота-щита? Не длина диалога. Не доля разговоров, «решённых без человека». Главная метрика — количество качественных брифов, переданных менеджеру.

Handoff — это и есть конверсия. Ради этого момента строилась вся система: persona-routing (M3), output_contract (M4), fallback-гарды (M6). Бот собирает данные, квалифицирует намерение, формирует структурированную карточку — и передаёт. Менеджер получает не «пришёл какой-то клиент», а горячего лида с параметрами, бюджетом и контактом.

Глубина: квалификация > закрытие для доверия

На дорогом/сложном товаре есть правило: честная квалификация + передача эксперту конвертит лучше, чем имитация менеджера.

• Покупатель отопительного котла принимает решение на 10–20 лет. Он хочет говорить с инженером, а не с чат-ботом.
• Бот, который говорит «Хороший выбор! Оформляем?» — вызывает тревогу. Бот, который говорит «Я подобрал три варианта, уточнил бюджет — сейчас передаю нашему специалисту, он перезвонит в течение часа» — вызывает доверие.
• Правило: не притворяйся человеком на закрытии. Раскрытие ограничений бота в нужный момент — не слабость, а честность, которая работает.

Глубина: бриф как структурированная экстракция (связь с M4)

В M4 мы изучали output_contract — дисциплину структурированной экстракции. Бриф для менеджера — это ровно та же дисциплина: из диалога бот извлекает карточку с полями, а не свободный пересказ.

Менеджер получает:

{
  "площадь_м2":    150,
  "тип_топлива":   "газ",
  "бюджет":        "40-60к руб.",
  "кандидаты":     ["K-102 Котёл газовый 32 кВт"],
  "контакт":       "+7 9XX XXX-XX-XX (Telegram)",
  "температура":   "горячий — просит перезвонить сегодня"
}

Реальные id товаров — не «что-то похожее на котёл», а конкретный K-102 из каталога. Менеджер открывает карточку и уже знает, что предлагать.

Когда передавать: триггеры handoff (связь с M3)

В M3 мы строили routing-правила. Handoff — один из маршрутов, с чёткими триггерами:

Как не потерять лид

1. Взять контакт ДО handoff — имя и телефон/мессенджер нужны до того, как сессия закрыта.
2. Бриф уходит немедленно — не после звонка менеджера, а в момент нажатия кнопки/триггера. CRM / Telegram-уведомление / почта — в реальном времени.
3. Менеджер оффлайн — фиксируем заявку («записал вас, перезвоним до 18:00»), не исчезаем в тишину. Обещание перезвона = удержание лида.

🔧 Интерактив: сборщик брифа

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

Площадь:    —
Топливо:    —
Бюджет:     —
Кандидат:   —
Контакт:    —
Темп-ра:    —

Проверь себя

Verification Gate: golden ≠ adversarial

Модуль 8 из 9 — почему «я проверил вручную» — не верификация, и как тестировать недетерминированную систему

Verification Gap: разрыв между «выглядит» и «работает»

В M6 мы построили runtime-ассерт, который ловит нарушение контракта прямо в боте. Сегодня разберём, как убедиться, что бот надёжен ещё до продакшна, — и почему это принципиально сложнее, чем кажется.

Почему happy-path даёт ложную уверенность

Golden-тесты — фиксированные эталонные диалоги, которые бот должен «уметь» проходить. Это регрессионные тесты: они проверяют, что нечто, что работало раньше, не сломалось после правок промпта или модели.

Golden vs Adversarial: в чём разница

Что входит в adversarial-набор для бота интернет-магазина отопления:

Как тестировать недетерминированную систему

LLM каждый раз даёт чуть другой ответ. Зафиксировать точный текст невозможно — он меняется. И это та же стохастика, что в M1: temperature / top-p > 0 делают вывод вероятностным (при temperature=0 разброс меньше, но привязки к истине это не добавляет). Раз формулировка не фиксирована — ассертить её дословно бессмысленно. Это звучит как проблема, но решение простое:

Инварианты для бота интернет-магазина отопления:

🔍 Найди галлюцинацию

Инвариант inv_1 + inv_2: товар должен быть в каталоге, и цена должна совпадать. Ниже — реальный каталог и 4 ответа бота. Определи, где нарушение.

K-101  "Котёл газовый 24 кВт"              — 41 900 руб
K-102  "Котёл газовый 32 кВт"              — 53 400 руб
R-210  "Радиатор алюминиевый 10 секций"   — 6 700 руб
B-050  "Бойлер косвенного нагрева 100 л"  — 28 500 руб

Как устроен автоматический гейт

Гейт — это скрипт, который прогоняет golden + adversarial кейсы, ассертит инварианты и выдаёт объективный pass/fail. DoD: гейт зелёный.

# verify_bot.py — структура гейта (псевдокод)
import json, re

CATALOG = json.load(open("catalog.json"))

def run_suite(cases):
    results = []
    for case in cases:
        answer = call_bot(case["input"])          # вызов бота
        results.append({
            "case": case["id"],
            "inv1_no_phantom": check_inv1(answer),  # артикулы ∈ каталог
            "inv2_price_ok":   check_inv2(answer),  # цены совпадают
            "inv3_role_ok":    check_inv3(answer, case.get("adversarial")),
            "inv4_non_empty":  len(answer.strip()) > 0 and "Traceback" not in answer,
        })
    return results

def check_inv1(answer):
    found = re.findall(r'[A-Z]-\d+', answer)
    return all(code in CATALOG for code in found)

def check_inv2(answer):
    for code in re.findall(r'[A-Z]-\d+', answer):
        price_match = re.search(r'(\d[\d\s]*)\s*руб', answer)
        if price_match:
            stated = int(price_match.group(1).replace(' ', ''))
            if stated != CATALOG[code]["price"]:
                return False
    return True

GOLDEN  = json.load(open("cases_golden.json"))
ADVERSARIAL = json.load(open("cases_adversarial.json"))

all_results = run_suite(GOLDEN) + run_suite(ADVERSARIAL)
failed = [r for r in all_results if not all(r[k] for k in r if k != "case")]
if failed:
    print("FAIL:", [r["case"] for r in failed])
    raise SystemExit(1)
print("PASS — all invariants hold")

Жизненный цикл гейта

Проверь себя

Деплой, экономика, поддержка

Модуль 9 из 9 — финальный. Как вывести заземлённого консультанта в продакшн, считать его стоимость и удерживать качество со временем.

🚀 Деплой: два независимых слоя

Заземлённый ИИ-консультант для интернет-магазина состоит из двух частей, которые деплоятся отдельно от основного сайта клиента — так мы не трогаем его CMS/конструктор.

<script src="https://api.bot.example/widget.js"
  data-origin="https://shop.example">
</script>

✅ Смоук-тест продакшна (чеклист)

После каждого деплоя прогони шесть проверок. Ни одна не требует лезть в код — только браузер и DevTools:

💰 Токен-экономика: откуда берётся стоимость диалога

Каждый диалог с LLM стоит деньги. Формула простая:

Почему модульность (M4) и размер набора кандидатов (M5) бьют по рублю: системный промпт и кандидаты — это основной объём входного контекста. Если кандидатов 20 вместо 5, входной контекст может вырасти в 2–3 раза. Именно поэтому M5 учил нас отбирать минимально достаточный набор.

⚙️ Выбор модели: тейдоф качество / латентность / цена

Стратегии:

• Одна модель под worst-case — проще в поддержке, чуть дороже. Подходит при небольшом трафике.
• Роутинг — классифицируй запрос (простой/сложный) и выбирай модель. Экономит до 60–80% на простых вопросах. Сложнее в инфраструктуре, нужен гейт (M8) для обоих путей.

🧮 Калькулятор экономики проекта

Подставь свои цифры — посмотри, сколько реально стоит LLM относительно абонентки. Все цены иллюстративные.

* Цены иллюстративные; реальные тарифы зависят от провайдера и модели.

📉 Дрейф в проде — главная угроза заземления

Заземлённый консультант силён ровно настолько, насколько свеж его каталог. В проде всё дрейфует:

🔄 Поддержка как продукт: связь с M2

В M2 мы говорили о модели «setup + абонентка». Теперь видно, почему она устроена именно так:

Калькулятор выше показывает: LLM-токены — малая часть себестоимости. Абонентка — это оплата работы фрилансера, а не перепродажа токенов. Клиент платит за работающий, актуальный сервис, а не за API-запросы.

❓ Проверь себя

Готово 🎉

9 модулей пройдены. Теперь у тебя есть полный playbook: от механики галлюцинаций до деплоя и поддержки заземлённого консультанта.

• Понимаешь, ПОЧЕМУ LLM врёт и что значит «заземлить» ответ на реальный каталог
• Умеешь продавать done-for-you консультанта, а не коробку (setup + абонентка)
• Строишь тонкий kernel + инстансы: новый клиент = подменить persona
• Собираешь промпт из блоков (антивинегрет), а не монолитом
• Делаешь детерминированный retrieval кандидатов ДО LLM
• Ставишь defense-in-depth: гард + ретрай + graceful fallback в захват лида
• Проектируешь handoff как событие конверсии (щит, не замена)
• Различаешь golden и adversarial тесты — закрываешь verification gap
• Считаешь экономику диалога и держишь дрейф в проде под контролем

Что читать дальше

• Методология harness-engineering — verification gap и модульность как отдельная дисциплина
• Документация по structured output / tool-use твоего LLM-провайдера
• Гайды по prompt injection и LLM-безопасности (OWASP LLM Top-10)
• Паттерны RAG: гибридный retrieval, реранкеры, оценка retrieval-качества

▶ Пройти курс заново