Skip to content

future-features-discussion.md

Latest commit

 

History

History
63 lines (41 loc) · 6.76 KB

future-features-discussion.md

File metadata and controls

63 lines (41 loc) · 6.76 KB

Майбутні функції (дискусійно)

Це нотатки з обговорень, не план релізу. Рішення можуть змінитися; код і схема БД тут не зафіксовані.

Родинні зв’язки на одній сторінці (скан)

Контекст: у поточних наборах (напр. один акт на скані) багато зв’язків імпліцитні: порядок у persons (дитина → батько → мати) і поля father в meta. Це слабко, коли на сторінці кілька записів, кілька дітей, свідки, схожі прізвища.

Що зручно для ШІ (JSON-вивід):

  • Кожній знайденій на цьому скані особі дати стабільний рядковий id у відповіді (на кшталт c1, f1, m1) — не плутати з persons.id у SQLite.
  • Не класти граф лише в meta випадкової особи; краще окремо на верхньому рівні поруч із persons (або під scan.meta — за смаком): масив relationships (або edges) з посиланнями на ці id.
  • Модель «вузли + ребра» — звична для промпта й валідації.

Приклад ідеї JSON:

{
  "scan": {},
  "persons": [
    { "id": "child1", "surname": "…", "name": "…", "meta": { } },
    { "id": "father1", "surname": "…", "name": "…", "meta": { } }
  ],
  "relationships": [
    { "type": "parent", "child": "child1", "parent": "father1", "role": "father" }
  ]
}

Збереження в БД (на майбутнє): у persons.meta можна тримати scan_person_id, що відповідає id з JSON; окрема таблиця для ребер (from_person_id, to_person_id, scan_id, тип зв’язку) — якщо потрібні запити по графу. Альтернатива — relationships у scans.meta, якщо достатньо сирого виводу без нормалізації.

Поле father у meta: може лишатися для імені з по батькові; канонічні зв’язки батько/мати–дитина — через relationships + id, коли введемо.

Типи спорідненості: коди чи довідник

  • Коди (фіксований набір у TEXT / enum / константи в коді): мінімум схеми, зручно в промпті «лише ці значення» (напр. parent_of, spouse, sibling, witness, godparent).
  • Окрема таблиця-довідник типів: варта уваги, якщо потрібні підписи в БД, локалізація, порядок сорту, історія змін — інакше часто достатньо кодів і поля role / side (напр. father / mother) де потрібно.
  • Для екстракції в JSON стабільні англ. коди; гарні назви українською — у UI, не в сирих полях.

Орієнтир на майбутню таблицю ребер: kind TEXT (або kind + role); довідник опційно.

«Пам’ять» між різними сканами (сусідні сторінки, списки)

Перше питання: чи може Gemini «сама» пам’ятати контекст між викликами, коли, наприклад, батько на одній сторінці, діти на наступній?

  • У стандартному API нема постійної сесії як у чаті: кожен запит — окремо. Щоб зв’язок між сторінками існував, його має передати пайплайн: підсумок попереднього скану, скорочений витяг, або нескорені зображення / діапазон PDF в одному запиті (батч сусідніх сторінок).
  • Тотожне формулювання: «щоб модель запам’ятовувала між сканами» = або групувати сусідні сторінки в один виклик, або зберігати стан (чернетка списку, «стан сім’ї») у своїй БД/коді і додавати це в наступний prompt.
  • Якщо дати моделі обидві сусідні сторінки разом, вона може узгодити суперечності; якщо лише одна сторінка без сусіда, збільшується ризик «домислити» зв’язок.

Друге питання: скрипт пропускає вже оброблені скани після рестарту (ідемпотентність).

  • Це окремий шар: кеш / done / ідентифікування файлу не залежать від моделі.
  • Якщо колись з’являться залежності між файлами, треба чітко визначити, що значить «успішно оброблено»: лише ця сторінка чи ще й пара сусідніх / перегляд після наступного файлу. Інакше легше випадково закешувати неповний випадок, коли «продовження» (діти) прийде пізніше на іншому скані.

Коротко: модель не зберігає сам контекст між викликами; лише то, що ви зберігли і підставили в наступний запит, або кілька сторінок в одному запиті. Пропуск уже обробленого при рестарті — корисна властивість, але при крос-сторінкових графах потребуватиме явних правил кешування/повтору.

Можливі напрямки, якщо будемо формалізовувати: «вікно з N сусідніх сторінок», об’єднаний state у JSON після кожного скану, правила повторної обробки, коли з’являється новий сусід.