Вывод явных структур из неявных интуиций LLM: Compilence и FPF (2/2)

5. Поиск пробелов и конфликтов
 
Если обязанность ссылается на неопределённый термин, две нормы пересекаются или для конфликта не задан приоритет, это можно обнаружить при компиляции, а не после ошибочного решения.
 
6. Требования как проверяемая среда
 
Тот же подход применим к спецификациям, API-правилам, архитектурным ограничениям, стандартам безопасности и разработки.
 
ИИ пишет код или проектирует решение, а скомпилированный корпус проверяет его до выпуска.
 
Получается важный переход:
 
раньше база знаний помогала ИИ ответить;
теперь база знаний может начать управлять тем, что ИИ имеет право ответить или сделать.
 
Официальное описание Compilence рассматривает именно такие сценарии: compliance, государственные и правовые корпуса, здравоохранение, закупки, безопасность и проверку действий coding-агентов.
 
Чем Compilence отличается от FPF
 
На первый взгляд подходы похожи. Оба пытаются не оставлять важные различения внутри головы человека или внутри одного ответа LLM. Но задачи у них разные.
 
Compilence спрашивает:
 
"Что следует из этого утверждённого корпуса правил и можно ли это исполнить?"
 
FPF спрашивает:
 
"Что именно мы сейчас рассматриваем, утверждаем, сравниваем, решаем или делаем - и на каком основании?"
 
FPF нужен раньше и шире. Он помогает не смешивать:
 
- реальную систему и её описание;
- требование и предложение;
- источник и свидетельство;
- гипотезу и принятое решение;
- метод и план;
- план и фактически выполненную работу;
- архитектуру и нарисованную диаграмму.
 
Например, в проекте автоматизации налогового мониторинга FPF помогает разложить весь клубок:
 
что регулирует НПА - что добавляют методики - что реально реализовано в системе - какие проблемы подтверждены - какие варианты автоматизации есть - какой вариант выбран - какое решение принято - какие работы действительно выполнены.
 
Compilence начинает приносить максимальную пользу в другой точке: когда выбранный нормативный срез уже достаточно определён и его нужно превратить в исполняемую систему:
 
кто - при каких условиях - что обязан сделать - в какой срок - какое исключение действует - какой переход разрешён.
 
Есть ещё одно различие.
 
FPF - язык паттернов для организации мышления и проектной работы. Его можно применять в обсуждениях, документах, реестрах, архитектурных решениях и работе с LLM.
 
Compilence задуман как программный компилятор и исполняющий слой: корпус компилируется, а вопросы и действия затем проходят машинную проверку.
 
Поэтому FPF не конкурент Compilence.
 
Скорее, FPF помогает понять, что именно стоит компилировать, кто вправе утвердить эту структуру, какие основания у неё есть и для какого использования ей можно доверять. А Compilence может исполнять одну уже формализованную часть такого проекта.
 
Совсем коротко:
 
FPF превращает проектный хаос в явную архитектуру рассуждения. Compilence превращает утверждённый свод правил в явную исполняемую структуру.
 
FPF прямо предназначен для ситуаций, где значения, утверждения, варианты, доказательства, архитектура, решения и работа должны сохранять согласованность между людьми, командами, инструментами, временем и AI-агентами.
 
В общем, если вы практик по реализации проектов - то вашим рабочим инструментом будет скорее FPF. Если вы разработчик (или аналитик) регуляторного корпуса то тут может пригодиться Compilence.
 
Только один нюанс: FPF - открытый, бери и пользуйся. Compilence закрытая система, на этапе пилота, которая, возможно будет продаваться как сервис.
 
Ссылки:
 
1. Более подробный лонгрид на тему
2. Официальная страница исследований Compilence - https://compilence.com/research
3. Пост Pavel Valentov о Compilence (со ссылками на оригинальные статьи)
4. FPF - https://github.com/ailev/FPF/tree/main