РАЗДЕЛ 1. Подходы и методологии по зонам 2–5¶

Ссылки проверены 2 сентября 2026 года. Шкала применена строго: работа в проде одной компании всё ещё считается пилотами; для промышленной практики нужны несколько независимых применений и измеримые результаты.

Зона 2 — дискавери¶

CollabCoder — совместный индуктивный анализ качественных данных. Держатели: Jie Gao и соавторы, Singapore University of Technology and Design, SMART, University of Notre Dame; CHI 2024, 11 мая 2024. Процесс: независимое открытое кодирование → обсуждение расхождений → сборка кодбука. Артефакты: коды для фрагментов интервью, уверенность кодировщика, журнал решений, пары расхождений и IRR, согласованный список кодов, группы кодов, финальный кодбук. Роли: минимум два человека-кодировщика независимо интерпретируют материал и достигают консенсуса; LLM предлагает коды, обнаруживает конфликты и группирует согласованные коды, но не утверждает трактовку. Зрелость: пилоты — лабораторная оценка с 16 участниками; опубликован процесс и код, промышленного применения несколькими исследовательскими командами не показано. Вендор: прототип GPT-powered, но трёхфазный процесс не зависит от уникальной функции OpenAI. Это не полный discovery, а хорошо определённый участок интервью → кодбук.
LLM-in-the-loop Thematic Analysis. Держатели: Shih-Chieh Dai, Aiping Xiong, Lun-Wei Ku; Findings of EMNLP, декабрь 2023. Артефакты: исходная разметка, предложения кодов, последовательность обсуждений человека с моделью, промежуточные и финальный кодбуки, итоговая кодировка корпуса. Роли: исследователь задаёт аналитическую рамку, проверяет смысл кодов и принимает финальные решения; LLM работает как дополнительный кодировщик и участник итеративного обсуждения. Зрелость: пилоты — два кейса на опросах о прослушивании музыки и использовании менеджеров паролей; качество было сопоставимо с человеческим кодированием при меньших трудозатратах, но внешних внедрений нет. Вендор: проверено на GPT‑3.5; сам протокол переносим, но опубликованная оценка не доказывает переносимость качества на другие модели.
Interview-Informed Generative Agents for Product Discovery. Держатели: Zichao Wang, Alexa Siu; препринт 10 марта 2026, затем CHI 2026. Это редкий случай не продажи «синтетических пользователей», а проверки, где они работают и где нет. Процесс: скрининг респондентов → 90-минутные интервью о реальных рабочих процессах → персональная память агента → тест четырёх продуктовых концепций людьми и агентами → сравнение TAM, NPS и открытых ответов. Артефакты: протокол интервью, 51 транскрипт, память и scratchpad каждого агента, четыре концепт-прототипа, 3 060 человеческих и столько же синтетических ответов, распределения оценок, тематическое сравнение, метрики индивидуальной и популяционной точности. Роли: исследователь отбирает людей, создаёт концепты и определяет пороги пригодности; реальные пользователи остаются источником ground truth; агенты применяются только для дешёвого предварительного скрининга. Зрелость: пилоты — одно продольное исследование, N=51. Главный результат отрицательно-полезный: агенты приблизительно воспроизводят распределение ответов, но плохо воспроизводят конкретного человека; лучший вариант дал лишь около 67% человеческой индивидуальной согласованности. Вендор: архитектура «memory–retrieval–reflection» переносима; реализация частично использовала компоненты OpenAI, поэтому доказательство не модель-агностично.

Белое пятно зоны 2. По запросам AI-assisted continuous discovery, agent product discovery hypothesis prioritization, LLM opportunity solution tree, continuous discovery agents interview experiment loop не найден опубликованный процесс, который целиком ведёт цепочку сигнал → гипотеза → интервью/эксперимент → решение → обновлённый backlog и задаёт качество каждого перехода. Найденные методы хорошо автоматизируют анализ интервью либо ограниченно симулируют респондентов; управление портфелем гипотез остаётся у продакта и обычно вообще не описано.

Зона 3 — обслуживание¶

