Инструменты ИИ (AI) для генеалогического исследования : ВГД

На сайте ВГД собираются люди, увлеченные генеалогией, историей, геральдикой и т.д. Здесь вы найдете собеседников, экспертов, умелых помощников в поисках предков и родственников. Вам подскажут где искать документы о павших в боях и пропавших без вести, в какой архив обратиться при исследовании родословной своей семьи, помогут определить по старой фотографии принадлежность к воинским частям, ведомствам и чину. ВГД - поиск людей в прошлом, настоящем и будущем!

Поделюсь своим опытом использования ИИ в документальной генеалогии: чтение рукописей, поиск архивных источников и проверка родственных связей. Недавно написал об этом на MolGen и решил поделиться здесь тоже.

У меня уже были семейные деревья в MyHeritage, Geni и в локальных файлах, сканы из архивов и разрозненные материалы (записки, карты и т.п.). Дальше нужно было всё это разбирать, искать недостающие документы и проверять, действительно ли люди в разных записях относятся к одной семье.

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

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

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

Предлагалось вручную разметить 60–100 страниц, дообучить специальные модели и начать с длительного пилотного проекта. Меня такое совсем не впечатлило ;D

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

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

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

За неполные две недели по журналам запусков набралось около 330 агент-часов. Это суммарная длительность запусков разных исполнителей, включая инструменты и ожидания, с отдельным учётом параллельной работы. В корпусе исповедок первично разобраны 63 комплекта, 796 снимков и 36,5 тысячи именных строк. Это строки, а не уникальные люди; около 4,5 тысячи строк отмечены как сомнительные.

В двух ветвях документально приняли 65 и 40 связей «родитель – ребёнок». От выбранных исторических корней прослежены цепочки к совокупно 103 предкам, местами до восьми поколений вместе с корнем. Часть имён уже была в деревьях, но теперь появились документы и обоснования связей. Некоторые прежние связи пришлось исправить.

ИИ нашёл для исследования немало источников, о которых я раньше не знал. В основном это были открытые ресурсы. Для работы с Тверским архивом он попросил подключить платный доступ: я его оплатил, а агент занялся получением и разбором документов. Поиск охватил материалы и каталоги РГАДА, РГИА, ЦГИА Санкт-Петербурга, национальных архивов Финляндии и Эстонии, Тверского архива и Тверского центра документации новейшей истории, сведения муниципального архива Максатихинского района. Пригодились также РГБ, РНБ, НЭБ, Государственная публичная историческая библиотека и тверские библиотеки. Помимо исходных деревьев MyHeritage и Geni, использовали FamilySearch, SSHY, Digihakemisto, HisKi, базу «Великие описи», форум ВГД, «Наши предки», «Открытый список», опубликованные материалы на Flickr, Google Drive, Яндекс Диске, Wikimedia/Wikisource и многие другие источники. В результате по всем направлениям исследования сохранено более 33 тысяч уникальных файлов общим объёмом около 26 ГБ: изображения документов, книги и их части, описи, карты и каталожные материалы.

О принятии связей в основное дерево мы договорились отдельно. Если агент обосновал конкретную связь по документам, я считаю её сразу согласованной: не нужно каждый раз ждать моего отдельного «да» или обязательного второго независимого "субагента-аудитора". В документе подходит и прямое указание, и совокупность свидетельств, если установлены конкретные люди, проверены родство, хронология и существенные альтернативы. Источники и объяснения сохраняем, гипотезы держим отдельно.

Эти правила пришлось уточнять в процессе. Сначала агент местами слишком упирался в отсутствие отдельной метрики или буквального слова «мать» рядом с именем, поэтому даже при очевидном совпадении он пытался все время обязательно найти еще какой-то документ. Я ему уточнил: ещё один документ нужен только для решения конкретного вопроса, а не просто на всякий случай, чтобы условно 99.95% уверенности превратилось в 99.99%.

Нерешённую дату можно было оставить открытой, если обосновано, что она не меняет вывод о родстве.

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

Теперь несколько других примеров того, как это выглядит на практике. В исходном дереве матерью ребёнка была записана более поздняя жена отца. Я предложил проверить два брака; агент сопоставил семейную книгу и метрику, после чего материнскую линию удалось исправить.

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

