TRUST CALCULUS · ОБЗОР

Trust Calculus: оценка доверия к решению по трём осям

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

Зачем нужна формальная оценка доказательств

Когда команда выбирает между двумя техническими решениями, обычно происходит вот что: каждая сторона приносит доказательства. Одни - статью из корпоративного блога. Другие - бенчмарк с чужой конфигурацией. Третьи - ссылку на обсуждение в Reddit. На совещании всё это принимается примерно с одинаковым весом, потому что нет шкалы, по которой можно сравнить.

В итоге побеждает тот, кто убедительнее говорит или у кого больше авторитета в комнате. Не тот, у кого доказательства сильнее. Через полгода, когда решение начинает трещать, выяснится, что ключевой аргумент был маркетинговым материалом, а не реальным замером.

Формальная оценка доказательств решает одну задачу: заставить команду явно ответить на три вопроса о каждом доказательстве - до того, как будет принято решение. Когда эти три ответа записаны рядом с доказательством, становится видно, что одни аргументы весят 0.8, а другие - 0.2. И финальный расчёт доверия к решению отражает это, а не интенсивность дискуссии.

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

Три оси: F, G, R простыми словами

Трастовое исчисление (Trust Calculus) оценивает каждое доказательство по трём независимым осям. Каждая ось даёт оценку от 0 до 1. Ни одна не важнее двух других - они разные измерения одного вопроса: «насколько этому доказательству можно верить в нашей ситуации».

Formal - степень строгости формулировки

Насколько точно сформулировано само доказательство. Расплывчатый вывод «работает быстрее» - низкая строгость. Конкретное утверждение «p95 задержка 42ms при 1000 RPS на конфигурации X» - высокая строгость. Важно: строгость формулировки - это не то же самое, что правдивость. Строго сформулированная ложь остаётся ложью. Но строгость позволяет хотя бы проверить утверждение.

0.0-0.3 · «быстрее», «лучше»

0.4-0.6 · частично с числами

0.7-1.0 · метрика + условия

- · пример: независимое рецензирование

Granular - детализация, наличие цифр

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

0.0-0.3 · одна фраза без деталей

0.4-0.6 · есть данные, нет разбивки

0.7-1.0 · разбивка по сценариям

- · пример: бенчмарк с матрицей

Reliable - надёжность источника в вашем контексте

Насколько надёжен источник - не вообще, а именно для вашей задачи. Статья от вендора, который продаёт продукт - низкая надёжность. Независимый академический бенчмарк - средняя. Замер, сделанный вашей командой на вашей инфраструктуре с вашими данными - высокая. R - самая контекстуальная ось: один и тот же источник может дать 0.9 для одной задачи и 0.3 для другой.

0.0-0.3 · исследование вендора

0.4-0.6 · независимая публикация

0.7-1.0 · ваш замер на ваших данных

- · пример: продакшен-профиль

Каждая ось оценивается отдельно, и их нельзя компенсировать друг другом. Высокая детализация не делает ненадёжный источник надёжным. Надёжный источник не компенсирует расплывчатость формулировки. Итоговая оценка доказательства - это минимум из трёх чисел, не среднее. Именно об этом - следующая секция.

Правило слабого звена: почему минимум, а не среднее

Самый частый вопрос при знакомстве с трастовым исчислением звучит так: «Почему нельзя взять среднее? Если источник надёжный (R = 0.9), разве это не компенсирует то, что доказательство расплывчато (F = 0.2)?»

Нет. Среднее скрывает критическую слабость и создаёт ложное ощущение уверенности. Цепочка из трёх осей - это не сложение сильных сторон, а перемножение ограничений.

Аналогия из жизни: технический осмотр автомобиля. Машина проходит через список пунктов: двигатель, тормоза, фары, рулевое. Если тормоза не прошли - автомобиль не выезжает, даже если двигатель идеальный, фары новые и рулевое без нареканий. Среднее по всем пунктам могло бы выдать «84% - очень хорошо», и машина с плохими тормозами вышла бы на дорогу.

С доказательствами то же самое. Если утверждение расплывчато и непроверяемо (F = 0.2), то детальность данных и репутация источника не имеют значения: нельзя проверить, верно ли утверждение вообще. Или если источник - вендорский маркетинг (R = 0.2), то сколько бы там ни было цифр, эти цифры оптимизированы не для вашей задачи.

Правило слабого звена: итоговая оценка доказательства = min(F, G, R). Не среднее, не взвешенная сумма - минимум. Одна слабая ось обнуляет весь вклад сильных.

Этот принцип знаком инженерам под другим именем - закон Амдала в параллельных вычислениях, или «узкое место» в любой системе. Здесь та же логика: цепочка надёжна ровно настолько, насколько надёжно её самое слабое звено.