AIOpsLab — “gym” для операционных агентов. Держатели: Microsoft Research, исследовательская группа Chetan Bansal/Saravan Rajmohan; 20 декабря 2024, расширенная публикация MLSys 2025. Процесс: определить операционную задачу → развернуть сервис и workload → инъецировать отказ → передать агенту ограниченный Agent–Cloud Interface → записать действия и состояние → проверить обнаружение, локализацию, RCA и mitigation. Артефакты: спецификация задачи (task, workload, fault, solution), сценарий отказа, workload, набор разрешённых API, логи/метрики/трейсы, траектория действий агента, эталонное решение и метрики выполнения. Роли: инженер создаёт сценарии, оракулы и допустимое пространство действий; агент исследует систему и предлагает или выполняет действия только через валидирующий оркестратор. Зрелость: пилоты — протестированы четыре класса задач, пять агентов и реалистичные, но лабораторные микросервисы; production-on-call не показан. Вендор: ядро открыто под MIT и интерфейс допускает произвольного агента; Azure используется как одна реализация, а не обязательная несущая конструкция.
Tool-using ReAct agent for RCA. Держатели: Microsoft Research, Devjeet Roy и соавторы; FSE, июль 2024. В отличие от генерации RCA по одному тикету агент сам запрашивает диагностические сервисы. Артефакты: карточка инцидента, запросы к логам/метрикам/БД, последовательность наблюдений и гипотез, собранные доказательства, итоговый RCA. Роли: команда SRE подключает разрешённые диагностические инструменты; on-call остаётся владельцем диагноза и mitigation; агент выбирает следующий источник данных и строит RCA. Зрелость: пилоты — оценка на отложенном наборе реальных инцидентов Microsoft и отдельный кейс с одной продуктовой командой; автономное исправление продакшена не исследовалось. Вендор: ReAct и tool-use переносимы, но доказательство получено на закрытых данных и диагностике Microsoft.
Meta AI-assisted root-cause isolation. Держатель: Meta Engineering; 24 июня 2024. Процесс: эвристический поиск сокращает тысячи изменений до сотен → LLM ранжирует изменения турнирным «голосованием» пакетами по 20 → responder получает пять кандидатов → вручную воспроизводит и проверяет результат. Артефакты: контекст расследования, граф владения/исполнения кода, список кандидатов, ранжирование top‑5, объяснение и закрытая обратная связь от responder. Роли: система ищет и ранжирует; человек подтверждает причинность и выбирает mitigation. Зрелость: пилоты — внутреннее применение и exhaustive backtesting; истинный виновник оказался в top‑5 в 42% расследований web-monorepo. Это полезный ассистент, но не автономный RCA. Вендор: реализация жёстко связана с fine-tuned Llama 2, внутренним кодовым графом и примерно 5 000 RCA-примерами Meta; общий паттерн переносим, опубликованная система — нет.
LLM-assisted postmortems с сохранением человеческого обучения. Держатель: Datadog, Tran Le, Till Pieper, Gillian McGarvey; 23 сентября 2024. Процесс: структурированные поля Incident Management + обсуждение в Slack → ансамбль моделей генерирует отдельные разделы → человек редактирует и завершает postmortem. Артефакты: incident metadata, коммуникационный таймлайн, черновики разделов, первый полный черновик, человеческие исправления, финальный postmortem. Роли: Incident Commander и автор postmortem сохраняют право интерпретации причин и lessons learned; LLM агрегирует факты и пишет черновик. Зрелость: пилоты — функция была доведена до продукта, на настройку структуры потрачено более 100 часов, но нет независимых внедрений и опубликованного влияния на повторяемость инцидентов. Вендор: опубликованная реализация привязана к Datadog Incident Management/Bits AI и Slack; принцип «черновик, не автор вывода» переносим.

Белое пятно зоны 3. По запросам LLM agent on-call autonomy levels, agent production remediation approval rollback, autonomous SRE incident lifecycle, AI postmortem action item verification не найден независимый промышленный процесс выдачи агенту write-доступа в прод: классификация действия по blast radius, двойное подтверждение, lease на полномочия, автоматическая проверка восстановления и отзыв автономии. Публичные материалы в основном заканчиваются на RCA/recommendation либо описывают preview конкретного облачного продукта.

Зона 4 — оперирование¶

