Перенос знания: почему выученное не применяется само

Полгода назад вы разбирались с идемпотентностью. Читали внимательно, поняли всё: почему at-least-once доставка означает, что обработчик увидит одно и то же сообщение дважды, зачем нужен ключ операции, как устроена таблица дедупликации, где у неё TTL и какие бывают гонки. Если бы вас спросили — рассказали бы наизусть.

Вчера вы написали ночной джоб начисления бонусов. CronJob в Kubernetes, внутри проход по таблице и UPDATE balance = balance + bonus. Джоб упал на середине из-за таймаута к базе, планировщик перезапустил его по политике restartPolicy, и часть пользователей получила бонусы дважды.

Знание было. Оно было доступно по прямому запросу. Оно не включилось.

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

Эта глава — про механику этого разрыва и про то, что с ним можно сделать. Она продолжает главу «Что значит понимать», где перенос был описан как третий, самый дорогой уровень владения темой, а поверхностная и глубинная структура задач введены как понятия. Здесь мы разбираем не что такое перенос, а почему он ломается и что известно про способы его чинить.

Сразу — граница честности, которую придётся держать всю главу. Почти всё, что известно про перенос, измерено на задачах Дункера, физических задачках, переговорных кейсах и школьной математике. Контролируемых исследований переноса инженерных навыков практически нет. Устойчивый результат — качественный: перенос трудный, он не происходит сам, и его вероятность растёт от конкретных вмешательств. Насколько именно растёт у инженера — не измерено никем. Всё, что в этой главе выходит за границы данных, помечено явно.

Что ломается между «знаю» и «применил»

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

История с бонусным джобом — это разрыв 2. Знание про идемпотентность лежало под ярлыком «очереди и HTTP-ретраи», а ситуация выглядела как «SQL и cron». Ни одно слово не совпало, и память не отозвалась.

Инертное знание: не метафора, а измеренный эффект

Термин старше, чем психология обучения в современном виде. Whitehead (1929) в The Aims of Education называл «инертными идеями» то, что усвоено, но «не используется, не проверяется и не соединяется со свежими комбинациями». Он писал это про университетское образование и без всяких данных — это было наблюдение преподавателя.

Данные появились позже. Самый чистый эксперимент, который стоит знать, — Perfetto, Bransford и Franks (1983) в Memory & Cognition. Участникам сначала давали читать набор обычных предложений — вроде того, что мужчина может жениться на многих женщинах, если он священник и проводит венчания. Потом, отдельным заданием, предлагали задачи-загадки, ответ на которые прямо содержался в прочитанных предложениях. Группа, которой не сказали о связи, решала задачи не лучше тех, кто предложений вообще не читал. Группе, которой сказали «то, что вы читали, может помочь», решала заметно лучше.

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

Это же явление в учебном контексте систематизировали Renkl, Mandl и Gruber (1996) в Educational Psychologist: они разобрали конкурирующие объяснения инертности — «знание не в той форме», «знание не привязано к ситуации», «метапознание не подсказывает его достать» — и показали, что объяснения не исключают друг друга, а описывают разные вклады в один эффект. Для нас достаточно вывода: разрыв между владением и применением — норма, а не патология конкретного человека.

Почему память ищет по поверхности

Дальше — самый полезный факт этой главы, и он про механизм.

Ross (1984, 1987) в серии экспериментов давал людям учиться на решённых примерах, а потом предлагал новые задачи. Оказалось, что при выборе, какой из старых примеров вспомнить, люди опирались на поверхностные признаки: тот же сюжет, те же объекты, та же лексика. Если задача про садовников решалась той же формулой, что задача про автомобили, вспоминалась та, где были садовники — независимо от того, какая структура нужна.

Ключевая работа, которая разделила два эффекта, — Gentner, Rattermann и Forbus (1993) в Cognitive Psychology. Они разводили два вопроса: (1) какой из старых материалов человек вспомнит и (2) какой из них он же сочтёт полезным, если ему показать оба. Результат — диссоциация:

• Извлечение из памяти управляется поверхностным сходством. Вспоминается то, что похоже словами и объектами.
• Оценка полезности управляется структурным сходством. Когда оба варианта перед глазами, человек уверенно выбирает структурно подходящий и отвергает поверхностно похожий.

