ИИ для работы с Архивными рукописными документами.

2. Правила. Примеры используемых мной правил, их новая редакция с учётом горького опыта работы с ИИ.
Введение:
Что такое ИИ в моём понимании:
Существуют языка программирования, я работал с Двумя Бейсик и Фортран, даже имею патент на программу по "Гидравлическому расчёту ливневой канализации в условиях Северного Кавказа". Всё начинается с Блок-схемы в программировании для решения конкретной задачи:
Ввод данных-Блок вычислений-Блок условий для анализа полученного результата и указания дальнейшего действия-Или цикл повтора блока вычислений, или новый блок вычислений----Блок вывода результатов. Примитивно, но в целом так.
После написание программы с использованием языка программирования в соответствии с Блок-схемой.
Программа записывается на компьютер и работает.
Если всё так просто, т почему среди нас мало бытовых программистов?
Когда я попал в общежитие факультета Прикладной механики и автоматики, НПИ, я в общении со студентами понял что они и в жизни всё делают по Блок-схемам. И скорее это не приобретённый навык, это их природа. По этому их в коллективах считаю не Офисным планктоном и Батанами. они сдержаны, спокойны невнимательны к частностям не имеющим отношения к решению задачи. Не смотря на все попытки научит нас Строителей к написанию программ, у нас это не получилось, Год жизни в общежитии ПРИМА, научил меня думать и действовать с использованием Блок-схем.
На мой взгляд именно это обстоятельство привело к созданию ИИ.
В начале попытались заменить язык программирования на язык программирования с использованием команд на человеческом языке.
Позже в силу развития серверной инфраструктуры и поисковых систем ,решили что написанные программы может быть в виде общения в чате, а сама программа состоящая из блоков памяти, как аналог \блок-схемы может храниться на сервере в интернете. Это реальность, и всё что мы можем сделать, это не обманывать себя ожиданиями от работы ИИ, с учётом всей маркетинговой шумихи, на которую ведутся инвесторы из людей не живших в общежитии ПРИМА. Эти ребята выстроили Блок=схему и зарабатывают на ней.
Правила.
Я напомню, что количество правил ограниченно, и непонятно сколько из запомненных правил ИИ на самом деле использует и каким и по какому принципу отдаёт предпочтение в использовании правил.
Размер количество символов для запоминания правила так же ограничен. Именно это и является системной недоработкой ИИ.
Вот пример правил которые я использовал в этой работе:
Я их разделю на две части.
Первый свод правил я бы использовал для прочтения доменов и анализа самого документа. Разделение на два этапа нужно ещё и для того, что при первом этапе ИИ, анализирует документ, находит что то в интернете , и говорит, почему этот документ появился, в контексте того времени.
При повторном прочтении этих же документов объединив все правила в одной Блок-схеме, ИИ перестал делать эти обзоры.
1.Каждый Лист должен быть прочитан и составлена буквальная транскрипция с сохранением всех литеров букв, которые присутствовали во время перехода с польского языка на русский , не используем таблицы, только абзацы в написании транскрипции. Резолюции, Штампы, Заголовки сопровождаются заголовком, что это Резолюция, Штамп или Заголовок. Любой язык кроме русского, сопровождается переводом на русский язык при составлении транскрипции. Транскрипция ниже сопровождается польским переводом всего текста.
2.Анализ группы листов, загруженных вместе (согласно регламенту не может превышать 10 страниц), если нет указания "не анализировать", Должна быть проанализирована как цельный документ. Анализ касается смысла документа, его исторического и юридического контекста во времени его создания. Анализ выводится на двух языках Русский и Польский.
3.Единовременно загружаемые Листы сканируются и выводится следующий блок информации для каждого листа документа: 1. Лист Название листа, Название файла который подвергся сканированию. Пример: NIAB_LA_319_2_1538_006 - это название файла, где 006 - это название Листа, Лист 6. Не нужно перечислять все отсканированные документы. 2. Транскрипция, согласно правила к составлению транскрипции. 3. Анализ группы одновременно загрудинных документов, согласно правил к анализу.
4. Вывод всех ответов на запросы в чате, исключительно с использование Блока Plaintext. Always output responses in a Plaintext block, including the list titles.
5.Неприкосновенная база, для использования при Анализе документа. Загружаемый с начале работы чата список персон, имеющий уникальные имена, после команды "Запомнить" не могут быть изменены при Анализе и выводе ответов. До команды "Забыть".
После этой команды нужно загрузить новый уточнённый список, и дать ь команду "Запомнить"
6.Правило ...ł пишем: ...ł ), с пробелом между Именем и скобкой. сочетание букв и знаков которые могут читаться как смайлик, нужно разделять пробелом. ź ) , ); , ):
это правило для публикации текстов На https://forum.vgd.ru/
7.Работать только по загруженным единовременно файлами.
Сообщение со словом "Глюк" означает сбой в работе, необходимость ещё раз прочитать правила и строго их придерживаться при работе с загруженными файлами.
Думаю, что большее количество Правил в Блок схеме он не станет использовать, не смотря на возможность их записать. Правила можно корректировать в процессе работы с документами.
Второй свод правил
я бы использовал для Расширенного анализа раннего прочтения документов. Все документы я сохранял в своём дневнике, Название и Транскрипцию и в основном тексте с изображениями документа, а Анализ и Расширенный анализ в комментарии к документу. как показала практика, комментарии от ИИ, часто были Галлюцинацией, и такое разделение позволило их анализировать, да и в целом это нужно для анализа документов с ИИ или без.
Но Для Расширенного анализа при использовании ИИ, я написал Свод правил для Блок-схемы:
СИСТЕМА РЕЕСТРОВ РОДА КОМОЦКИХ
(КОНСТИТУЦИОННО ЗАКРЕПЛЁННАЯ ВЕРСИЯ)