InsightPilot — intent-driven exploratory analytics. Держатели: Microsoft Research и HKUST; EMNLP, декабрь 2023. Процесс: человек задаёт аналитическое намерение → LLM строит цепочку типизированных analysis actions → детерминированный insight engine вычисляет факты → результаты фильтруются по релевантности и разнообразию → LLM пишет отчёт. Артефакты: пользовательский вопрос, analysis entities/actions, последовательность исследования, вычисленные инсайты, ранжированный набор инсайтов, графики и текстовый отчёт. Роли: человек задаёт цель и принимает бизнес-решение; LLM планирует исследование и объясняет; вычислительный движок, а не LLM, отвечает за численные факты. Зрелость: пилоты — четыре data scientist, два датасета, 24 сравнения и один case study; production нет. Вендор: реализация на GPT‑3.5 и text-embedding-ada-002; разделение вычисления и интерпретации модель-агностично, результаты — нет.
Finch — финансовый data-agent Uber. Держатель: Uber FinTech, Spencer Garth, Tim Ross и соавторы; 17 июля 2025. Процесс: вопрос финансиста в Slack → supervisor выбирает подагента → поиск метаданных и бизнес-алиасов → выбор таблиц → генерация и исполнение SQL с исправлением ошибок → ответ, детализация и экспорт. Артефакты: curated single-table data marts, семантические алиасы колонок и значений, запрос, выбранные источники, SQL, статус tool calls, таблица ответа, Google Sheet, golden queries и regression-набор. Роли: финансы формулируют вопрос, трактуют результат и принимают решение; data/platform-команды поддерживают семантику и права; агенты маршрутизируют, находят данные и выполняют запросы. Зрелость: пилоты — используется финансовыми командами Uber, есть независимые проверки подагентов, routing, end-to-end и regressions, но показатели охвата не опубликованы. Важная честная граница: авторы называют Finch пригодным для повседневной работы, а human validation для критических запросов руководства — ещё roadmap. Вендор: модели заменяемы через Uber GenAI Gateway; конкретная практика зависит от Slack, LangGraph, OpenSearch и внутренних витрин, но не от одного поставщика модели.
Внутренний data-agent OpenAI с повторяемыми аналитическими workflow. Держатель: OpenAI Data Productivity/Data Science; 29 января 2026. Процесс: уточнить неоднозначный вопрос → найти данные через шесть слоёв контекста → выполнить и самопроверить SQL → опубликовать notebook/report → сохранить подтверждённую поправку в memory → упаковать повторяемый анализ, например weekly business report, в reusable workflow. Артефакты: table lineage и usage, экспертные аннотации, code-derived определения таблиц, institutional knowledge, редактируемые memories, execution trace, SQL, notebook/report, workflow-инструкция, golden SQL и непрерывные evals. Роли: domain experts определяют метрики и документируют caveats; пользователь уточняет цель, может остановить агента и валидирует допущения; агент исследует, исправляет неудачные join/filter и публикует результат. Зрелость: пилоты — реальное использование в Engineering, Data Science, GTM, Finance и Research; платформа данных имеет более 3 500 внутренних пользователей, 70 000 датасетов и 600 PB, но доля пользователей самого агента и бизнес-эффект не раскрыты. Вендор: жёстко связан с GPT‑5.2, Codex, OpenAI Evals/Embeddings и внутренними источниками. Архитектурный паттерн переносим, реализация нет. Пересекает зоны 4 и 5.
Multi-level hypothesis-driven agentic analytics project44. Держатель: project44, Ankit Singh Chauhan и Aditya Sood; 6 апреля 2026. Процесс эволюционировал от свободного tool-use к plan-then-execute, затем к двум уровням: полный поиск с парными гипотезами «влияет/не влияет» → ранжирование доказательств → drill-down только по сильным сигналам. Артефакты: унифицированный shipment profile примерно из 400 переменных, проверяемый план, пары конкурирующих гипотез, 60 аналитических шагов, ranked findings, drill-down, рекомендации и отчёт воспроизводимости. Роли: аналитик утверждает план, валидирует findings и решает, какие рекомендации превращать в действия; агент чистит данные, перебирает связи и строит доказательную цепочку. Зрелость: пилоты — сравнение с одним ручным customer deep-dive: все прежние факторы найдены, время сокращено примерно в 16 раз, стоимость — на 95%; на двух датасетах по три запуска дали 80–85% совпадения ключевых выводов. Автономное действие и проактивный мониторинг прямо обозначены как будущее. Вендор: реализация опирается на данные project44; двухуровневый гипотезный процесс переносим.

Белое пятно зоны 4. Запросы LLM automated business analytics workflow metrics decision making human in loop, agentic analytics business metrics decision workflow case study, "AI agent" "weekly business review" metrics, "automated insights" product metrics LLM дали text-to-SQL, отчёты, QBR-генераторы и vendor “decision intelligence”. Не найден зрелый общий процесс постоянное наблюдение → обнаружение значимого отклонения → проверка причинности → оценка вариантов и риска → назначение владельца решения → действие → измерение эффекта. У всех четырёх подходов выше решение остаётся за человеком; только project44 пытается формализовать различение сигнала и шума.