То есть механизм поиска и механизм рассуждения ориентируются на разные признаки — и поиск ориентируется на «неправильные». Отсюда прямое следствие для инженера: вы не хуже других рассуждаете по аналогии; у вас плохо работает поиск аналога. Как только нужный аналог перед глазами, вы им пользуетесь правильно.

Теоретическая рамка, объясняющая «правильную» часть, — теория отображения структур Gentner (1983), Cognitive Science. Аналогия — это отображение системы отношений между объектами источника на объекты цели. Переносятся отношения, а не свойства объектов; сильной считается аналогия, в которой отображается связная система отношений, а не разрозненные совпадения.

Novick (1988) в JEP: Learning, Memory, and Cognition показала эту же картину на разнице между новичками и опытными: опытные быстрее отбрасывали поверхностно похожие, но структурно чужие примеры, а новички дольше держались за них и получали отрицательный перенос. Заметьте, что это не «эксперты не ошибаются» — это «эксперты быстрее замечают, что аналогия не легла».

Что из этого следует практически

Раз спонтанное извлечение идёт по поверхности, есть ровно два рычага.

Первый: подавать подсказку себе вручную. У Gick и Holyoak решающим было внешнее «вспомните историю, которую вы читали». В работе такого человека рядом нет — значит, подсказка должна стать процедурой. Практически: приучиться в начале нетривиальной задачи задавать вопрос «как это звучит без единого названия технологии?». Формулировка «планировщик может повторить операцию, которая меняет состояние» ищет по памяти совсем не там, где ищет «ночной cron делает UPDATE».

Второй: заранее класть знание туда, где его будут искать. Если ситуация подаёт в память симптомы, то и индексировать знание надо симптомами, а не темами. Об этом — раздел про индекс ниже.

Что такое ментальная модель — и что этим словом называют зря

Слово затаскано, поэтому начнём с того, где у него есть содержание.

Craik (1943) в The Nature of Explanation ввёл идею: организм строит «small-scale model» внешней реальности и прогоняет её, чтобы предсказать последствия действий до того, как их совершит. Johnson-Laird (1983) в книге Mental Models сделал из этого теорию рассуждения: человек рассуждает, конструируя модели ситуаций и проверяя, есть ли контрпример. Gentner и Stevens (1983) собрали сборник Mental Models; глава Дональда Нормана (Norman, 1983) «Some observations on mental models» описывает свойства реальных моделей у реальных людей: они неполны, нестабильны, границы у них размыты, они «суеверны» — содержат ритуальные действия, которые человек выполняет, не веря в них, но на всякий случай, — и при этом ими вполне можно пользоваться.

Для инженера рабочее определение получается конкретным и проверяемым:

Ментальная модель — это то, что позволяет вам предсказать поведение системы до того, как вы её запустили, и объяснить наблюдаемое поведение после.

Всё, что не даёт предсказаний, — не модель, а словарь. Это удобный критерий: если ваша «модель консенсуса» не позволяет сказать, что произойдёт с кластером при потере кворума на 30 секунд, у вас нет модели консенсуса, у вас есть знакомство со словом «кворум».

Три части модели, про которые чаще всего забывают:

• Границы. Условия, при которых модель перестаёт описывать реальность. Модель «база данных атомарно применяет транзакцию» ломается на уровне изоляции ниже serializable — см. «Транзакции и изоляция».
• Режимы отказа. Не «что бывает», а «как именно это выглядит в логах и метриках». Модель без режимов отказа бесполезна на инциденте.
• Наблюдаемые следствия. Чем ваша модель отличается от соседней. Если две модели предсказывают одно и то же во всех случаях, различать их незачем; если различаются — вы знаете, какое измерение их разведёт.

Чего в этом слове нет

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

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

И ещё одна честная оговорка. Box (1976) в Journal of the American Statistical Association сформулировал то, что стоит держать при себе постоянно: все модели неверны, но некоторые полезны. Модель «TCP гарантирует доставку» неверна (гарантирует при живом соединении, а соединение рвётся), но полезна в 95% разговоров. Вопрос не «правильная ли модель», а «где именно она врёт и заметите ли вы это вовремя».

Отрицательный перенос: когда старая модель активно мешает