Где F/G/R живёт в DDR

DDR (Decision-Driven Record) - формат записи решений из шести обязательных секций. Третья секция называется «Доказательства» - и именно здесь живёт трастовое исчисление.

Каждое доказательство в этой секции записывается не просто как ссылка или цитата, а как структурированный объект с четырьмя полями:

Само доказательство - что именно: ссылка, цитата, результат замера.
F / G / R - три числа от 0 до 1, по одному на каждую ось.
Итоговая оценка - min(F, G, R), рассчитывается автоматически.
Уровень контекстного соответствия (CL) - насколько это доказательство вообще относится к вашей ситуации.

Уровень контекстного соответствия - отдельный параметр поверх F/G/R. Он отвечает на вопрос: «Это доказательство вообще про нас?» Доказательство может быть строгим, детальным и из надёжного источника - но если оно про нагрузку в 10 000 RPS, а у вас 50 RPS, то применимость ограничена.

CL3 · НАШ КОНТЕКСТ

Штраф: 0%

Тот же сценарий, та же инфраструктура, тот же диапазон нагрузки. Доказательство измерено в условиях, максимально близких к вашим.
CL2 · ПОХОЖИЙ КОНТЕКСТ

Штраф: 10%

Похожая нагрузка, близкая архитектура. Доказательство релевантно, но нужно сделать поправку на разницу в условиях.
CL1 · ДРУГОЙ КОНТЕКСТ

Штраф: 40%

Другой масштаб, другая технологическая среда. Выводы переносятся с трудом; нужно явно обосновывать применимость.
CL0 · ПРОТИВОПОЛОЖНЫЙ

Штраф: 90%

Условия настолько разные, что прямой перенос выводов ошибочен. Доказательство практически не работает в DDR секции.

Финальная формула для одного доказательства: score = min(F, G, R) × (1 − штраф_CL). Для всего решения - минимум по всем доказательствам в секции, что даёт итоговый R_eff.

Простой пример расчёта на трёх доказательствах

Разберём конкретный кейс: команда выбирает между двумя базами данных для хранения векторных вложений - LanceDB и SQLite с расширением vector. Оба варианта технически рабочие, команда собрала три доказательства в пользу LanceDB.

КЕЙС · ВЫБОР ХРАНИЛИЩА ДЛЯ ВЕКТОРНОГО ПОИСКА

Три доказательства и их оценка по F / G / R / CL

Итоговый R_eff решения = min всех score = 0.27. Решение технически принято, но сигнал слабый: одно доказательство из трёх - маркетинговый материал вендора с плохим контекстным соответствием. Это повод либо найти замену для Д1, либо явно пометить его как «принято с низким доверием».

#	Доказательство	F	G	R	min	CL	Оценка
Д1	Исследование вендора: «LanceDB на 5× быстрее при аналитических запросах»	0.3	0.4	0.2	0.2	CL1 −40%	0.12
Д2	Публикация инженеров Qdrant с бенчмарком на 1M векторов, разбивка по HNSW параметрам	0.8	0.8	0.6	0.6	CL2 −10%	0.54
Д3	Замер нашей команды: 500K документов, наша нагрузка, сравнение p95 задержки и пропускной способности	0.9	0.9	0.95	0.9	CL3 −0%	0.90

R_eff = min(0.12, 0.54, 0.90) = 0.12 · Сигнал слабый - тянет вниз Д1 (исследование вендора)

Обратите внимание: даже один слабый источник обваливает R_eff всего решения. Это не баг - это фича. Правило слабого звена говорит: если в вашей доказательной базе есть маркетинговый материал, который вы принимаете всерьёз, это риск. Либо уберите его, либо явно признайте, что опираетесь на слабое доказательство.

В этом примере команда могла бы убрать Д1 из DDR и опереться только на Д2 и Д3 - тогда R_eff = min(0.54, 0.90) = 0.54. Это уже честная оценка: «мы решили с умеренным доверием, опираясь на независимый бенчмарк и собственный замер».

Глубже

Три материала для следующего шага - в зависимости от того, что сейчас ближе.

3D ИНТЕРАКТИВ

Trust Calculus в пространстве F/G/R - интерактивная визуализация →

ФОРМАТ DDR

Как вписать F/G/R в шестую секцию DDR при записи решения →

СРОК ГОДНОСТИ

Evidence decay: когда доказательство устаревает и R_eff падает →

Главное: расчёт доверия - это не бюрократия поверх обсуждения, а защита от распространённой ошибки. Команды проигрывают не потому что выбирают плохие технологии, а потому что доверяют красиво оформленным аргументам наравне с реальными замерами. Три числа и правило минимума делают эту разницу явной до того, как решение принято.