Зона 5 — управление процессом¶

Error-analysis-first eval loop. Держатели: Hamel Husain и Shreya Shankar; AI Evals FAQ, 28 мая 2025, обновлено 31 августа 2026. Процесс: собрать 20–50 репрезентативных traces → человек делает open coding ошибок → axial coding в таксономию failure modes → приоритизация по частоте/вреду → простые assertions или размеченный набор → калибровка LLM-judge против человеческих меток → CI и выборочный production-monitoring → новые ошибки переходят в regression set. Артефакты: trace, заметки кодировщика, таксономия ошибок, размеченный датасет, rubric, judge с TPR/TNR, CI-suite, production sample, история версий prompt/eval. Роли: один domain expert — “benevolent dictator” качества; инженеры устраняют причины; LLM может помогать размечать и судить только после калибровки. Зрелость: промышленная практика — метод преподан 700+ инженерам и PM, опубликованы несколько независимых product cases; например, Nova Escola с примерно 1 млн пользователей в месяц и ежедневными evals на 2% production traffic, а также production-кейс Rechat/Lucy. Доказательства в основном исходят от авторов методики, но внедрения независимы. Вендор: принципиально vendor-neutral; авторы рекомендуют начинать с ноутбука и предметного эксперта, а не с eval-платформы.
EDDOps — Evaluation-Driven Development and Operations. Держатели: Boming Xia, Qinghua Lu, Liming Zhu и соавторы, CSIRO Data61/Responsible AI Research Centre; первая версия 21 ноября 2024, актуальная — 17 ноября 2025. Процесс: определить evaluation plan → создать test cases и slices → проводить связанные offline/online evaluations → анализировать сбои → направлять evidence-linked изменения в agent/runtime → shadow/canary/rollback → пополнять тесты из production evidence. Артефакты: metric-mix policy, slice taxonomy, run metadata schema, escalation policy, test cases, traces, eval-result store, safety cases, evidence-linked tickets, change plan, release/rollback criteria. Роли: stakeholder и SME задают цели, риски и оракулы; человек аудирует неоднозначные и высокорисковые случаи и разрешает изменения; AI-evaluators выполняют массовые проверки и runtime probes; агенту разрешена только ограниченная адаптация. Зрелость: пилоты — модель выведена из обзора 134 академических и 27 practitioner-источников, затем инстанцирована на pre-production tax assistant; production rollout и online controls не проводились. Вендор: архитектура явно разделяет agent, evaluator, stores и interfaces и рассчитана на замену модели и инструментов.
Production evidence → eval target → bounded agent task: Tax AI. Держатели: Thrive Holdings, OpenAI и сеть Crete; 27 мая 2026. Процесс: практик исправляет результат → сохраняется полный provenance от исходного документа до filed return → исправления превращаются в field-level review rows → повторяющиеся ошибки группируются → создаётся целевой eval → Codex получает ограниченный worktree, trace, evals и skills → предлагает изменение → проходит targeted и regression evals → инженер решает, выпускать ли его. Артефакты: production trace, predicted/expected/final value, review rows, failure cluster, finding, task YAML, execution plan/results, eval datasets/suites/graders, skills, read-only evidence package, candidate PR. Роли: бухгалтер исправляет и утверждает декларацию; product team разбирает неоднозначность; инженер отвечает за архитектуру и выпуск; Codex локализует причину, меняет разрешённую поверхность и проверяет её. Зрелость: пилоты, хотя масштаб большой: явным образом назван пилотом на 30+ бухгалтерских фирмах и 7 000 декларациях; за шесть недель доля деклараций с минимум 75% корректно заполненных полей выросла с 25% до 86%, заявлена точность до 97%. Независимой проверки вне сети Crete нет. Вендор: конкретная реализация привязана к Codex/OpenAI; схема production correction → evidence → eval → bounded change переносима.

Белое пятно зоны 5. По запросам organizational agent memory governance, prompt instruction versioning ownership workflow, context engineering refresh policy eval regression, AgentOps lifecycle roles artifacts не найден зрелый vendor-neutral процесс управления организационной памятью: кто владеет фактом, какой у него TTL, как разрешаются противоречия, кто удаляет устаревшее/персональное знание, как изменение контекста проходит review и rollback. EDDOps закрывает eval-контур, Tax AI — превращение evidence в изменение, но не полную knowledge governance.