Перенос бывает не только отсутствующим, но и вредным. Это отдельный измеренный эффект, и в инженерии он встречается чаще, чем в лаборатории.

Luchins (1942) — классические задачи с кувшинами. Испытуемые решали серию задач, где работал один и тот же трёхшаговый рецепт, а потом получали задачу, где рецепт тоже работал, но был и очевидный двухшаговый путь. Большинство продолжало применять привычный длинный способ; часть не решала задачу, которая простым способом решается сразу. Эффект назвали Einstellung — установка, механизация решения.

Bilalić, McLeod и Gobet (2008) в Cognition воспроизвели это на шахматистах с айтрекером — работа называется «Why good thoughts block better ones». Игрокам давали позицию, где есть знакомый долгий мат и более короткий незнакомый. Игроки говорили, что ищут альтернативы, а движения глаз показывали, что они продолжают проверять поля, относящиеся к первому найденному решению. Это важная деталь: человек субъективно уверен, что рассматривает варианты, а объективно — нет. Интроспекция здесь не помогает.

Инженерные примеры отрицательного переноса — не догадки, а описанная история отрасли:

Первая строка — самый задокументированный случай в истории индустрии. Waldo, Wyant, Wollrath и Kendall (1994), «A Note on Distributed Computing» (техотчёт Sun Labs), написали её после волны фреймворков, обещавших «прозрачные» удалённые вызовы: попытка представить удалённый вызов как локальный проваливается не из-за качества реализации, а потому что различия — задержка, разные адресные пространства, частичный отказ, конкурентность — принципиальны. Примерно тогда же Питер Дойч сформулировал «заблуждения распределённых вычислений» (сеть надёжна, задержка нулевая, полоса бесконечна и так далее) — список, который до сих пор точно описывает, какие допущения локальной модели тихо переезжают в распределённую. Подробности — в треке «Распределённые системы».

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

Приёмы, у которых есть данные

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

1. Сравнение двух примеров с явной формулировкой общего

Механизм. Один пример не даёт материала для абстракции: непонятно, какие его черты существенны. Два примера, различающиеся поверхностно и совпадающие структурно, позволяют выделить инвариант. Это называют аналогическим кодированием.

База. Gick и Holyoak (1983): чтение двух историй с общей структурой и прямая просьба описать, что у них общего, поднимала спонтанный перенос заметно выше, чем одна история. Loewenstein, Thompson и Gentner (1999) в Psychonomic Bulletin & Review и Gentner, Loewenstein и Thompson (2003) в Journal of Educational Psychology перенесли это на обучение взрослых переговорам: студенты, которых просили сравнить два кейса и описать сходство, применяли стратегию в новой ситуации существенно чаще, чем те, кто разбирал те же два кейса по отдельности. Разница именно в акте сравнения, а не в объёме материала.

У инженера. Не «прочитать про circuit breaker», а положить рядом два постмортема с каскадным отказом из разных компаний и написать абзац: что общего в механизме, чем различаются условия. Не «изучить Kafka», а сравнить модель офсетов в Kafka с моделью подтверждений в RabbitMQ и сформулировать, какая инвариантная задача решается обеими.

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

2. Попытка решить до объяснения

Механизм. Попытка справиться самому создаёт различения, к которым потом «прикрепляется» объяснение. Без них объяснение ложится на пустое место и запоминается как текст.

База. Schwartz и Bransford (1998), «A Time for Telling» в Cognition and Instruction: студенты, которые сначала сами анализировали контрастные случаи и только потом читали объяснение, на отложенном тесте на предсказание справлялись лучше, чем те, кто сразу получил хорошее объяснение или пересказывал текст. Schwartz и Martin (2004) в той же журнальной серии развили это в «изобретение как подготовка к будущему обучению»: попытка изобрести метод, даже неудачная, улучшала усвоение канонического метода после.

У инженера. Перед чтением архитектурного разбора — 20 минут на свой набросок решения той же задачи, с фиксацией, где вы застряли. Перед чтением исходников библиотеки — попытка предсказать, как она устроена внутри, с записью предположений.

Цена. Дороже по времени в моменте и субъективно неприятно: вы заведомо делаете хуже, чем сделали бы, прочитав готовое. Это ровно та ситуация, которая разбирается в главе «Желательные трудности». Не окупается для тем, которые вам нужны один раз: если вы никогда больше не будете настраивать этот CI, читайте готовое.