С одним селом пришлось разбираться через историю местности. Агент нашел его в официальном справочнике, затем отыскал опубликованные воспоминания жителей. Они помогли различить старое поселение, местные названия и позднейший посёлок переселенцев. Я уточнил семейную привязку, и стало понятнее, где искать дальше.

В другом поиске агент обнаружил реестр архивных потерь: фонд нужного прихода, 53 дела, числился утраченным во время ВОВ. При этом сохранившиеся книги в другом фонде остались в работе.

Были и технические задачи. В двух книгах текст на экране читался, а при извлечении превращался в неправильные символы. Агент заново распознал 1 414 страниц, сохранил результат отдельно от оригиналов, и по книгам стало возможно искать текст. А неясную цифру в рукописи проверил по надёжному написанию "1835" на той же странице: сравнил форму 3 и 5 и исправил своё первоначальное чтение года с 1775 на 1773. Другими словами по этому "1835" можно было понять как конкретный писарь эти цифры изображал.

Наконец, в отдельном поиске сведений о дедушке агент нашёл библиографическую запись его статьи (о которой моя семья не знала вообще), подготовил запрос в РГБ и после моего согласования он сам (!) отправил письмо с подключённой почты.

Рабочие выводы пока без независимой проверки, полный документальный путь от выбранных корней до меня ещё не везде закрыт. Но я мягко говоря удивлён тем, насколько удалось сдвинуться с места. Постепенно сложилась работа нескольких исполнителей с архивными сайтами, документами и общими файлами; моя роль – направлять поиск, давать семейные подсказки и определять, какие основания достаточны для принятия связи. Идеально

Отличный опыт!

Поделитесь - каким агентом пользовались? Какой харнесс и набор инструментов - дефолтный для агента или что-то дополнительное использовали? И какая модель?

Norseman написал:

[q]
Отличный опыт!

Поделитесь - каким агентом пользовались? Какой харнесс и набор инструментов - дефолтный для агента или что-то дополнительное использовали? И какая модель?
[/q]

Спасибо!

Фактически, весь харнесс – штатный Codex.

Использую модели GPT-6 Astra (постановка задач и планирование) и GPT-6.1 Sol (основная работа), уровни рассуждения high/xhigh в зависимости от чата.
Настраивал их интуитивно, опираясь на опыт работы с этими моделями в других проектах.

Все чаты работают с общей папкой, поэтому результаты сохраняются в файлах и доступны для продолжения работы. Связанные сведения хранятся в JSON, пояснения и исследовательские разборы – преимущественно в markdown.

Структура такая:

[q]
Проект/
├── AGENTS.md – правила работы для агента
│
├── archive/ – сами материалы
│ ├── documents/ – архивные документы и сканы
│ ├── trees/ – исходные выгрузки деревьев
│ ├── literature/ – литература
│ ├── maps/ – карты
│ ├── stories/ – семейные рассказы
│ ├── correspondence/ – переписка и запросы
│ ├── derived/ – производные файлы
│ └── research_history/ – материалы этапов исследования
│
├── knowledge/ – каталог содержимого
│ ├── collections/ – связанные записи по типам
│ └── branches/ – подборки по родам
│
├── research/ – разбор документов, сопоставления, гипотезы и дальнейший план поиска
├── canonical/ – люди, родственные связи, их статусы и решения о принятии в дерево
├── decisions/ – мои указания и правила исследования
└── scripts/ – скрипты обработки и проверки
[/q]

Что используют агенты – инструменты работы с файлами, терминал, веб-поиск, просмотр изображений и делегирование задач. Дополнительно использовались браузерная автоматизация, локальные утилиты для PDF и OCR, а также python- и JS-скрипты. Агент пишет скрипты сам по ходу работы: для скачивания материалов, каталогизации, проверки дублей и поиска по текстам. Для запроса в РГБ подключил gmail плагин.

Для распознавания сканов документов он использует в основном Tesseract, а из PDF с готовым текстовым слоем извлекает текст напрямую. Рукописный текст и сложные фрагменты ИИ разбирает по изображениям страниц – именно в этом и есть ключевой прогресс!

Обычный OCR помогает с предварительным поиском, но сам по себе не считается достоверной расшифровкой: фрагменты, на которых строятся генеалогические выводы, агент сверяет с изображением оригинала, а сомнительные чтения отмечает отдельно.