Русскоязычный контур. По запросам ИИ агенты продуктовый дискавери методология, ИИ агент SRE разбор инцидентов, агент продуктовая аналитика бизнес метрики, управление контекстом и эвалами агентов нашлись переводы документации, обзоры платформ и общие отчёты о внедрении. Оригинальной русскоязычной методологии с именованными артефактами, человеческими decision rights и подтверждёнными независимыми внедрениями не найдено.

РАЗДЕЛ 2. Чего не хватает в самой рамке¶

Нет типа найденного объекта. Сейчас в один список могут попасть методология, workflow-pattern, исследовательский протокол, reference architecture, формат артефакта и продуктовая функция. Нужное поле: тип, причём продукт или архитектура не должны автоматически считаться методологией.
Определение методологии слишком слабое. «Процесс, роли или артефакты» пропускает материал, где есть только один из трёх. Полная методология должна задавать одновременно: входы, последовательность, выходы, decision rights, критерии перехода, обратную связь, исключения, отказ/rollback и процедуру изменения самой методологии.
Зрелость смешивает три оси. Масштаб внедрения, качество доказательства и автономность — разные вещи. Нужны отдельные шкалы:
deployment: лаборатория / shadow / ограниченный prod / массовый prod;
evidence: self-report / контролируемое сравнение / независимая репликация;
autonomy: совет / предложение действия / действие с approval / ограниченная автономия / полная автономия.
«Модель-агностичность» недостаточна. Подход может менять GPT на Claude, но быть намертво связанным с Datadog, Azure, Slack, закрытой semantic layer или proprietary trace schema. Нужна stack portability: модель, orchestration, data/semantic layer, observability, identity/permissions и artifact store.
Зоны 2 и 4 разделены по названию, но не по решению. Метрики уже входят в discovery, а «оперирование» тоже анализирует метрики. Практичнее провести границу так:
discovery отвечает: «что стоит проверить или построить?»;
business operations: «какое повторяемое решение нужно принять сейчас?»;
переход определяется артефактом: hypothesis/experiment backlog против decision record/action/outcome.
Зона 3 склеивает четыре разных цикла: наблюдение и detection; incident command; diagnosis/mitigation/recovery; post-incident learning. У них разные роли, SLA, права агента и артефакты. Особенно опасно оценивать одним уровнем автономии генерацию RCA и выполнение kubectl/rollback.
Зона 5 перегружена. В ней смешаны:
agent configuration lifecycle — prompt/tools/policies/evals;
context and knowledge governance — provenance, freshness, memory;
operating model — владельцы, финансирование, risk acceptance;
observability и improvement loop.

Это минимум три подзоны: agent control plane, knowledge/context governance, methodology governance.

Нет сквозного feedback loop. Главный AI-native контур проходит через все зоны: пользовательское наблюдение или production trace → failure/insight → гипотеза → eval → изменение контекста/инструмента/процесса → controlled rollout → измеренный outcome. Сейчас зоны позволяют собрать пять локальных playbook, которые не обмениваются именованными артефактами.
Не заданы decision rights и ответственность. Вопрос «где человек сказал да» недостаточен. Нужны: кто legally/accountably владеет решением, кто может делегировать, какой лимит риска, сколько действует полномочие, кто отзывает его, что происходит при недоступности человека.
Нет управления неопределённостью. Следует спрашивать не только итоговый score, но и источник ground truth, confidence calibration, false-positive/false-negative cost, допустимую нестабильность между запусками и правило эскалации при конфликте источников.
Не охвачены security и segregation of duties. Prompt injection, утечка контекста, poisoned memory, over-privileged tools, конфликт «агент предложил — тот же агент проверил — тот же агент выпустил» должны быть сквозным слоем, а не подразумеваться внутри зоны 5.
Нет экономики агента. Нужны outcome-denominated cost, latency budget, стоимость человеческой проверки, цена ошибочного действия и условие, при котором автоматизация дороже ручного процесса.
Нет временной воспроизводимости. Для повторения решения надо фиксировать не только модель, но и её версию, prompt/policy/tool versions, retrieved context, snapshot данных, права пользователя, memory state и полный trace.
Не определён lifecycle артефактов. У каждого документа, eval, инструкции, памяти и гипотезы должны быть owner, источник, версия, TTL/freshness SLA, статус утверждения, связи с решениями и правило удаления.
Не хватает outcome после решения. Аналитический отчёт, RCA или codebook сами по себе не доказывают ценность. Методология должна требовать последующий артефакт: принятое решение, выполненное действие, измеренный эффект и обновлённое правило/знание.