3. Самообъяснение

Механизм. Проговаривание «почему здесь именно так» вместо чтения дальше заставляет достраивать пропущенные шаги — а именно в них живёт структура.

База. Chi, Bassok, Lewis, Reimann и Glaser (1989) в Cognitive Science сравнили, как сильные и слабые студенты работают с решёнными примерами по физике: сильные спонтанно объясняли себе каждый шаг, слабые перечитывали. Chi и коллеги (1994) показали, что самообъяснение можно вызвать инструкцией и это улучшает понимание, — то есть это не просто корреляция с сообразительностью. Метаанализ Bisra, Liu, Nesbit, Salimi и Winne (2018) в Educational Psychology Review даёт средний положительный эффект порядка половины стандартного отклонения; как всегда с метаанализами в образовании, разброс по условиям большой, и стоит смотреть на исследования, близкие к вашей задаче.

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

Цена. Замедляет чтение примерно вдвое. Не окупается на материале, который вы просматриваете для ориентировки, а не для владения.

4. Имя для структуры

Механизм. Абстрактный ярлык — это адрес в памяти, по которому потом можно постучаться. У Gick и Holyoak явная формулировка общей схемы («сложить несколько слабых воздействий, идущих разными путями») повышала перенос сильнее, чем два примера без формулировки.

У инженера. Заметки и разделы, названные механизмами: «повторное применение эффекта», «чтение из отставшей копии», «неограниченная очередь перед медленным потребителем», «конкурирующие писатели без арбитра». Не «Kafka», не «Postgres». Разбор того, как это соотносится с внешней памятью, — в главе «Заметки и внешняя память».

Цена. Требует дисциплины при записи и регулярного переименования, когда механизм оказался назван неточно. Плохое имя хуже отсутствия имени: оно склеивает разные вещи.

Граница данных. Есть смежная линия исследований — «затухание конкретности» (concreteness fading): начинать с конкретного представления и постепенно переходить к абстрактному; обзор Fyfe, McNeil, Son и Goldstone (2014) в Educational Psychology Review. Почти всё измерено на школьной математике. Переносить вывод на инженерное обучение можно только как гипотезу.

5. Вариативность условий

Пятый приём — практика на задачах, различающихся поверхностно при одинаковой структуре. Он общий с главами «Желательные трудности» и «Перемежение и вариативность», поэтому здесь только короткая формулировка: одинаковая структура, разные декорации — единственный известный способ получить в голове категорию, а не список случаев. Классическая формулировка гипотезы — Schmidt и Bjork (1992) в Psychological Science.

Индекс по симптомам: приём без данных, но с понятным механизмом

Дальше — практика, которую нужно пометить честно: контролируемых исследований именно этой техники нет. Она выведена из принципа специфичности кодирования (Tulving и Thomson, 1973, разобран в главе «Что значит понимать») и из результата Gentner, Rattermann и Forbus про поиск по поверхности. Логика простая: если память адресуется признаками ситуации, храните знание под адресом «признаки ситуации».

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

В виде заметки это выглядит так:

# Файл: mechanisms/repeated-effect.yaml — имя по механизму, не по технологии
механизм: повторное применение неидемпотентного эффекта

симптомы:
  - "дубли строк с разными id и одинаковым бизнес-смыслом"
  - "сумма списаний больше суммы заказов за период"
  - "жалоба: списали дважды, заказ один"
  - "рост числа записей сразу после деплоя, рестарта или ребаланса"

возникает_когда:
  - "инициатор может повторить операцию: ретрай клиента, рестарт джоба, ребаланс консьюмера"
  - "операция меняет состояние и не проверяет, применялась ли она раньше"

проявляется_в:
  - "HTTP POST без ключа идемпотентности"
  - "Kafka at-least-once после ребаланса"
  - "CronJob с restartPolicy: OnFailure"
  - "webhook от платёжного провайдера с повторной доставкой"

решения:
  - действие: "ключ операции + таблица дедупликации"
    когда_не_подходит: "нет естественного ключа со стороны инициатора"
  - действие: "сделать операцию естественно идемпотентной (SET вместо +=)"
    когда_не_подходит: "нужна именно аккумуляция"
  - действие: "уникальный индекс на бизнес-ключ и обработка конфликта"
    когда_не_подходит: "ключ не уникален по бизнесу"

