temporality
Изменить страницу↗
Инженерные документы

Разделение Experience, Knowledge, Skills и контекстной эволюции агента

#1. Цель

Уточнить и зафиксировать в Temporality модель накопления опыта и эволюции агентов.

Ключевая идея:

Experience не является памятью агента и не должен превращаться в единую глобальную базу воспоминаний. Experience — это временная доказательная база, из которой могут формироваться Knowledge и предложения по эволюции Skills.

Агент должен развиваться не за счёт бесконечного увеличения количества воспоминаний, а за счёт консолидации опыта в устойчивые знания и эволюционирующие процедурные способности (Skills).

При этом применимость опыта должна быть контекстной: организация → организационная единица → проект → задача/run, а не глобальной по умолчанию.

#2. Основная модель

В системе необходимо явно разделить следующие сущности.

#Experience

Experience — это наблюдаемая история работы агента:

Experience является временным и может быть большим.

Experience не должен целиком попадать в execution context агента.

Experience нужен для:

#Knowledge

Knowledge — это обобщённый вывод из Experience, который имеет ценность за пределами конкретного run.

Knowledge должен иметь:

Knowledge не является просто «сохранённым сообщением агента».

Если вывод применим только к конкретному run, он остаётся Experience и не должен автоматически становиться Knowledge.

#Skill

Skill — это процедурная способность агента, а не разновидность памяти.

Skill отвечает на вопрос:

«Как агент должен действовать при определённых условиях?»

Skill может развиваться на основании накопленного Experience и Evidence.

Цикл:

Skill vN
    ↓
execution
    ↓
Experience
    ↓
Evidence
    ↓
evaluation
    ↓
┌───────────────┐
│ no change     │
│ или           │
│ evolution     │
└───────┬───────┘
        ↓
Skill vN+1

Skill должен быть версионируемым.

Изменение Skill должно иметь возможность быть связано с конкретными Experience/Evidence, которые послужили основанием для изменения.

#Hint

Hint — это краткая проекция релевантного Knowledge в execution context конкретного запуска.

Hint не является новой памятью.

Упрощённо:

Experience
    ↓
Knowledge
    ↓
relevance + scope
    ↓
Hint
    ↓
Agent execution

Количество Hint должно быть ограниченным.

Необходимо сохранять возможность определить:

#3. Главный принцип

В системе должно быть явно закреплено:

Experience ≠ Knowledge
Knowledge ≠ Skill
Skill ≠ Memory
Hint ≠ Memory

И также:

Experience → Knowledge
Experience → Skill evolution
Knowledge → Hint
Skill → execution
execution → Experience

Таким образом формируется два связанных цикла:

#Цикл знаний

Experience
    ↓
Knowledge
    ↓
Hint
    ↓
Execution
    ↓
Experience

#Цикл эволюции навыков

Skill vN
    ↓
Execution
    ↓
Experience
    ↓
Evidence
    ↓
Evaluation
    ↓
Skill proposal
    ↓
Skill vN+1

#4. Контекст опыта

Experience, Knowledge и Skills не должны рассматриваться как глобальные по умолчанию.

Необходимо использовать организационный контекст Temporality:

Organization
    ↓
Organization Unit
    ↓
Project
    ↓
Task / Run

Scope является не только механизмом доступа.

Scope определяет область применимости опыта.

Например:

Organization Knowledge
    ↓
может быть применимо к нескольким проектам

Project Knowledge
    ↓
применимо внутри конкретного проекта

Run Experience
    ↓
относится к конкретному запуску

#5. Правило локальности

Новый Experience по умолчанию должен оставаться в том контексте, в котором он возник.

Нельзя автоматически превращать:

Project A experience

в:

Organization knowledge

только потому, что оно выглядит семантически полезным.

Обобщение должно быть отдельным осмысленным процессом.

Правильная модель:

Project A
    ↓
repeated evidence
    ↓
Project Knowledge
    ↓
evidence across contexts
    ↓
Organization Knowledge

То есть:

Сначала локальность, затем доказанное обобщение.

Необходимо избегать автоматического глобального распространения проектных знаний.

#6. Приоритет контекста над семантическим сходством

При выборе Knowledge для нового запуска нельзя руководствоваться только semantic similarity.

Например, Knowledge из:

Project B

может быть очень похожим на задачу:

Project A

но это не означает, что его следует передавать агенту Project A.

Приоритет должен быть примерно таким:

scope
    ↓
applicability
    ↓
lifecycle / validity
    ↓
evidence
    ↓
relevance

Semantic similarity является только одним из факторов отбора.

#7. Experience не должен превращаться в prompt

Нельзя реализовывать модель:

1000 runs
    ↓
10000 memories
    ↓
prompt

Execution context должен формироваться из ограниченного набора наиболее релевантных элементов:

