Whitepaper вендора и скриншот Slack-замера могут иметь одинаковое 'среднее качество', но опираться на них для решения - это разные ставки. Разбираю формулу R_eff: три оси доказательства, правило слабого звена, контекстное соответствие - и почему один свой замер сильнее десяти статей из чужих блогов.
Знакомая ситуация: два источника, одно среднее
В понедельник утром продукт-менеджер собирает встречу: выбираем поставщика интеграции с банком. На столе два кандидата. К каждому - два набора материалов.
Первый - официальный whitepaper. PDF на сорок страниц, графики, кейсы клиентов, цифры пропускной способности, обещание «99.99% uptime в среднем за прошлый год». Оформлено идеально. Структурировано на пять разделов с подзаголовками.
Второй - скриншот из чата от знакомого технического директора, который работал с этим поставщиком полгода. Три абзаца: «у нас на нашей нагрузке держит, p95 латентность 180 мс, последний раз когда падало - была вторая неделя января, чинили семь часов». Никаких графиков. Без раскрашенных рамок.
Команда заходит в обсуждение, и кто-то говорит: «Whitepaper выглядит сильнее. Давайте пойдём с ним».
Я хочу разобрать, почему этот рефлекс - самая частая ошибка в выборе поставщика, и какая простая логика её останавливает. Без новых инструментов, без перехода на «культуру данных». Один способ оценивать доверие к источнику, который вы можете попробовать на следующем выборе.
Три оси, которые на самом деле не одна
Когда мы говорим «качественный источник», мы смешиваем три разных вещи, каждая из которых независима от других.
Первая - строгость формулировки. Насколько источник чётко сформулировал, что именно он измеряет и в каких условиях. Whitepaper обычно силён здесь: пять страниц про методологию, разбивка на сценарии, описание окружения. Slack-сообщение от коллеги - слабее: «у нас на нашей нагрузке держит» оставляет открытым, что значит «нашей нагрузке». Назову эту ось F (formal).
Вторая - конкретика чисел и деталей. Насколько источник опирается на наблюдения, а не на общие фразы. «99.99% uptime» - это число. «У нас p95 латентность 180 мс» - это число. И тот и другой источник могут быть сильны в этой оси одновременно. Назову её G (granular).
Третья - надёжность относительно вашего контекста. Whitepaper производит компания, которая продаёт продукт - у неё есть мотивация показывать сильную сторону и замалчивать слабую. Замер от знакомого технического директора, у которого нет мотивации продавать или хвалить, в этом смысле сильнее. Назову её R (reliable).
Эти три оси можно представить как координаты в трёхмерном пространстве. У whitepaper - F=8, G=7, R=2 (мотивация продавца). У Slack-замера - F=4, G=7, R=8 (нет мотивации преувеличивать).
Если усреднить, получим оба источника около 5.5 - почти одинаково. Но если применить другую логику оценки, картина становится противоположной.
Почему оси независимы
Главное, что нужно понять: эти три оси не градации одной величины. Они описывают разные классы ошибок, и сильная сторона одной оси не компенсирует слабую сторону другой.
Источник может быть очень строго сформулирован, но опираться на устаревшие данные - и тогда строгость не спасает. Источник может быть детальным до пунктов, но исходить от продавца с мотивацией приукрасить - и тогда детальность работает против вас (вы поверите конкретике, не задаваясь вопросом, откуда она). Источник может быть от безусловно надёжного коллеги, но сформулирован настолько расплывчато, что вы вытащите из него неправильный вывод.
Это похоже на оценку автомобиля при покупке. У одного - отличный мотор, но изношенные тормоза. У другого - новые тормоза, но проржавевший кузов. Усреднение даёт «оба нормальные», но управлять ими - разные степени риска. И не любой риск можно компенсировать сильной стороной.
В реальности команды чаще всего проваливаются на оси R, потому что она самая неудобная для проверки. Спросить «насколько источник нейтрален» - это поставить под сомнение профессионализм автора. Поэтому большинство обсуждений сводится к оценке F и G, а R молчаливо подразумевается «средняя».
Правило слабого звена
Раз оси независимы, осмысленная оценка - не среднее, а минимум. Доверие к источнику ограничено самым слабым звеном, не самым сильным.
Whitepaper: F=8, G=7, R=2. Доверие = 2 из 9. Slack-замер: F=4, G=7, R=8. Доверие = 4 из 9.
Slack-замер по этой логике в два раза надёжнее, хотя по среднему он слабее.
Аналогия с техосмотром помогает закрепить. На станции техосмотра проверяют тормоза, рулевое управление, освещение, шины. Если хоть один пункт провален - машина не получает допуска на дорогу, сколь бы блестящими ни были все остальные. Никто не считает «среднее качество автомобиля» - потому что отказ на одной из критичных подсистем убивает всю поездку.
Доказательство для решения - то же. Если хоть одна ось из трёх провалена, доверие к источнику низкое, независимо от того, как хороши остальные. Это контринтуитивно для команд, привычных к усреднению, но именно эта логика спасает от типовой ошибки «опереться на красиво оформленный, но односторонний материал».
Уровень контекстного соответствия
К трём осям добавляется четвёртое измерение - насколько источник применим к вашей конкретной ситуации.
Свой замер на вашем проекте, на вашей нагрузке, в вашем окружении - высший уровень. Никаких допущений о переносимости. Назову его CL3 (context level 3).
Замер на похожем проекте в похожих условиях - почти высший. Допущение: ваш проект достаточно близок по характеристикам. Назову его CL2.
Документация поставщика, описывающая «типичный сценарий», - ниже. Допущение: ваш сценарий совпадает с тем, что они подразумевают под «типичным». CL1.
Ответ со Stack Overflow про другой язык, который выглядит похоже на ваш случай, - почти ничего не значит. Слишком много допущений. CL0.
Каждый понижающий уровень - это штраф к итоговой оценке. Источник может быть силён по F/G/R, но если его контекстное соответствие низкое - итоговое доверие падает пропорционально. Это вторая защита от ошибки «увидел красивый бенчмарк, понадеялся, что у нас сработает так же».
Формула на одной строке
Соберём всё вместе. Доверие к решению - это минимум по доказательствам, скорректированный на штраф за уровень контекста.
Не пугайтесь, математика на одной строке: R_eff = min(оценки источников) × (1 − штраф за CL).
Штраф разбит по уровням: CL3 = 0 (без штрафа), CL2 = 0.1 (минус 10%), CL1 = 0.4 (минус 40%), CL0 = 0.9 (минус 90% - почти зануляет).
Возьмём пример. Команда выбирает между двумя движками поиска. Три источника:
- свой замер на тысяче заметок (F=5, G=8, R=7) - CL2 (не на полном объёме данных)
- документация одного из движков (F=8, G=6, R=4) - CL1 (типовой сценарий, не наш)
- пост в Hacker News «у нас в проде сломалось» (F=2, G=7, R=6) - CL1
По среднему получится около 5.7. Команда смотрит и думает «нормально, можно опираться».
По R_eff: минимум первого источника = 5 (с CL2 штрафом 10% → 4.5), минимум второго = 4 (с CL1 штрафом 40% → 2.4), минимум третьего = 2 (с CL1 штрафом 40% → 1.2). Общий минимум - 1.2 из 9. AT RISK - решение опирается на одно недостаточно проверенное предупреждение и две слабые поддержки.
Команда видит результат и понимает: нужен ещё один сильный источник - например, собственный замер на полном объёме данных (CL3, R_eff поднимется в разы). Полтора дня работы, и доверие выходит на нормальный уровень. Без этого - через три месяца после релиза вы поймёте, что выбрали движок, который не вытягивает вашу нагрузку, и переписывание займёт два спринта.
Конкретный пример: специализированное хранилище или универсальная база
Расскажу один кейс, изменю детали.
Команда, делающая локальное приложение для заметок, выбирает векторное хранилище для поиска по смыслу. Два кандидата: специализированное колоночное хранилище для векторов и универсальная база с одним из доступных векторных расширений.
Собрали три источника:
- свой замер на тысяче заметок: специализированное - p95 60 мс, универсальное с расширением - p95 90 мс (F=6, G=8, R=8, CL2 - не на полных 50 тысячах)
- блог производителя специализированного хранилища про производительность на миллионе векторов (F=7, G=8, R=3 - это маркетинг, CL1)
- пост в Hacker News «у нас сломалось при апгрейде версии» без воспроизводимого сценария (F=3, G=4, R=6, CL1)
По среднему - специализированное выглядит «нормально». По R_eff: первый источник - 6 × 0.9 = 5.4 (минус 10% за CL2). Второй - 3 × 0.6 = 1.8. Третий - 3 × 0.6 = 1.8. Минимум - 1.8.
Команда видит, что доверие держится на слабом - необъяснимая поломка из Hacker News тянет всё решение вниз. Идёт собирать четвёртый источник: воспроизводит сценарий апгрейда из того поста, проверяет на своих данных. Час работы. Оказывается, что в новой версии проблему починили. Источник переоценивается: «устарел, исправлено в версии X.Y». Можно исключить из рассмотрения.
Новый R_eff = min(5.4, 1.8) = 1.8 - всё ещё слабо. Команда добавляет собственный замер на полных 50 тысячах. Получает p95 75 мс - тоже укладывается в требования. CL3, F=7, G=9, R=8 - без штрафа, итог 7. Новый R_eff = min(5.4, 1.8, 7) = 1.8.
И тут команда замечает важное: второй источник (маркетинговый блог) всё равно тянет вниз. Решение принять можно, но с явной пометкой: «опираемся на свой замер, маркетинговый материал поставщика не учитываем как доказательство». Запись в DDR (формат, который разберу в следующем посте) фиксирует это явно, чтобы через год никто не подумал, что решение приняли из-за красивых графиков от поставщика.
Это пример того, как простая логика «минимум, а не среднее» меняет качество обсуждения. Вместо «всё выглядит ОК, давайте брать» - «слабое звено вот тут, давайте его укрепим или явно признаем».
Что отдать AI-агенту, что - себе
AI-агент (Claude Code, Cursor, любой кодовый ассистент) хорошо делает первый шаг: собрать источники по теме, выписать их в таблицу с тремя осями оценок и предложить уровень контекста для каждого. За пять минут даст вам черновик, на который человеку ушло бы час.
Финальный шаг - присвоение R-оценки (надёжности относительно вашего контекста) - стоит держать за собой. Агент не знает, что компания, написавшая whitepaper, недавно пыталась продать вам подписку и получила отказ. Не знает, что технический директор из Slack-замера в прошлом году рекомендовал библиотеку, которая у вас сломалась через полгода. Эти подробности - внутренний контекст команды, который никогда не появится в публичных источниках. Только человек может с ним сверяться.
Базовое правило: агент собирает и оценивает по F/G, человек добавляет R и CL. Если агент проставляет все четыре оси сам - у вас не оценка надёжности, у вас красивая видимость её.
Что почитать дальше
Это третий пост в серии из восьми про дисциплину принятия архитектурных решений. Предыдущие:
- Кладбище решений - почему через полгода никто не помнит мотивировку
- Перед тем как чинить - выпишите три версии - приём следователя для диагностики
Дальше я разберу:
- Как выглядит формат записи решения, чтобы оно через год само открылось на пересмотр, без подвига памяти команды.
- Как маленькое сообщение в чате превращается в продуктовый документ из 13 разделов без расползания рамок.
К этому посту прилагается интерактивный разбор: 3D-сцена в пространстве F/G/R, где можно покрутить семь доказательств и увидеть, как минимум по осям отличается от среднего. Лежит в /guides, крутится мышью, ничего ставить не надо.