цена:
  - "хранение и TTL ключей, отдельный режим отказа: ключ протух раньше ретрая"
  - "гонка двух параллельных попыток с одним ключом требует блокировки или UPSERT"

как_отличить_от_похожего:
  - "не путать с гонкой двух разных операций: там ключи разные, а порядок неверный"

Цена приёма. Такая заметка пишется 20–40 минут и требует возврата, когда механизм встретился в новом обличье, — тогда в проявляется_в добавляется строка. Это ровно та работа, которая превращает список случаев в категорию. Не окупается для одноразовых знаний: сколько бы симптомов вы ни выписали про флаг сборки, вы им воспользуетесь один раз.

Отдельно про честность жанра: заметки — инструмент, а не ритуал. Разбор того, что у популярных систем заметок (включая Zettelkasten) нет контролируемых исследований эффективности, — в главе «Инструменты» трека о тайм-менеджменте. Формат выше — не исключение из этого правила: у него есть обоснование через механизм и нет подтверждения через эксперимент.

Как это выглядит в момент применения

Соберём всё в одну сцену: инцидент, три часа ночи, дубли списаний.

Шаги 4–5 — это то, чему стоит научиться специально. Внешней подсказки, как в экспериментах, на работе нет; её роль выполняет привычка переформулировать задачу в терминах механизмов. Шаг 10 — то, что превращает разовое решение в расширение индекса.

Мифы про перенос

«Изучение X делает мышление лучше вообще». Самая живучая конструкция: выучи Haskell — станешь лучше писать на Java; порешай олимпиадные задачи — станешь лучше проектировать. Прямых данных нет ни за, ни против — исследований такого рода на инженерах не проводили. Есть косвенные, и они не в пользу оптимизма: обзор Sala и Gobet (2017) по шахматам, музыке и тренировке рабочей памяти (разобран в главе «Что значит понимать») находит ближний перенос и не находит дальнего. Механизм, по которому изучение другой парадигмы всё-таки может помогать, правдоподобен — новый язык даёт имена структурам, которых в старом не было, а имя, как мы разобрали, служит адресом. Но это гипотеза, а не результат. Формулируйте соответственно: «я изучаю Rust, чтобы понимать владение памятью» — честно; «я изучаю Rust, чтобы стать лучше как инженер вообще» — необоснованное обещание себе.

«Тренировка мозга». Ближайший к этому вопрос проверен хорошо и с плохим для индустрии результатом. Owen и коллеги (2010) в Nature провели онлайн-эксперимент с более чем 11 тысячами участников: тренируемые задачи улучшались, нетренируемые когнитивные тесты — нет (nature.com). Обзор Simons и коллег (2016) в Psychological Science in the Public Interest систематически разобрал доказательства коммерческих программ и нашёл много данных о том, что люди становятся лучше в тренируемых заданиях, и очень мало — о переносе на что-либо ещё (journals.sagepub.com).

«Стили обучения». В теме переноса это всплывает в виде «мне нужно просто увидеть схему, я визуал». Гипотеза соответствия формата предпочтениям не подтверждена (Pashler, McDaniel, Rohrer и Bjork, 2008; подробно — в главе «Что значит понимать»). Формат выбирают по природе материала: схему рисуют, потому что отношения пространственные, а не потому, что вы визуал.

«10 000 часов дают перенос». Двойное искажение. Во-первых, это искажённый пересказ Ericsson, Krampe и Tesch-Römer (1993) — у них речь про осознанную практику в областях с устоявшейся методикой и быстрой обратной связью, а не про наработку часов. Во-вторых, даже там, где часы работают, они дают мастерство в тренируемой деятельности, а не перенос на соседние. Разбор — в главе «Осознанная практика».

«Аналогия — это аргумент». Аналогия — прекрасный инструмент поиска решения и очень слабый инструмент доказательства. «Микросервисы — как разделение труда на заводе» может подсказать гипотезу и ничего не доказывает про вашу систему. Разбор ошибок такого рода — в главе «Ошибки релевантности».

ИИ и перенос: что именно он забирает

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