РАЗДЕЛ 3. Где маркетинг легче всего принять за методологию¶

Agentic AI / autonomous agent / digital employee / AI teammate / copilot. Это описание интерфейса или желаемой автономии. Без входов, порядка действий, полномочий, checkpoints и outcome-метрик процесса нет.
Multi-agent / swarm / supervisor-agent. Топология системы не равна распределению ответственности. Назвать три промпта Researcher, Critic и Manager — не значит определить организационные роли.
AIOps. Чаще означает корреляцию алертов, anomaly detection и поиск похожих инцидентов. Это может быть полезно, но не является агентным incident lifecycle. Ключевая проверка: система сама выбирает следующий диагностический шаг или только ранжирует события?
AgentOps. Термин используется одновременно для tracing SDK, observability SaaS, CI-evals и полноценной операционной дисциплины. Dashboard с token count и latency не задаёт процесс изменения агента.
Self-healing / autonomous remediation. Нередко означает выполнение заранее написанного runbook по алерту. Без выбора действия, blast-radius policy, проверки восстановления и rollback это обычная автоматизация, а не агентная методология.
AI-powered RCA / root cause copilot. Top‑5 подозрительных deploy не является доказанной причиной. Причинность требует воспроизведения, контрфактуальной проверки или подтверждённого восстановления после воздействия.
Automated postmortem. Красивый черновик из Slack — артефакт генерации текста. Методология начинается там, где люди проверяют факты, извлекают contributing conditions, назначают действия и затем проверяют их выполнение.
Synthetic users / AI personas / digital twins. Сгенерированный правдоподобный ответ не является пользовательским свидетельством. Без grounding на реальных интервью, held-out human comparison и заранее заданного порога fidelity это имитация, не research method.
AI-augmented continuous discovery. Если AI только транскрибирует и суммирует интервью, процесс остаётся обычным continuous discovery. AI-native вариант должен изменить роли, пропускную способность, quality gates и способ превращения evidence в backlog.
Conversational BI / text-to-SQL / data copilot. Это новый способ получить числа. Он не решает, какие числа важны, где сигнал, кто отвечает за действие и как проверить эффект.
Augmented analytics / agentic analytics. Автоматическая генерация десятков корреляций может увеличить шум. Процесс появляется только при наличии competing hypotheses, статистических ограничений, ranking policy, human validation и decision record.
Decision intelligence. Часто это umbrella-brand для BI + rules engine + workflow automation. Четыре слова sense–decide–act–learn на диаграмме не доказывают существование владельцев решений, обратной связи и измерения результата.
Semantic layer / metrics layer. Это необходимый контракт значений и данных, но не процесс регулярного разбора метрик и принятия решений.
Context engineering. Нередко так переименовывают prompt engineering или RAG. Без владельцев источников, authority hierarchy, freshness, versioning, compaction policy, evals и rollback это техника сборки входа, не дисциплина управления контекстом.
Organizational memory / enterprise knowledge graph / corporate brain. Хранилище и retrieval не отвечают, какая запись истинна, кто её утвердил, когда она устарела и имеет ли агент право использовать её для действия.
Eval-driven development. Набор generic scores — helpfulness, relevance, groundedness — ещё не метод. Нужны error analysis, предметная таксономия сбоев, человеческие метки, калибровка judge, regression promotion и связь результата eval с конкретным изменением.
LLM-as-a-judge. Это компонент измерения, а не независимый арбитр. Без TPR/TNR против человеческой разметки, анализа смещения и периодической перекалибровки judge лишь автоматизирует неизвестную ошибку.
Human in the loop. Самый удобный маркетинговый эвфемизм. Пока не названы человек, момент вмешательства, видимое ему доказательство, SLA, полномочие отклонить решение и поведение при тайм-ауте, никакого управляемого HITL нет.
Model-agnostic. Единый API-адаптер доказывает заменяемость endpoint, но не переносимость качества, evals, prompt semantics, tool-use и safety behavior. Это свойство интеграции, не методологии.
Production-ready / enterprise-grade. Один внутренний deployment или shadow mode подтверждает пилот, но не промышленную практику по принятой в рамке шкале. Benchmark accuracy, число токенов и скорость ответа также не заменяют измеренный бизнес- или reliability-outcome.