Я с интересом наблюдаю за ходом исследовательского проекта @ailev и время от времени использую его результат для несложных в общем-то задач с целью тестирования. Можно сказать что выступаю в роли бета-тестера на минималках (думаю далеко не я один но других таких постов пока не нашёл).
И вот в процессе размышления о сути этого FPF вспомнил такой термин - “машиночитаемый документ”. У нас в отрасли это в последнее время чем дальше тем более часто употребляемо, с разделением ещё на более узкие категории - машиночитаемый, машинопонимаемый и т.п.
Вот иллюстрация из одной из отраслевых презентаций на тему:
Как правило под ними понимают документы на машинном языке с жёсткой разметкой (xml, json, ifc вот тоже можно таким форматом считать).
Разговоры эти идут давно, в том числе и на (около)государственном уровне например в концепции “машиночитаемого права”
Нетрудно заметить что в FPF есть некоторый аналогии с такими “машино-читаемыми, понимаемыми, интерпертивруемыми” документами, однако благодаря тому что это документы всё же текстовые, то есть презназначенные для чтения в первую очередь LLM, но не исключающие и возможность их прочтения обычным человеком, мне кажется что FPF можно отнести к новому классу “LLM-читаемых”, “LLM-интерпретируемых” документов. Понятно, что таковым является также и любой хороший промпт (плохой тоже является, просто мы не будем их рассматривать, они нам не нравятся). Также и RAG тоже можно относить к LLM (или более широко - AI) - читаемым документам.
Однако FPF здесь мне кажется очень подходящим документом ввиду и своего размера, и своей структурированности, и своего предназначения - я пока вижу это предназначение в том чтобы удерживать “мышление” LLM в жёстких границах формальных описаний, давая при этом возможность дальнейшей интерпретации результатов на человеческом языке.
Мне показалось важным отметить факт появления такого класса документов, и видится в перспективе что возможно они даже важнее именно “машиночитаемых” документов, как они понимались ранее. Идея перевода всего корпуса стандартов, требований и НПА в машиночтаемый формат вручную мне кажется нерешаемой, а если для этого будет применяться ИИ - то бессмысленной. А вот с ИИ-читаемыми документами как будто перспектива выглядит гораздо более реальной, они, как видим, создаются самим ИИ, при должном уровне руководства процессом.
Ну и в качестве примера того самого тестового применения FPF.
Результаты уже приводил в чате Лабораторного журнала в Телеграме, сюда дублирую для истории и возможно кому-то будет интересно их увидеть здесь.
Там пока нет идеального результата, проект исследовательский и ещё далеко не в стадии завершения, но тем не менее я считаю результаты обнадёживающими.
Итак, исходная информация:
Новость о том что в Госдуме сформулировали определение искусственного интеллекта.
Вот оно:
«Искусственный интеллект — это любая система данных, программное обеспечение или аппаратное средство, обладающее способностью обрабатывать данные и информацию способом, напоминающим разумное поведение, с использованием методов машинного обучения или статистических методов для генерации контента, формирования прогнозов, рекомендаций или решений, способных оказывать влияние на реальную и виртуальную среду».
Гипотеза:
Это определение плохое, так как содержит в себе внутренние конфликты.
Метод проверки:
Пропустить это определение через ChatGPT 5 с предзагруженным в него файлом FPF и промптом на поиск в нём несоответствия FPF.
Результат:
1. Категориальные смешения (A.7 · Strict Distinction)
В определении спутаны объект («система данных, ПО или аппаратное средство»), метод («машинное обучение или статистические методы»), и поведение/результат («генерация контента, прогнозов, решений»).
По FPF нужно строго различать:
U.System (носитель, физическая или софтовая система),
U.Method и U.MethodDescription (способы действия),
U.Work (фактическое событие исполнения).
Здесь всё сжато в одну фразу без онтологической чистоты.
2. Проблема с агентностью (A.13 · Agential Role)
Определение приписывает системе «способность» вести себя «разумно». Но по FPF способность (U.Capability) — это отдельная ось, а «разумность» — это роль/характеристика, требующая контекста (U.RoleAssignment).
Иными словами, ИИ не является «разумным» сам по себе — он играет роль в контексте, а способность к обработке данных должна быть отделена от внешней интерпретации как «псевдоразумность».
3. Неявная метафора «как разум» (E.10 · Lexical Governance)
Формулировка «способом, напоминающим разумное поведение» вводит неформализованную аналогию. По FPF такие описания должны быть либо сведены к измеримым характеристикам (CHR), либо отнесены к конкретному bounded context. Иначе возникает риск амфиболии.
4. Смешение уровня дизайна и уровня исполнения (A.4 · Temporal Duality)
Определение одновременно говорит о методах («машинное обучение») и об их результатах («контент, прогнозы, решения»), но не проводит границы между design-time и run-time.
В FPF это разделяется: MethodDescription (например, обученная модель) ≠ Work (конкретный прогноз, выданный в момент времени).
5. Недостаточная онтологическая парсимония (A.11)
В одном предложении перегружено: система, данные, ПО, железо, методы, контент, прогнозы… Но не дано минимального ядра. FPF требует минимальной достаточности: лучше выделить «AI-система» как U.System, уточнить её U.Capabilities, а всё остальное оформить как роли и сервисы.
6. Неявность границ и контекста (A.1.1 · U.BoundedContext)
Определение претендует на универсальность, но не фиксирует контекст применения (например, юридический, инженерный, научный). По FPF любое определение должно быть привязано к bounded context, иначе оно становится размытым и несогласованным между доменами.
7. Нет физического якоря (A.12 · External Transformer, C.1 Sys-CAL)
Определение не указывает, что «ИИ» всегда должен быть реализован в конкретной физической системе (процессоры, память, носители). В FPF это обязательный якорь: любое абстрактное свойство должно быть связано с материальным трансформером.
Итого:
Определение ИИ в исходной формулировке нарушает несколько базовых FPF-принципов: смешивает уровни (система/метод/работа), не фиксирует контекст, использует метафору «как разум», не разделяет способность и роль, и не имеет физического якоря. В терминах FPF такое определение является категориально нестрогое и непроверяемое.
В ответ на предложение откорректировать определение от LLM получен следующий текст:
Искусственный интеллект (ИИ) — это система, реализованная на программном и/или аппаратном носителе, которая в рамках заданного ограниченного контекста наделена определёнными способностями по обработке данных и информации.
Эти способности могут реализовываться через различные описания методов (например, статистические методы или методы машинного обучения), которые при исполнении порождают конкретные работы (события обработки).
ИИ может исполнять различные роли, связанные с:
созданием контента,
формированием прогнозов,
предоставлением рекомендаций,
выработкой решений,
— что оформляется как услуги, оказывающие воздействие на реальную или виртуальную среду.
Отдельно приведу ответ на вопрос в чём проблема с термином “система данных”:
В FPF термин «система данных» в исходном виде проблематичен и некорректен. Обосную по слоям FPF:
Строгое различение сущностей (A.7)
FPF требует чёткого разграничения между:
U.System — холон, обладающий границей, динамикой, сервисами и способностью к действию.
U.Episteme — знание или описание (например, датасет, спецификация, метрика).
Данные как таковые — это эпистемический артефакт, а не система. Следовательно, термин «система данных» путает U.System с U.Episteme, нарушая принцип строгого различения.
Что может быть системой?
В FPF системой можно назвать:
платформу управления данными (например, СУБД или хранилище) как U.System, предоставляющий сервисы;
или коллектив программно-технических средств, которые трансформируют/хранят данные.
Но сами данные (наборы записей, наблюдений, файлов) — это не система, а U.Episteme.
Риски некорректного термина
Если оставить «система данных» без уточнения, возникают:
Категориальная ошибка: объект (System) смешивается с описанием (Episteme).
Архитектурная двусмысленность: непонятно, идёт ли речь о платформе, об инфраструктуре или о наборе сведений.
Управленческая ошибка: неясно, чем управлять — данными или системой их обработки.
Правильные проекции (аналогично L-FUNC для «функции»):
Если имеется в виду СУБД, lakehouse, data warehouse → корректнее: «система управления данными» ≍ U.System.
Если речь о самих данных → корректнее: «набор данных» ≍ U.Episteme.
Если о сервисах по предоставлению данных → U.Service, реализуемый системой.
Вывод:
Термин «система данных» сам по себе некорректен в модели FPF. Он требует уточнения и проекции:
либо в U.System (если это инфраструктура для работы с данными),
либо в U.Episteme (если это сами данные как знание).
Без этой проекции он нарушает принцип строгого различения и попадает в категориальную ошибку.
Вывода здесь пока особого не будет, возможно в дальнейшем дополню пост если будут ещё интересные примеры использования.