Отсюда — точная формулировка проблемы, без паники и без рекламы.

Что ИИ делает хорошо. Закрывает разрыв 2 (инертное знание) и частично разрыв 1 (постановка). Он назовёт класс задачи по описанию симптома лучше, чем это сделает ваша память в три часа ночи. Он же — идеальный поставщик второго примера для приёма сравнения: «дай другой контекст, где работает тот же механизм, максимально непохожий по поверхности» — запрос, на который он отвечает качественно. И хороший партнёр для самообъяснения: вы объясняете, он ищет дыры в объяснении.

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

Что ИИ делает плохо. Ровно то же, что человек: предлагает аналогию по поверхности. Модель уверенно приложит знакомый паттерн к задаче, где совпали слова, а не структура; проверка допущений — «а верно ли, что у нас есть естественный ключ операции?» — остаётся на вас, и она требует той самой модели, которую вы не строили. Про режимы отказа и про проверку вывода — «Проверка результата» и «Ревью кода от ИИ»; про то, почему модель звучит уверенно независимо от правоты, — «Как работают языковые модели».

Рабочий компромисс (это инженерная рекомендация, а не вывод из исследования): выполняйте шаг формулировки сами и вслух, до того как спросили. Тридцать секунд на «это, кажется, про повторное применение эффекта» — и дальше спрашивайте модель. Вы получаете скорость и сохраняете тренировку той единственной операции, которая ломается. Развёрнуто — в главе «Учиться с ИИ», а вопрос, зачем вообще учиться при наличии модели, — в главе «Зачем учиться, когда есть ИИ».

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

Конкретная последовательность, 30–60 минут после того, как задача решена. Не «полезная привычка», а операция с понятной ценой.

1. Назовите механизм без технологий. Одна фраза, в которой нет слов Kafka, Postgres, Kubernetes. Если фраза не получается — вы решили симптом, а не задачу.
2. Найдите второй случай. Где ещё этот механизм встречался — в вашей практике, в постмортеме, в документации. Если не находится, спросите модель именно об этом.
3. Напишите абзац сравнения. Что структурно общего, чем различаются условия. Письменно: в экспериментах эффект даёт именно явная формулировка, а не молчаливое сопоставление.
4. Выпишите границы. При каких условиях решение перестаёт работать. Минимум два условия.
5. Добавьте симптомы в индекс. Как это выглядело до того, как вы поняли, в чём дело. Это адрес, по которому вы будете искать в следующий раз.
6. Через неделю — проверка извлечением. Не перечитать заметку, а восстановить механизм с нуля и сверить (см. «Извлечение из памяти» и «Интервальное повторение»).

Упражнение на структурное сходство

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

# Обработчик вебхука от платёжного провайдера
def handle_payment_webhook(payload: dict, db) -> None:
    order_id = payload["order_id"]
    amount = payload["amount"]

    # Провайдер повторяет доставку, пока не получит 2xx
    with db.transaction():
        db.execute(
            "UPDATE orders SET paid_amount = paid_amount + %s WHERE id = %s",
            (amount, order_id),
        )
        db.execute(
            "INSERT INTO ledger (order_id, amount) VALUES (%s, %s)",
            (order_id, amount),
        )

// Консьюмер, начисляющий бонусы за события покупки
func (c *Consumer) handle(ctx context.Context, msg kafka.Message) error {
    var ev PurchaseEvent
    if err := json.Unmarshal(msg.Value, &ev); err != nil {
        return err // не ретраится: битое сообщение
    }
    // Офсет коммитится после успешной обработки:
    // при ребалансе сообщение будет доставлено снова
    _, err := c.db.ExecContext(ctx,
        `UPDATE bonus_accounts SET balance = balance + $1 WHERE user_id = $2`,
        ev.Bonus, ev.UserID)
    return err
}

Общее. В обоих случаях есть инициатор, который может повторить доставку (провайдер по таймауту, Kafka после ребаланса), и эффект вида «прибавить», который не проверяет, применялся ли он раньше. Транзакция в первом фрагменте создаёт ложное чувство защищённости: она делает атомарным одно применение, но никак не мешает применить дважды.

Различия, которые не важны. Язык, брокер против HTTP, деньги против бонусов, наличие транзакции.

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