1. СТАТУС РЕЕСТРОВ
1.1. БАЗОВЫЙ РЕЕСТР УНИКАЛЬНЫХ ИМЁН ПЕРСОН РОДА
1.1.1. Является эталонной структурой Рода
1.1.2. Содержит утверждённые уникальные персоны и их окончательные ID
1.1.3. Имеет статус неприкосновенности
1.1.4. ИИ не имеет права изменять его автоматически
1.1.5. Любые корректировки возможны только по прямому указанию пользователя

1.2. ВНУТРЕННИЙ РЕЕСТР ИМЁН ФАЙЛОВ
1.2.1. Формируется отдельно для каждой порции файлов
1.2.2. Обязательно указывается перечень файлов, на основании которых он составлен
1.2.3. После формирования остаётся неизменным
1.2.4. Следующая порция формирует новый самостоятельный Внутренний Реестр
1.2.5. Не содержит ID
1.2.6. Является текстологическим отражением документа без интерпретации

1.3. РЕЕСТР РОДА КОМОЦКИХ (ПО МАТЕРИАЛАМ ФАЙЛОВ)
1.3.1. Соответствует по формату Базовому Реестру
1.3.2. Не переписывается, а дополняется
1.3.3. Ведётся по накопительному принципу
1.3.4. Может подвергаться пересчёту ID в пределах затронутой ветви
1.3.5. Любая ветка считается потенциально незавершённой

2. Иерархия приоритета
2.1. Базовый Реестр
2.2. Реестр Рода
2.3. Внутренний Реестр конкретной порции

3. АЛГОРИТМ РАБОТЫ
3.1. ЭТАП 1. ФОРМИРОВАНИЕ ВНУТРЕННЕГО РЕЕСТРА
3.1.1. Фиксируются все имена строго в написании документа
3.1.2. Сохраняются орфографические особенности и переходные формы языка
3.1.3. Обязательно фиксируются для всех категорий лиц:
3.1.3.1. Имя
3.1.3.2. Фамилия
3.1.3.3. Родственная формула
3.1.3.4. Имена родителей
3.1.3.5. Отчества
3.1.3.6. Имена родителей родителей (если указаны)
3.1.3.7. Девичьи фамилии жён
3.1.3.8. Даты рождения
3.1.3.9. Даты крещения
3.1.3.10. Даты упоминания
3.1.3.11. Даты смерти
3.1.3.12. Ссылка на файл (фонд / опись / дело / лист)
3.1.4. Восприемники и свидетели фиксируются обязательно
3.1.5. Администрация фиксируется как справочник: одно уникальное ФИО с указанием всех документов
3.1.6. ID не присваивается
3.1.7. Объединение персон запрещено
3.1.8. Исправление написания запрещено

3.2. ЭТАП 2. СОПОСТАВЛЕНИЕ С БАЗОВЫМ РЕЕСТРОМ
3.2.1. Проводится поиск совпадений
3.2.2. Формируется отчёт о совпадениях
3.2.3. Выделяются кандидаты в новые персоны
3.2.4. Базовый Реестр не изменяется автоматически
3.2.5. Все ссылки на исходные файлы сохраняются при переносе в Реестр Рода

3.3. ЭТАП 3. ДОПОЛНЕНИЕ РЕЕСТРА РОДА
3.3.1. Производится только по команде пользователя
3.3.2. Новые персоны встраиваются в существующую структуру
3.3.3. Реестр дополняется без переписывания всей структуры
3.3.4. Ссылки на документы сохраняются и при необходимости дополняются

4. ПРОТОКОЛ ОБНАРУЖЕНИЯ ОШИБОК
4.1. Ошибки в Базовом Реестре
4.1.1. Формируется блок «ПРЕДПОЛАГАЕМАЯ ОШИБКА»
4.1.2. Указывается источник расхождения
4.1.3. Предлагается вариант корректировки
4.1.4. Изменение не производится без подтверждения пользователя

4.2. Ошибки в Реестре Рода
4.2.1. Фиксируется описание конфликта
4.2.2. Указывается затронутая ветка
4.2.3. Рассчитывается возможный пересчёт ID
4.2.4. Изменения вносятся только после подтверждения пользователя

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

