Сохранить опыт — ещё не значит научиться
Transcript или запись в vector store отвечает на вопрос «что происходило». Обучение начинается позже: система отделяет устойчивую причинную закономерность от случайного успеха, связывает вывод с исходными свидетельствами и проверяет, меняет ли он будущие решения.
Поэтому полезны три разных артефакта:
- неизменяемая траектория — действия, результаты инструментов и состояние среды;
- анализ одного прогона — outcome, первый ошибочный шаг, категория отказа и ссылки на evidence;
- межтраекторный candidate — правило, документ, программа или обучающая выборка с областью применимости и противоречащими случаями.
Сводка одного запуска не перепрыгивает сразу в третий слой. Эта граница совпадает с Memory Write Policy: trajectory — свидетельство, insight — производная гипотеза.
Сигнал обучения состоит из трёх проверок
Успешный финальный текст ещё не доказывает правильный прогон. Перед извлечением урока траектория получает три независимых вердикта:
| Слой | Вопрос | Предпочтительное evidence |
|---|---|---|
| Outcome | Реальное состояние задачи изменилось как требовалось? | тесты, БД, backend state, результаты инструментов |
| Process | Результат получен разрешённым способом? | policy, permissions, последовательность действий |
| Quality | Пользователь получил качественное решение? | заранее заданная rubric и ссылки на фрагменты траектории |
Вердикт, пригодный для обучения, хранит не только общий score, но и исход success / partial / failure, оценки по измерениям, точные места evidence и failure label. При недостатке свидетельств допустимый результат — unknown; такой случай не повышается в обучающий набор автоматически (Unknown Not A Value).
Четыре носителя изменения
Место правки выбирают по форме способности, а не по модности метода.
| Что надо изменить | Куда писать | Почему |
|---|---|---|
| факты, исключения, проверенные стратегии и источники | knowledge document | быстро обновляется, цитируется и отзывается |
| контекстные принципы, приоритеты и процедуры с исключениями | prompt или skill | естественный язык остаётся интерпретируемым |
| детерминированная процедура, hard constraint, validator | program или harness | исполняется и тестируется без решения модели |
| восприятие, стиль и невыразимая компактным правилом политика | model weights | способность нужна без длинного runtime-контекста |
Одна способность может пересекать слои: актуальные правила лежат в knowledge, разбор исключений — в skill, запрет обхода прав — в code, а распознавание сложного сигнала — в weights. Но критический инвариант не следует оставлять только в вероятностной инструкции, если его можно выразить проверкой.
Два контура вместо самоизменения в горячем пути
online execution
task -> actions -> environment -> immutable evidence
|
v
offline evolution
aggregate -> diagnose -> candidate -> independent gates -> staged release
^ |
+---- rollback/evals <----+Online-контур решает задачу и записывает evidence; он не редактирует production-способности. Offline-контур работает по пачке оценённых прогонов, делает локальный candidate и выпускает новую версию через обычный change control. «Sleep learning» — удобное имя для этой фоновой консолидации, а не требование запускать её ночью.
Candidate не может менять валидаторы, наборы проверки, release threshold, audit log и stable backup, которыми будет одобрять сам себя. Новые зависимости и код сначала живут в изолированной области; право обслуживать реальные задачи появляется после security- и regression-гейтов (Skill Change Control, Harness Optimization).
Правильная правка может не принести пользы
Нельзя склеивать качество updater и способность рабочего агента воспользоваться результатом. Оценка разделяется минимум на четыре ступени:
- candidate validity — предложено ли полезное изменение;
- activation — загрузил ли агент нужный документ, skill или tool в подходящем случае;
- adherence — последовал ли загруженному правилу;
- held-out gain — улучшилась ли итоговая задача вне выборки эволюции.
Без этого хороший skill, который никогда не маршрутизируется, ошибочно выглядит плохой правкой; а часто загружаемый, но игнорируемый документ — успешным retrieval.
Longitudinal eval, а не один before/after
Эволюция проверяется последовательностью фаз:
- learning — появились новые оценённые случаи;
- transfer — те же закономерности нужны при другой формулировке и окружении;
- rule change — старое правило становится неверным и должно быть заменено, а не дописано рядом;
- retention — ранее работающие и всё ещё действующие способности не забыты.
Рядом с качеством считаются negative transfer, время восстановления после смены правила, безопасность, token/latency/storage cost и инженерное качество. append_only, который помнит обе несовместимые версии, — не эволюция.
Где замкнутый цикл ненадёжен
Лучше всего схема работает там, где outcome читается из среды: код, инструментальные операции, формальные бизнес-состояния. В исследованиях, стратегии и продуктовой работе «всё выполнено» легко становится прокси вместо реального прогресса.
Для открытых задач нужны дополнительные границы:
- утверждения хранятся отдельно от evidence и provenance;
- отрицательные результаты и причины остановки доступны наравне с успехами;
- поиск сохраняет несколько содержательно разных кандидатов, а не только удобный для метрики максимум;
- человек определяет проблему, критерии оценки и момент остановки, а не только подтверждает опасные tool calls.
Autoresearch поставляет evidence, но не выпускает новую способность
В Autoresearch Experiment Trees цикл перебирает версии исследуемого кода или конфигурации под фиксированным run contract. Здесь же меняется способность самого рабочего агента. Связь односторонняя: experiment tree может дать версии, отрицательные результаты и измеренное evidence для offline evolution, но победивший узел не получает права автоматически переписать production skill, prompt, harness или validator.
Так сохраняется независимость гейта: поиск отвечает «какой candidate лучше в этом эксперименте», а evolution отдельно проверяет перенос, удержание старых способностей, безопасность и право на выпуск.
Что это меняет для этой базы
Наша безопасная цепочка уже частично соответствует паттерну: внешний материал и сырые наблюдения остаются evidence, а proposal отделён от live skill. Граф, checklist и реестр источников проверяют структурную целостность и provenance, но не доказывают downstream benefit. Поэтому при будущей автоматизации нужно отдельно наблюдать маршрутизацию нового артефакта, соблюдение его правил и перенос на новые задачи.
Связано с
- Agent Evals — откуда берётся структурированный learning signal
- Memory Write Policy — почему raw trajectory и distilled insight нельзя склеивать
- Skill Change Control — выпуск исполняемого знания через proposal и независимые gates
- Harness Optimization — локальные изменения harness по нескольким траекториям
- Agentic Context Management — долговечные артефакты как отдельный слой состояния
- LLM Training Stages — когда внешний артефакт уже недостаточен и нужны веса
- Autoresearch Experiment Trees — воспроизводимый поиск вариантов как источник evidence, но не механизм автоматического релиза