Инструкции проекта завёл в AGENTS.md: что сохранять, как фиксировать источники, как отделять гипотезу от доказанного родства и когда принимать связь в дерево. Постепенно уточняю правила, учась на ошибках

Один раз слишком широко поставил задачу оркестратору: попросил его унифицировать все материалы, сохранять полные тексты и выделенные сведения, а затем завершить весь разбор архива. Агент построил подробный каталог, но увлекся техническим сопровождением. Например, подключение трех метрических книг дало больше 4000 связанных записей: карточки файлов, изображений страниц, уже существовавших OCR-текстов и связи между ними.

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

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

По поводу итогового интерфейса или какого-то "дашборда". Пробовал gramps, потом просил агента написать приложение под меня – ну всё не то, если честно. В итоге понял, что мне удобнее хранить каноническое дерево и связи с документами, а нужное представление получать отдельными запросами. Условно: "Построй вертикальное дерево по этой ветке от такого-то человека, добавь разделители по столетиям, покажи род занятий и известные годы жизни". Или: "сделай интерактивную карту мест проживания; сначала покажи 5 вариантов на HTML мокапе".

Такой подход кажется мне удобнее, чем заранее пытаться уместить все будущие задачи в один интерфейс. Откровенно говоря, появляется ощущение, что привычные подходы из серии "найти приложение и приспособиться к его возможностям" уходит. Интереснее иметь свои данные в понятной структуре и получать нужные инструменты и представления по запросу.

Классный опыт! Спасибо, что поделились!!! Всё очень-очень интересно