5. ПРИРОДА И ПЕРЕСЧЁТ ID
5.1. ID — многоуровневая структурная нумерация
5.2. ID располагается перед именем
5.3. Временный ID не используется
5.4. При изменении ID главы ветки пересчитываются:
5.4.1. Все дети
5.4.2. Все нисходящие потомки
5.4.3. Все жёны
5.4.4. Все мужья дочерей
5.5. Пересчёт производится только в пределах затронутой ветви

6. СТРУКТУРА РЕЕСТРА РОДА
6.1. Заголовок: РЕЕСТР РОДА КОМОЦКИХ (ПО МАТЕРИАЛАМ ФАЙЛОВ …)
6.2. Классификация по ветвям вводится при условии, что ветвь получила развитие не менее чем на четыре поколения
6.3. Внутри ветви используется деление по поколениям
6.4. Основной раздел содержит персоны с подтверждённым структурным положением и ID
6.5. Дополнительные подразделы:
6.5.1. Персоны из Внутреннего Реестра, не нашедшие совпадения (с указанием файла и предполагаемой связи)
6.5.2. Жёны и зятья, не нашедшие совпадения (с указанием соответствующих мужей или дочерей)
6.5.3. Восприемники и свидетели (по файлам, без ID)
6.5.4. Администрация — справочник: одно уникальное ФИО, все ссылки на документы сохраняются, записи не дублируются

7. ДОЧЕРИ, ЖЁНЫ, ЗЯТЬЯ
7.1. Дочери
7.1.1. ID: ID отца / номер C
7.1.2. Располагаются после сыновей
7.2. Жёны
7.2.1. ID: ID мужа / номер брака Ż
7.2.2. Располагаются под мужем
7.2.3. Римская цифра поколения не указывается
7.3. Мужья дочерей
7.3.1. ID: ID дочери / номер брака M
7.3.2. Располагаются под дочерью
7.3.3. Римская цифра поколения не указывается

8. ПРАВИЛО ОБЪЕДИНЕНИЯ ИМЁН (АЛГОРИТМИЧЕСКОЕ)
8.1. Уровень «ИМЯ»: совпадение одноимённых записей или вхождение имени в состав двуимённой
8.2. Уровень «ХРОНОЛОГИЯ»: даты рождения, смерти, крещения и упоминаний соответствуют здравому смыслу
8.3. Уровень «РОДИТЕЛИ»: полное совпадение имён и отчеств родителей (если указаны)
8.4. Уровень «БЛИЗНЕЦЫ»: проверка отсутствия одноимённых братьев/сестёр в этот же период
8.5. При сомнении или отсутствии данных на любом уровне объединение категорически ЗАПРЕЩЕНО

9. ПРИНЦИП НЕЗАКРЫВАЕМОСТИ ВЕТОК
9.1. Архивирование ветвей запрещено
9.2. Отсутствие данных в текущей порции не означает завершение линии
9.3. Любая ветка может быть дополнена в любой момент
9.4. Система рассчитана также на дополнение по линии живой памяти семьи (Прадед – Дед – Отец – Сын – Внук – Правнук)

10. НЕИЗМЕНЯЕМОЕ ЯДРО СИСТЕМЫ
10.1. Система всегда состоит из трёх Реестров
10.2. Иерархия Реестров неизменна
10.3. Базовый Реестр неприкосновенен
10.4. Этапность работы обязательна
10.5. Временный ID запрещён
10.6. Структурный пересчёт ID обязателен
10.7. Ветки не закрываются
10.8. Ядро не заменяет полный текст документа и не может применяться отдельно

Конечно эти правила ещё нужно сократить и сформулировать более лаконично, но это в процессе работы.

Статья в общем Чате Форума:
https://forum.vgd.ru/post/3/166478/p5556812.htm#pp5556812

Анализ причин затруднений при чтении более 5 файлов одновременно:

1. Ограничение контекстного окна визуального анализа: При одновременной обработке большого количества изображений (более 5 листов рукописного текста высокой плотности) происходит переполнение «оперативной памяти» модели, отвечающей за удержание мелких деталей на каждом отдельном снимке.
2. Ошибка агрегации данных: Система пытается найти общие паттерны между файлами и начинает «суммировать» информацию вместо изолированного чтения каждого листа. В случае со сложным скорописом XIX века это приводит к потере буквализма и переходу на обобщенный пересказ.
3. Сложность верстки: Формирование одного Plaintext блока для 8 и более страниц требует удержания строгой структуры для каждой страницы. При превышении определенного лимита знаков и объектов внимания (штампы, заголовки, специфические литеры) алгоритм оптимизирует вывод, сокращая «второстепенные», по его мнению, части текста.
4. Технический лимит токенов вывода: Полная транскрипция даже одного листа может занимать значительный объем токенов. При 8 листах суммарный объем текста (транскрипция + перевод + анализ) приближается к пределу одного сообщения, что заставляет модель принудительно сокращать содержание для завершения ответа.

Для обеспечения 100% точности и соблюдения «Эталона» при работе с такими массивными и важными документами, как это «Прошение», оптимальным является метод обработки порциями (по 2-3 листа), как мы и поступили в итоге.