Технічний контекст
Я залип не на романтиці пошуку предків, а на самій механіці. Репозиторій mattprusak/autoresearch-genealogy — це не «магічна кнопка», а акуратно зібраний workflow для Claude Code: покрокові гайди, шаблони сховища, правила розбору документів та маршрути по архівах.
За фактами там є як мінімум сім напрямних сценаріїв: старт проєкту, OCR-пайплайн, додавання нового предка, тріаж документів, усна історія, вирішення суперечностей та фазове ведення дослідження. Тобто автор не намагається змусити модель «вгадати сімейну історію». Він упаковує дослідження в послідовність кроків, де LLM допомагає тримати контекст і не втрачати нитку.
Ось це мені й сподобалося. Я багато разів бачив, як люди чекають від моделі готової відповіді, а потім розчаровуються. Тут підхід дорослий: Claude виступає не оракулом, а дослідницьким двигуном, який допомагає збирати гіпотези, готувати запити до архівів, розкладати прізвища за етимологією та підказувати, куди копати далі.
З обговорення навколо проєкту видно найцікавіше: користувачі вже ганяють це не у вакуумі, а на реальних сімейних даних, архівах та вивантаженнях на кшталт MyHeritage. Десь процес зупиняється через брак інформації, але модель навіть у такому режимі генерує нормальні листи до архівів і пропонує наступні кроки. Це вже не чатик «поговорити», а інтерактивне розслідування.
Окремо зазначу обмеження: підтверджених цифр щодо ефективності, якості або навіть витрати токенів у мене немає, крім згадок користувачів на кшталт «спалив 4.1k токенів». Тож я б не продавав це як доведену технологію з KPI. Але як патерн використання Claude — дуже сильна штука.
Що це змінює для бізнесу та автоматизації
Найкорисніший висновок тут узагалі не про генеалогію. Я бачу робочий шаблон для завдань, де мало структурованих даних, багато різнорідних джерел і потрібно крок за кроком уточнювати картину. Юридичний аналіз, due diligence, дослідження ринку, техпідтримка рівня L3, комплаєнс, пошук інцидентів у документах — все це дуже схоже за формою.
Якщо коротко: перемагає не той, у кого «найрозумніша модель», а той, хто вибудував процес. У таких кейсах вирішує архітектура ШІ-рішень: як зберігається контекст, як оформлюються гіпотези, де модель може фантазувати, а де зобов'язана посилатися на джерело, хто валідує спірні висновки.
Саме тому мені подобається дивитися на такі open-source штуки як на прототипи бойового впровадження ШІ. Спочатку хтось збирає вузький сценарій — тут це генеалогія. Потім стає видно, що той самий каркас годиться для більш приземлених завдань: автоматизація за допомогою ШІ довгих розслідувань, роботи з архівами, узгодження суперечливих документів та маршрутизації наступних дій.
Програють тут, як не дивно, любителі «давайте просто підключимо модель до бази, і все запрацює». Не запрацює. Без нормальної схеми intake, triage, OCR, resolution та фіксації статусу ви отримаєте гарний потік тексту і хаос у рішеннях.
Ми в Nahornyi AI Lab якраз на таких місцях зазвичай і включаємося: не у виборі модної моделі, а в збірці процесу цілком. Де потрібна людина-в-контурі, як будується ШІ-інтеграція, які кроки можна віддати на ШІ-автоматизацію, а які краще залишити правилам і валідації.
У мене після цього кейсу дуже простий висновок: LLM вже впевнено корисні у складній knowledge work, якщо дати їм рейки. Не магія. Нормальна інженерія.
Розбір зробив я, Вадим Нагорний з Nahornyi AI Lab. Я з командою руками збираю ШІ-рішення для бізнесу, де потрібно не «погратися з нейромережею», а зробити робочий контур зі зрозумілою логікою, ризиками та окупністю.
Якщо у вас схоже завдання — дослідницький workflow, архіви, документи, довгі кейси з купою невизначеності — напишіть мені. Подивимося разом, як це перетворити на чітке впровадження штучного інтелекту, а не на дорогий експеримент.