Как я научил ИИ дорабатывать проекты: инкрементальные правки в PlyLoom

Подробности изложены в материале первоисточника. В прошлых материалах я подробно разбирал, как раскладывать знания по листам и сопоставлять две редакции регламентов с помощью графических карт. Теперь я хочу рассказать, как изменился подход к работе, когда за доработку структуры берётся искусственный интеллект. В предыдущих сборках PlyLoom я столкнулся с ограничениями: полная перезагрузка проекта при каждом запросе и отсутствие нормального механизма для отслеживания локальных изменений.

Чтобы протестировать новый функционал, я обратился к модели с конкретной задачей — внедрить в текущую структуру проверку повторной доставки сообщений. В ответ я получил набор правок, где помимо нужных пунктов обнаружились две типичные галлюцинации: произвольно увеличенный срок хранения файлов и исчезновение важной оговорки.

Пример обработки правок за минуту

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

Откуда появилась задача и почему не подходил целый проект

Изначальный прототип задумывался под простую схему: нейросеть извлекает данные, а человек контролирует результат. Однако при попытке итеративно дорабатывать проект с помощью промтов выяснилось, что отправка всего файла целиком приводит к сбоям. Большие объемы JSON заставляют модели терять контекст, сокращать цитаты и вносить несанкционированные правки, обнаружить которые вручную крайне тяжело.

Сравнение подходов: почему не подошли Confluence и Git

Для решения проблемы контроля версий я изучил существующие практики. Инструменты вроде Confluence сохраняют историю правок на сервере, но вносят изменения мгновенно и без предварительного шлюза проверки, к тому же автономный PlyLoom не имеет выделенного серверного бэкенда. Системы контроля версий вроде Git предлагают отличную логику pull request, однако построчное сравнение текстов плохо ложится на граф, где достаточно просто передвинуть карточку, чтобы изменить десятки строк JSON.

Пакетная передача и концепция приращений

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

Организация интерфейса и сценарии обмена

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

Двухэтапная проверка изменений

Текстовый ответ модели обрабатывается автоматически, разделяя правки по отдельным листам с наглядной демонстрацией удаленных и добавленных фрагментов. Конфликты требуют осознанного вмешательства оператора, исключая случайную перезапись зависимых узлов.

Первый этап: проверка в режиме брифа

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

Второй этап: верификация в структуре графа

Дальнейшая проверка происходит непосредственно на карте среди смежных узлов, где оценивается логика связей и смысловое наполнение. Специальная нижняя панель позволяет быстро принять или отклонить оставшиеся изменения пакетным образом.

Алгоритмы семантического сравнения карт

Благодаря постоянным идентификаторам узлов система умеет точно сопоставлять графы по содержанию, фиксируя добавления, удаления, переименования и смену типов связей. Специальные защитные механизмы предотвращают ложные срабатывания, когда модель случайно перенумеровывает ID существующих элементов.

Управление версиями через хэш-отпечатки

От громоздких журналов истории было решено отказаться в пользу компактных отпечатков версий на базе алгоритма SHA-256. Файл сохраняет слепки последних двадцати состояний, позволяя корректно определять конфликты при параллельном редактировании.

Тестирование стабильности алгоритма

Для проверки надежности механизма сравнения я задействовал автоматический генератор случайных правок. Проведение сотен тестовых итераций позволило выявить и устранить скрытые дефекты еще до официального релиза утилиты.

Дальнейшие шаги и развитие функционала

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