⚛️ Атомарные Duo файлы


Сегодня день своеобразных терминов. Почему некоторые концепции имеют такие своеобразные названия? Потому что их нужно упоминать, а для этого им нужно какое либо название. Общепринятого не пришло в голову, подтому было выбрано настоящее название.

К сути. Сейчас обсуждаем концепцию "атомарных duo файлов". Это файлы, документирующие те или инце концепции в системе, причём построенные строго по определённым правилам:

- каждый duo-файл описывает только одну концепцию, отсюда в названии "атомарные"
- duo файлы "работают" в паре: арх-файл + гайд-файл
- первый хранится в папке architecture/ - арх-файл
- второй хранится в папке guides/ - гайд-файл
- парные файлы содержат аннотированные ссылки друг на друга
- арх-файл содержит высокоуровневое декларативное описание ЧТО и ПОЧЕМУ, архитектурную концепцию
- гайд файл описывает КАК ИМЕННО, операционные инструкции и детали

Такими файлами у меня в мемори банке описаны многие элементы фич, сущности в системе - от окружений для разработки (app stages) до визуального стиля ui-system

❓ Зачем атомарность? Почему только одна концепция?

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

Единственная концепция - удобный способ обеспечить принцип Single source of truth. Это важно для:
- группировки концепций в одном месте (полезно для внимания модели)
- упрощает обеспечение непротиворечивости контекста

Важная часть качественного контекста - его непротиворечивость. Если по вашим документам сведения "размазаны" по нескольким файлам, то с многословностью моделей вы легко получаете немного разные сведения об одном и том же! А после эволюции этого контекста могут появиться противоречия, что очень вредит качеству.

❓ Почему делим на 2 части?

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

Получается удобная управляемая схема.

❓В файле не одна концепция

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

❓А если никак не обойтись одной концепцией?

Я делаю составные концепции. Например, та же система тестирования может содержать групповой файл, который описывает систему тестирования в общем виде, и отдельные файлы про юнит тесты, e2e тесты и любые другие виды тестов, которые вы применяете.

❓ Сейчас модели получают большие контексты - зачем эта микро оптимизация?

Действительно, выходят модели с контекстами 400к токенов и 1м токенов. Но помимо контекста остаётся ещё механизм внимания модели, который тоже "не резиновый".

Чем меньше нерелевантных задаче деталей "отвлекают" модель, тем выше будет качество работы.

Этот аспект становится важнее с ростом системы.


#post
@deksden_notes