Agent definition
+
relevant Skills
+
relevant Knowledge / Hints

Большой исторический Experience Store остаётся за пределами prompt и используется системой отбора и эволюции.

#8. Эволюция Skills

Необходимо связать существующий механизм Living Skills с Experience и Evidence.

Для каждого изменения Skill должна существовать возможность установить:

какой Skill изменился
        ↓
какая версия была до изменения
        ↓
какая версия появилась
        ↓
какие Experience/Evidence послужили основанием
        ↓
какое изменение было сделано

Желаемая модель:

Skill v7
    │
    ├── executions
    │
    ├── Experience
    │
    ├── Evidence
    │
    └── Evaluation
            ↓
      evolution proposal
            ↓
         Skill v8

Skill evolution должна быть объяснимой и трассируемой.

#9. Не превращать Knowledge в Skill автоматически

Knowledge и Skill имеют разное назначение.

Например:

Knowledge:

"В этом проекте изменение API X также требует
обновления generated client."

может существовать как Knowledge.

Если подобное правило многократно подтверждается и становится устойчивой процедурой:

Skill:

"При изменении API contract:
1. обновить schema;
2. regenerate client;
3. запустить integration tests."

оно может стать частью Skill.

Таким образом:

Knowledge может быть основанием для эволюции Skill, но не каждое Knowledge должно становиться Skill.

#10. Проверка текущей реализации

Необходимо провести аудит существующей реализации после изменений в модели событий знаний.

Особенно проверить:

Цель аудита — не переписать существующую реализацию, а определить, насколько она уже соответствует описанной модели.

Если текущая реализация уже соответствует требованиям, изменений в коде не требуется.

#11. Отдельно проверить защиту от деградации качества базы знаний

После текущего автоматического extraction необходимо проверить, что система не начинает создавать Knowledge из любого достаточно содержательного run.

Нужно проверить реальные сценарии:

#Сценарий A — одноразовая задача

Run содержит много технических деталей, но они специфичны только для этой задачи.

Ожидается:

Experience: yes
Knowledge: 0 или минимум

#Сценарий B — повторяющаяся закономерность

Несколько запусков обнаруживают одинаковое устойчивое правило.

Ожидается:

Experience
    ↓
Knowledge
    ↓
reinforcement

#Сценарий C — Knowledge перестало быть актуальным

Позднейший Experience противоречит Knowledge.

Ожидается:

Knowledge
    ↓
contradiction
    ↓
lifecycle update / invalidation

#Сценарий D — проектное Knowledge

Правило действительно для Project A, но не доказано для Project B.

Ожидается:

Project A: available
Project B: not automatically available

#12. Acceptance Criteria

Задача считается выполненной, если:

#Модель

#Контекст

#Knowledge

#Skills

#Execution Context

#Наблюдаемость

Для конкретного Skill evolution должна быть восстанавливаема цепочка:

Skill vN
    ↓
execution
    ↓
Experience
    ↓
Evidence
    ↓
evaluation
    ↓
proposal
    ↓
Skill vN+1

Для Knowledge:

Experience
    ↓
Knowledge
    ↓
scope
    ↓
Hint
    ↓
execution
    ↓
outcome

#13. Что НЕ нужно делать в рамках задачи

Не делать:

Главная задача — выровнять существующую архитектуру с этой моделью, а не добавить ещё один слой абстракций.

#14. Итоговая концепция

Temporality должна двигаться к модели:

                 ┌──────────────────┐
                 │      Skill       │
                 │      vN          │
                 └────────┬─────────┘
                          │
                      execution
                          │
                          ▼
                 ┌──────────────────┐
                 │    Experience    │
                 │  temporal facts  │
                 └───────┬──────────┘
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
        ┌───────────┐        ┌──────────────┐
        │ Knowledge │        │   Evidence   │
        └─────┬─────┘        └──────┬───────┘
              │                     │
              ▼                     ▼
           Context              Evaluation
              │                     │
              ▼                     ▼
           Hints              Skill Proposal
              │                     │
              │                     ▼
              │              ┌──────────────┐
              │              │   Skill vN+1 │
              │              └──────────────┘
              │
              ▼
          next execution

Ключевой принцип:

Temporality не должна помогать агенту помнить всё, что с ним происходило. Она должна помогать агенту превращать накопленный контекстный опыт в устойчивые, проверяемые и эволюционирующие способности.

При этом Experience остаётся богатым историческим слоем, Knowledge — контекстным результатом обобщения, а Skill — компактной исполняемой формой накопленного опыта.

#13. Re-verification: часы, вердикты ранов и aging (реализовано)

Механика «знания стареют без свидетельств» — реализована целиком:

Итоговое правило: знание живёт, пока его подтверждают; сомнение накапливается от времени и от опыта; смерть — по свидетельствам (два вреда, явное опровержение, ручное решение).