Я пока до такого уровня не дошел, хотя модели и агентов использую в хвост и в гриву уже месяцев 8-9... - слишком люблю работать руками и абсолютный личный контроль :( Знаю, что меня это тормозит, но сломать привычки пока не получается

Это при том, что уже пробовал выстроить пайплайн и до-обучить модель под себя, сделать свой RAG, сделал простенького агента для себя со своей обвязкой - чтобы точно знать как это всё работает, обвешался моделями сверху-донизу, снабдил две своих личных проги встроенными MCP-инструментами для управления из своего персонального ассистента... В общем с низовкой проблем никаких, а вот сверху - читаю такие сообщения как ваше - и только облизываюсь, а выстроить такое-же не могу :( - личные предпочтения ломают

Дерево проекта у вас шикарное! Респект!

Norseman написал:

[q]
Классный опыт! Спасибо, что поделились!!! Всё очень-очень интересно

Я пока до такого уровня не дошел, хотя модели и агентов использую в хвост и в гриву уже месяцев 8-9... - слишком люблю работать руками и абсолютный личный контроль :( Знаю, что меня это тормозит, но сломать привычки пока не получается

Это при том, что уже пробовал выстроить пайплайн и до-обучить модель под себя, сделать свой RAG, сделал простенького агента для себя со своей обвязкой - чтобы точно знать как это всё работает, обвешался моделями сверху-донизу, снабдил две своих личных проги встроенными MCP-инструментами для управления из своего персонального ассистента... В общем с низовкой проблем никаких, а вот сверху - читаю такие сообщения как ваше - и только облизываюсь, а выстроить такое-же не могу :( - личные предпочтения ломают
[/q]

Понимаю. У меня обратная ситуация - люблю анализировать уже готовенькое

Norseman написал:

[q]
Дерево проекта у вас шикарное! Респект!
[/q]

Спасибо! Буду периодически писать в эту ветку, что интересного получается - и находки, и грабли

4head написал:

[q]
Использую модели GPT-6 Astra (постановка задач и планирование) и GPT-6.1 Sol (основная работа), уровни рассуждения high/xhigh в зависимости от чата.
Настраивал их интуитивно, опираясь на опыт работы с этими моделями в других проектах.

Все чаты работают с общей папкой, поэтому результаты сохраняются в файлах и доступны для продолжения работы. Связанные сведения хранятся в JSON, пояснения и исследовательские разборы – преимущественно в markdown.
[/q]

абсолютно верный подход, как мне кажется. Astra и Claude Opus 5.5 жужжат очень хорошо, но и токены кушают как не в себя. В частности, на распознавании текста. Делать какую-то специализированную модель - мне кажется уже никакого смысла нет, потому что модели общего применения завтрашнего дня переплюнут специализированную модель сегодняшнего дня на раз два. Это соревнование мы уже проиграли. Единственное, что с локальной моделью можно выиграть стоимость токенов за счет амортизации оборудования. Тогда интересно - удалось ли кому-нибудь взять готовую Gamma или Qwen и сварить из них что-то удобоваримое. Что важно - разработчики Астры и Опуса смотрят внутрь транскриптор и оптимизируют свои модели - поэтому условный Opus 6.0 будет точнее на Х% и дешевле на Y%.

gecube написал:

[q]
Делать какую-то специализированную модель - мне кажется уже никакого смысла нет, потому что модели общего применения завтрашнего дня переплюнут специализированную модель сегодняшнего дня на раз два. Это соревнование мы уже проиграли. Единственное, что с локальной моделью можно выиграть стоимость токенов за счет амортизации оборудования. Тогда интересно - удалось ли кому-нибудь взять готовую Gamma или Qwen и сварить из них что-то удобоваримое.
[/q]

Абсолютно с вами согласен.

Я пробовал свой пайплайн собрать для файн-тюнинга подобранной модели, именно Gemma. Но не для распознавания - тут с гигантами соревноваться - только время тратить. Хотел до-обучить на понимание паттернов разбора архаичных формулировок в переписях и метриках, на соответствие имен. Потому что столкнулся в своих экспериментах с тем, что если что-то противоречит базовому корпусу обучения используемой модели - ни RAG, ни факты, ни паттерны, ни системная роль - не авторитет. "Железный болван" будет тупить до победного, признаваться в ошибках, плакаться и всё равно косячить. Но увы. Столкнулся с элементарной вещью сразу же - хоть сколько ты занимайся генеалогией, сколько накопил распознанных документов и прочего - чтобы реально как следует до-обучить модель - нужен хороший качественный и вычитанный корпус документов. Большой! Пруфа прямо сейчас вам не приведу и не докажу, но было такое что для качественного до-обучения существующей модели нужно не менее 200 разных паттернов только на одну новую или конфликтную сущность (черт его знает, где я это читал, но такая цифра в голове осела). В одиночку биться головой об стенку и собирать корпус документов для обучения, да еще вычитывать и форматировать, чистить и подготавливать... увы. Закрыл эту тему.

Norseman написал:

[q]
Я пробовал свой пайплайн собрать для файн-тюнинга подобранной модели, именно Gemma. Но не для распознавания - тут с гигантами соревноваться - только время тратить. Хотел до-обучить на понимание паттернов разбора архаичных формулировок в переписях и метриках, на соответствие имен. Потому что столкнулся в своих экспериментах с тем, что если что-то противоречит базовому корпусу обучения используемой модели - ни RAG, ни факты, ни паттерны, ни системная роль - не авторитет. "Железный болван" будет тупить до победного, признаваться в ошибках, плакаться и всё равно косячить. Но увы. Столкнулся с элементарной вещью сразу же - хоть сколько ты занимайся генеалогией, сколько накопил распознанных документов и прочего - чтобы реально как следует до-обучить модель - нужен хороший качественный и вычитанный корпус документов. Большой! Пруфа прямо сейчас вам не приведу и не докажу, но было такое что для качественного до-обучения существующей модели нужно не менее 200 разных паттернов только на одну новую или конфликтную сущность (черт его знает, где я это читал, но такая цифра в голове осела). В одиночку биться головой об стенку и собирать корпус документов для обучения, да еще вычитывать и форматировать, чистить и подготавливать... увы. Закрыл эту тему.
[/q]

все хуже. Если рукопись - паттерны меняются от писаря к писарю. А по годам - бланки разные. То есть это можно распознать, кодифицировать и маленькой нейронкой перенаправлять на другие более специализированные нейронки. Но какое-то сумасшествие. Реально.

А есть ли где-то описание, куда соваться новичкам в этом вопросе? Меня немного смущает обьем, на котором судя по всему вы работаете, ведь для эффективности этих агентов нужны большие обьемы. То есть например сохраненные сканы метрик целиком?

Простите за дурацкие вопросы, звучит соблазнительно, но пока непонятно, как взяться

Инструменты ИИ (AI) для генеалогического исследования

Все, что касается искусственного интеллекта, в помощь в исследованиях