Монтируем языковую модель как диск: эксперимент с Python и FUSE
Языковые модели умеют убедительно сочинять - иногда именно поэтому им трудно доверять. Они могут придумать несуществующую научную работу, приписать библиотеке отсутствующий метод или уверенно описать факты, которых не было в исходных данных. Обычно эту склонность стараются ограничить: подключают базы знаний, добавляют инструменты и требуют отвечать только по заданному контексту. Но что, если выдумка не ошибка, а полезная функция?
Есть задачи, где синтетические данные нужны намеренно: например, для тестирования программ, создания игровых миров или подготовки ловушек для злоумышленников. В информационной безопасности такие ловушки называют honeypot. Это поддельные серверы и сервисы, которые должны выглядеть правдоподобно, чтобы привлечь атакующего и дать специалистам возможность изучить его действия. Однако пустую декорацию легко распознать, а вручную наполнять ее конфигурациями, журналами и заметками администратора долго.
Эксперимент автора решает эту проблему необычным способом: языковая модель изображает файловую систему. В ней нет заранее созданных файлов - каталоги и их содержимое возникают по запросу. Такой подход позволяет быстро развернуть большой правдоподобный мир, а программы взаимодействуют с ним привычными средствами. Подробности этого проекта - в материале о том, как устроена бесконечная файловая система на Python и FUSE.
Почему модель удобно представить в виде диска
Чтобы программа могла обратиться к языковой модели, обычно требуется специальная интеграция: API, плагин, MCP-сервер или собственная обвязка. Файловый интерфейс гораздо привычнее и универсальнее. С файлами умеют работать командные утилиты, скрипты и графические менеджеры - от `find` и `grep` до "Проводника". Если подключить модель как диск, существующим инструментам не придется знать, что данные на самом деле создаются искусственным интеллектом.
Для реализации автор использовал FUSE - механизм, позволяющий создавать файловые системы в пользовательском пространстве. Ядро Linux передает программе запросы, например на просмотр каталога или чтение файла, а код отвечает так, будто работает с обычным диском. В проекте задействована библиотека `mfusepy`, совместимая с `libfuse3`. Основная логика сосредоточена в обработчиках, которые вызываются при обращении к папкам и файлам.
Так выглядит практическая разработка файловой системы на Python: вместо чтения заранее сохраненных данных программа обращается к модели и получает от нее содержимое для нужного пути. При генерации учитываются адрес файла и имена соседних объектов. Благодаря этому материалы могут ссылаться друг на друга: например, заметка упоминает таблицу из той же директории, а конфигурация веб-сервера - сайт из соседней папки. Созданный мир сохраняется в JSON, поэтому при повторном обращении содержимое остается прежним.
При этом система работает лениво: пока каталог никто не запросил, его содержимого фактически нет - даже в оперативной памяти. Мир постепенно "дорисовывается" только в тех местах, куда обращается пользователь или программа. Любой запрошенный путь считается существующим: если клиент попросил `/var/lib/postgresql`, файловая система добавит этот объект. По принятому в эксперименте правилу имя с точкой означает файл, а без точки - папку.
Особенности чтения и оборудование
У виртуальных файлов есть нюанс: размер неизвестен, пока модель не сгенерировала содержимое. Поэтому до чтения `ls -l` может показать нулевой размер, а после открытия файла размер появится. Чтобы приложения не прекращали чтение преждевременно, автор включил режим `direct_io` и отключил кэширование атрибутов в ядре.
Эксперимент запускался на домашней системе с видеокартой GTX 1660 Super на 6 ГБ, процессором Ryzen 5 2600 и 8 ГБ оперативной памяти. В окружении работали Windows 11 и Ubuntu 24.04 под WSL2. Для генерации использовалась Qwen3-4B-Instruct-2507 в квантовании Q4_K_M: модель занимает около 2,3 ГБ, запускается через `llama.cpp` с Vulkan и выдает примерно 57 токенов в секунду.
Первый тест обнаружил проблему не в файловом интерфейсе, а в поведении модели. На просьбу показать содержимое `/home/user/рецепты` она ответила, что не может получить доступ к файлам компьютера. Это было формально верно: модель действительно не читала настоящий диск. Но задача заключалась не в поиске реальных рецептов, а в создании вымышленного содержимого. Поэтому системную инструкцию пришлось скорректировать: явно объяснить, что модель должна придумывать данные, а не отказываться из-за отсутствия доступа.
Этот пример показывает, что подключение языковой модели к файловой системе требует продуманного описания ее роли. Без ясных правил модель может воспринимать запрос как попытку прочитать реальные файлы и отвечать в соответствии с обычными ограничениями. Для файлового мира важно задать контекст: какие объекты допустимо создавать, как связывать их между собой и каким образом сохранять последовательность при повторных запросах.
От виртуального диска к ловушке для атакующих
В таком проекте FUSE для Python - не просто способ показать результаты генерации в виде файлов. Это интерфейс, который делает модель доступной целому набору уже существующих утилит. Например, `find` может обходить каталоги, а `grep` - искать строки в созданных документах. Для программ все выглядит как файловая система, хотя за каждым обращением стоит генерация или чтение сохраненного результата.
Особенно перспективным кажется применение этой идеи в honeypot-средах. Модель способна создавать конфигурации, журналы и служебные заметки, формируя впечатление живого сервера. В описанном эксперименте другой ИИ выступал в роли взломщика и несколько раз подряд принимал несуществующую систему за настоящую. Это не доказывает, что любая такая ловушка обманет реального злоумышленника, но показывает, что автоматически созданный файловый мир может выглядеть достаточно связно для дальнейших проверок.
Та же концепция пригодится не только в кибербезопасности. Генерируемая файловая система может быть полезна для тестирования приложений на больших наборах данных, создания учебных окружений и проверки инструментов, которым нужны реалистичные каталоги и документы. Здесь важны не только убедительность отдельных файлов, но и согласованность всей структуры: повторные обращения не должны каждый раз менять историю мира.
По сути, это пример разработки приложений на Python с искусственным интеллектом, где модель не встроена в программу как отдельное окно чата. Она становится частью инфраструктуры, а привычные системные инструменты превращаются в способ взаимодействия с ее результатами. Связка LLM API для Python и файлового интерфейса особенно интересна тем, что снижает порог интеграции: приложениям не нужно специально "понимать" модель, достаточно уметь читать файлы.
Конечно, виртуальный диск не следует считать источником достоверных сведений: его задача - создавать вымысел, а не выдавать факты. Поэтому применять такую систему нужно в изолированной среде и четко отделять сгенерированные данные от настоящих. Но как эксперимент с интерфейсами, автоматической генерацией и ловушками для анализа поведения злоумышленников он демонстрирует важную мысль: иногда полезнее не заставлять модель перестать фантазировать, а направить ее выдумку на задачу, где она действительно нужна.