Типичные ошибки

• Коллекционировать модели вместо решения задач. Список из ста ментальных моделей, выписанных из книжки, не даёт ни одного адреса в памяти, потому что не связан ни с одним симптомом.
• Модель без границ. «CAP-теорема говорит, что надо выбрать два из трёх» — модель, у которой нет условий применимости, и потому она порождает неверные решения. Разбор — «CAP и PACELC».
• Одна модель на всё. Закон инструмента: у Каплана (1964) — «дай мальчику молоток», у Маслоу (1966) — «если единственный инструмент молоток, всё вокруг похоже на гвозди». Симптом распознаётся легко: любая новая задача у вас оказывается задачей про очереди (или про типы, или про кэш).
• Считать аналогию доказательством. См. выше про ошибки релевантности.
• Учить перенос без обратной связи. Сформулированный механизм, который никто не проверил, может быть неверным — и вы закрепите неверную категоризацию. Про это — «Обратная связь».
• Ждать переноса от объёма. Прочитано много, задач решено мало — перенос не появляется. Он появляется от разных задач и явного сравнения, а не от количества прочитанного.

Мини-итог

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

Источники

Работы даны с авторами и годом; по названию и году они находятся в Google Scholar и на страницах лабораторий. Там, где точное издание или конкретные числа вызывают сомнение, это сказано в тексте прямо.

• Whitehead, A. N. (1929). The Aims of Education and Other Essays — понятие инертных идей.
• Perfetto, G., Bransford, J., Franks, J. (1983). Constraints on access in a problem solving context. Memory & Cognition.
• Renkl, A., Mandl, H., Gruber, H. (1996). Inert knowledge: Analyses and remedies. Educational Psychologist.
• Gentner, D. (1983). Structure-mapping: A theoretical framework for analogy. Cognitive Science.
• Gentner, D., Rattermann, M. J., Forbus, K. (1993). The roles of similarity in transfer: Separating retrievability from inferential soundness. Cognitive Psychology.
• Ross, B. H. (1987). This is like that: The use of earlier problems and the separation of similarity effects. JEP: Learning, Memory, and Cognition.
• Novick, L. R. (1988). Analogical transfer, problem similarity, and expertise. JEP: Learning, Memory, and Cognition.
• Gick, M., Holyoak, K. (1980, 1983). Analogical problem solving; Schema induction and analogical transfer. Cognitive Psychology.
• Loewenstein, J., Thompson, L., Gentner, D. (1999). Psychonomic Bulletin & Review; Gentner, D., Loewenstein, J., Thompson, L. (2003). Journal of Educational Psychology.
• Schwartz, D., Bransford, J. (1998). A time for telling. Cognition and Instruction; Schwartz, D., Martin, T. (2004). Inventing to prepare for future learning.
• Chi, M., Bassok, M., Lewis, M., Reimann, P., Glaser, R. (1989). Self-explanations. Cognitive Science; Chi, M. и др. (1994). Eliciting self-explanations improves understanding.
• Bisra, K., Liu, Q., Nesbit, J., Salimi, F., Winne, P. (2018). Inducing self-explanation: a meta-analysis. Educational Psychology Review.
• Luchins, A. (1942). Mechanization in problem solving. Psychological Monographs; Bilalić, M., McLeod, P., Gobet, F. (2008). Why good thoughts block better ones. Cognition.
• Craik, K. (1943). The Nature of Explanation; Johnson-Laird, P. (1983). Mental Models; Gentner, D., Stevens, A. (eds.) (1983). Mental Models — в т. ч. глава Д. Нормана.
• Box, G. E. P. (1976). Science and statistics. Journal of the American Statistical Association.
• Waldo, J., Wyant, G., Wollrath, A., Kendall, S. (1994). A Note on Distributed Computing. Технический отчёт Sun Microsystems Laboratories.
• Owen, A. и др. (2010). Putting brain training to the test. Nature — nature.com/articles/nature09042.
• Simons, D. и др. (2016). Do “brain-training” programs work? Psychological Science in the Public Interest — journals.sagepub.com.
• Лаборатория Роберта и Элизабет Бьорк (UCLA) — публикации по желательным трудностям и переносу: bjorklab.psych.ucla.edu.

Что дальше

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