Як ви шукаєте потрібне всередині своїх Word і PDF?
Привіт. За кілька років у мене назбиралась купа робочих документів у Word і PDF, і лежать вони в різних теках. Коли треба знайти конкретний абзац, стандартний пошук Windows мало допомагає, тож часто просто відкриваю файли по черзі.
Цікаво, як з цим у вас. Чим шукаєте і що в цьому досі бісить?
Я зробив коротке опитування, воно займає кілька хвилин:
українською: docs.google.com/...wB1a3R0P16qUbAzQ/viewform
англійською, якщо захочете скинути іноземним колегам: docs.google.com/...l4KFN4wG1KQpUf2A/viewform
Під цю проблему я роблю невеликий застосунок, тому кожна відповідь мені справді допоможе. Наприкінці опитування можна лишити пошту для раннього доступу, але це необовʼязково. Підсумки викладу сюди ж, у тред.
39 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівwww.emulator3000.org/a3.htm Стара бібліотечна софтіна з епохи віндовс хп. В універі ще Zotero була, у німців ще бачив Citavi. Клас програм називається reference management and knowledge organisation program
Дякую за назву класу, з нею легше шукати, хто вже розв’язував цю задачу. Archivarius я подивився: ще у 2005 році він шукав по офісних документах з урахуванням словоформ української, тож запит «договір» мав знаходити і «договору». Для пошуку по копіях у мене та сама вимога, і лексична частина зводить слова до словникової форми.
mcp-documents-reader в ClaudeDesctop
Але якщо робити якийсь просунутий сервіс на клаудах (для спеціалізованих даних, створення knowledgebase для робочого середовища), то мабуть краще MS Azure FoundryIQ /WorkIQ
Дякую, подивився обидва варіанти. mcp-documents-reader зручний, коли асистент уже знає, який файл відкрити: він читає один документ за шляхом, а PDF бере текстовим шаром через pypdf, тож скан без розпізнавання для нього порожній. Мені ж складніше вгадати, де саме лежить потрібне, тому розпізнаний текст готується заздалегідь, і такий інструмент міг би читати вже його.
Foundry IQ справді сильний для компанії: він бере дані зі SharePoint чи OneLake і сам стежить, хто що може бачити, а Work IQ спирається на сигнали Microsoft 365. Але для цього документи мають жити в хмарі Microsoft, тоді як мені потрібна тека на власному комп’ютері.
Коли ці файли будуть потрібні?— таке питання сходу виникло. А ще й конкретний абзац.
Впевнений на 100% що такого хлама у кожного з нас достатньо.
Ми тільки створюємо, становимося прошареніше і створюємо ще краще.
Тому, забий.
У багатьох старі файли справді просто лежать, і це нормально. Мені ж доводиться повертатись до нормативних документів і власних старих текстів по конкретне формулювання, тож для мене питання «коли знадобиться» має відповідь. А якщо у вас такої потреби немає, це теж корисна відповідь: опитування якраз і має показати, наскільки вона поширена.
Якщо це робоче, то створіть собі найпростіший RAG.
Для себе я приблизно з цього й почав. Зʼясувалось, що головна робота там у тому, щоб чисто витягнути текст з Word і PDF і тримати його свіжим, коли документи змінюються. Тому ця частина й виросла в окремий застосунок.
Ласкаво просимо в кролячу нору :)
Тепер можете досліджувати стратегії чанкування, механізми оновлення знань у векторній БД без перегенерації всієї БД, стратегії повторних пошуків, автоматичних переформулювань запитів, додавання агентів, мультимодальності та багато чого ще.
Дякую :) У цю нору я свідомо не поліз. Застосунок робить лише нижній шар: чисті текстові копії поруч з оригіналами, які самі оновлюються після кожного збереження. Чанкування, векторна база й агенти лишаються тим інструментам, які людина вже обрала.
а опція видалення інформації там є? 🤔
Якщо питання про мій застосунок, то так. Оригінали він лише читає і не видаляє ніколи. Коли ви самі видалили документ, його копія лишається з позначкою, і її можна відправити в кошик застосунку; кошик чиститься сам через 7, 14 чи 30 днів або не чиститься взагалі, як налаштуєте, і до того часу копію можна повернути. Копії цілої теки теж прибираються однією дією. А от із векторної бази чи з пам’яті асистента, куди текст уже потрапив, застосунок нічого не забере, це питання до того інструмента.
Для покращення вашого застосунку (асістента) прошу розглянути питання:
Як ви будете трекати зміни/версійність документа протяггом його життєвого циклу? Якими умовами викликані періоди (7, 14, 30 днів, не діб, не годин, не місяців) відновлення документу?
Чому не використовуєте той же відомий Subversion?
Як буде актуалізуватися база векторних індексів в разі відновлення першоджерел?
Який життєвіий цикл пам’яті асистента? Які структурні елементи пам’яті там присутні і як опрацьовуються вони застосунком?
Історії редакцій застосунок не веде: копія завжди відповідає останньому збереженому стану оригіналу. У вашому DELMOS робочий продукт має незмінні ревізії з хешем і лежить у Git, і там це потрібно, бо погодження спирається саме на ревізію. Мій випадок простіший: людина лишає файли там, де вони вже лежать, і якщо їй потрібна історія, її тримає Subversion чи git, історія версій OneDrive чи SharePoint, а копія просто йде слідом за кожною новою редакцією. Тому власного сховища версій застосунок не заводить.
У кошик потрапляють лише Markdown-копії, і жоден вихідний файл туди ніколи не йде. Звідси й строки в днях: кошик стежить, щоб копії безкінечно не займали диск, і для довшого зберігання є варіант без очищення.
Коли документ повертається в теку, з нього знову будується свіжа копія, а зовнішню векторну базу оновлює вже той інструмент, що її веде. Своєї пам’яті в застосунку немає взагалі, і тут мені близький ваш життєвий цикл об’єктів знань з глави 19: відповідь асистента сама фактом у базі ставати не повинна. У мене копія будується лише з документа і ніколи з відповіді асистента, тож помилка асистента назад у копію не потрапляє.
Не робить непотрібних відповідей. Вам треба ваші проблеми вирішити — про них й кажіть, бо DELMOS дякую за увагу але до цих проблем він аж ніяк. :)
на чому технічно тримається це твердження? як відпрацьовуються виключні випадки?
Як це працює. Windows сама повідомляє застосунку, що файл у теці змінився. Застосунок чекає кілька секунд, поки Word закінчить запис, і робить копію заново. Нову копію він спершу пише в окремий файл і лише потім ставить на місце старої, тож обірвана посередині копія на диску не лишається. Якщо файл змінили, поки застосунок був вимкнений, він помітить це при наступному запуску, бо порівнює файли з тим, що запамʼятав минулого разу.
Тепер коли копія з документом не збігається. Поки йде перетворення, копія відстає: для звичайного документа це секунди, для довгого скану хвилини. Якщо перетворення впало, лишається стара копія, а в застосунку зʼявляється позначка помилки. Файл OneDrive, який лежить лише в хмарі і ще не скачаний, Windows віддає не до кінця; застосунок має прийняти це за помилку і не записати пів документа, але перевіряв я це лише на імітації, бо OneDrive у мене не стоїть. Скан, уже прочитаний сильнішим способом, слабшим прочитанням застосунок не перезаписує. Закріплену людиною копію застосунок лишає як є. Якщо ж людина правила копію руками, перед перезаписом застосунок зберігає її правку окремо.
Тож точніше так: копія відповідає документу, коли застосунок увімкнений і нічого з переліченого не сталося.
Пруф в студію. Який саме спосіб IPC використовується?
Кілька секунд це 3, 5, або 48? Random на певному діапазоні?
Тобто ще тримаєте базу хеш-відбитків задля контролю цілісності?
А як цілісність бази хеш-відбитків контролюється?
Йой, а ця хмара звідки випливла? Подальші галюцінації про скани, про нестояли і сильніші способи вже читати мені якось не здраво :)
Дякую за коментар!
OneDrive і скани я назвав тому, що в попередньому коментарі ви питали, як відпрацьовуються виключні випадки, і це вони. У теці OneDrive з режимом «файли на вимогу» документ може лежати на диску лише заглушкою, і цілком він читається лише після скачування. А копію скану, розпізнаного точнішим способом, застосунок навмисно не перезаписує грубішим прочитанням, і там копія свідомо відрізняється від свіжого перетворення.
Про механізм. Події з теки ловить бібліотека chokidar, яка на Windows підписується системним викликом ReadDirectoryChangesW. Пауза фіксована: спершу розмір файла має півтори секунди лишатись незмінним (звірка кожні 0,3 секунди), потім іде ще 2 секунди тиші, і кожна нова подія за цей час відкладає перетворення наново.
На кожен документ записано SHA-256 вмісту, а поруч розмір із часом зміни для швидкої звірки: збіглися вони, отже файл той самий, розійшлися, тоді рахується хеш. Окремої контрольної суми на сам файл з відбитками немає. Він пишеться через тимчасовий файл з резервною копією поруч; якщо файл не читається, береться резервна, а якщо зіпсована і вона, з’являється сповіщення про втрату запису, і копії Word будуються наново. PDF тоді чекають ручного запуску навіть з увімкненим автоматичним OCR: переробка всього архіву коштує часу, і рішення про неї має приймати людина.
Дуже цікаво спершу чітко зрозуміти, що саме автор вкладає у слово «потрібне». Для людини потрібність ситуативна: це може бути файл, конкретний абзац, чинна норма, усі згадки терміна або відповідь із цитатою. Машина ж має давати детермінований результат для однакового канонічного запиту за незмінних корпусу та конфігурації пошуку. Якщо намір не визначений достатньо — вона повинна уточнити запит, а не вгадувати.
Я б розділяв це не на «пошук у PDF/Word», а на три різні задачі.
1. Знаю точну фразу або її частину.
Потрібен звичайний повнотекстовий індекс із пошуком фрази, близькості слів і підсвічуванням уривка. Тут ШІ не потрібен.
2. Пам’ятаю тему, терміни або зміст.
Потрібен лексичний пошук: BM25/інвертований індекс, фільтри за текою, датою, типом файлу, автором, тегами. Для особистого архіву варто почати з локального Recoll або DocFetcher; для малого обсягу — налаштувати Windows Search на потрібні теки.
3. Питаю природною мовою: «де описано умови X?»
Тут може допомогти семантичний пошук або RAG. Але він має повертати не «відповідь від моделі», а список конкретних уривків: файл, сторінку, заголовок, дослівну цитату. Інакше неможливо швидко перевірити, чи система не помилилася.
Технічно нормальний конвеєр виглядає так:
Важливий нюанс: PDF бувають двох типів. У PDF із текстовим шаром можна індексувати текст і зберігати номер сторінки та координати фрагмента. Сканований PDF спершу потребує OCR; результат OCR треба позначати як менш надійний, бо там можливі помилки в числах, формулах і назвах.
Я б не зливав увесь документ у суцільний текст. Краще індексувати окремо заголовки, абзаци, таблиці, підписи та сторінки. Тоді результат пошуку — не просто назва файлу, а, наприклад: «contract.docx, розділ 4.2, абзац 3» з кількома реченнями контексту. Але для цього треба добре розуміти структуру документу і припускати дотримання цієї структури в кожному документі.
Для приватних робочих документів важливо, щоб індекс працював локально. Хмарні «AI PDF chat» сервіси зручні, але фактично передають зміст документів сторонньому провайдеру.
Найкорисніша функція такого застосунку — не чат як такий, а швидкий перехід від запиту до перевірюваного місця в оригіналі: «ось знайдений уривок, ось файл, ось сторінка».
Краще розповідайте про наміри і наводьте приклади вимог для вашого застосунку. Припускаю що читачів, вмотивованих поскорше відповідати на ваш опитувальник, буде очікувано замало.
Дякую за такий детальний розбір!
Про наміри
Застосунок працює локально на Windows. Ви додаєте теку, і він поруч з кожним Word і PDF створює текстову копію в Markdown з тією ж назвою, а потім стежить за змінами й оновлює її, коли документ збережено. Оригінали він лише читає, сканований PDF проходить через OCR. Пошук по цих копіях є в самому застосунку, а ще їх може читати будь-який інший інструмент, від Recoll до AI-асистента, якому ви довіряєте свої файли.
Ваша думка про перехід від запиту до перевірюваного місця в оригіналі дуже влучна, візьму її у вимоги. З прогнозом щодо кількості відповідей ви, мабуть, праві, тож якщо знайдете кілька хвилин на опитування, це мені дуже допоможе.
Проблема (і ціність її вирішення) в чому — знайти потрібний абзац. Я правильно вас зрозумів?
Які use cases оператора (користувача що шукає абзац) у вас оформлені?
Підхід із Markdown-тінню поруч із оригіналом — цікавий і практичний. Але є кілька деталей, від яких залежить, чи виконається та сама ключова вимога «перехід до перевірюваного місця»:
1. Прив’язка фрагмента до координат у оригіналі.
Markdown-копія руйнує прив’язку до сторінки і позиції. Щоб відкрити точне місце у Word або PDF, потрібно зберегти у метаданих фрагмента: для DOCX — paragraph_index або bookmark, для PDF — page_number + bbox (bounding box). Якщо це не зберігається, результат пошуку буде «файл і приблизний текст» — а не
«сторінка 7, абзац 3».
2. Структура важливіша за суцільний текст.
Один плаский Markdown на весь файл ускладнює гранулярний пошук. Ефективніше зберігати не «один файл → один .md», а індекс фрагментів з метаданими: {file, section, paragraph_id, page, text, ocr_confidence}. Навіть якщо UI залишається файловим — пошуковий рушій всередині потребує цієї структури.
3. OCR-якість треба явно тегувати.
Для сканованих PDF: якщо фрагмент пройшов OCR із confidence < 0.85 — це варто відображати у результаті, інакше користувач довіряє тексту, де число «18» могло бути розпізнане як «1В».
4. Markdown — добрий відкритий формат для інших інструментів, але Recoll та llama.cpp/LocalAI все одно захочуть мати змогу фільтрувати за метаданими (дата, автор, тека, тип джерела). Варто передбачити YAML front matter у кожному .md з цими полями.
Якщо реалізуєте пошук у самому застосунку то рекомендую SQLite + FTS5 як базовий рушій: він ліцензійно чистий, повністю локальний, підтримує BM25 out of the box і легко додає повнотекстовий та структурований пошук одночасно. Для семантичного — sqlite-vec або окремий FAISS-індекс поруч.
5. Найскладніша частина — синхронізація при оновленні оригіналу.
Ось де «тіньовий Markdown» стає крихким. Людина редагує contract_v3.docx, зберігає — застосунок перегенерує .md. А що відбувається з індексом?
- Сторінки зсунулися. Вставили абзац на початку і всі page_number і paragraph_id нижче по документу стали невалідними. Будь-яке збережене посилання типу «сторінка 7, абзац 3» тепер вказує не туди.
- Фрагменти зникли або злились. Розділ 4.2 перейменований або видалений — старі результати пошуку в індексі посилаються на неіснуючий уривок. Це тихий, непомітний збій: застосунок відкриє файл, але місця вже немає.
- Часткове оновлення vs повна переіндексація. Якщо при кожному збереженні переіндексовувати весь документ — при великих файлах це буде повільно. Якщо оновлювати лише «diff» — потрібен алгоритм порівняння абзаців, бо просте текстове diff на рівні рядків не дає змогу надійно ідентифікувати «той самий абзац, трохи відредагований» від «новий абзац».
- OCR + зміна скану. Якщо сканований PDF замінено новою версією — OCR треба запустити повторно. Як відрізнити «файл оновлено» від «файл перезаписано випадково»? Тільки за хешем вмісту, не за датою модифікації.
Як можливе рішення тут впровадити версіонування фрагментів, а не файлів цілком:Проте надійна синхронізація може бути досягнута лише інтеграцією з редакторм — ну це хоча б плагін до Microsoft Word. А щодо PDF або редагування офісних файлів в OpenOffice/LibreOffice то це вже ваш головний біль.
6. Видалення файлів і додавання нових файлів — моніторінг і відповідні операції...
P.S.: Чи воно того варто? Скільки разів на день ви витрачаєте на пошук абзаців?
P.S.: Не буду я час на опитувальник витрачати, добре що хоч коментую щось тут
Так, проблема саме в цьому: знайти потрібне місце, коли не пам’ятаєш, у якому з сотень файлів воно лежить. Оформлених use cases поки немає, є мій власний досвід: пошук Windows дає список файлів, а далі відкриваєш кожен. Опитування я запустив, щоб зібрати сценарії інших людей і не будувати все лише під себе.
1. Прив’язка. Для сканів, що розпізнаються посторінково, номер сторінки стоїть у копії маркером. У DOCX лишаються заголовки, а індексу абзаців і bbox немає, і відкрити оригінал точно на місці застосунок поки не вміє. Тож зараз результат справді «файл і приблизний текст», і ваше «сторінка 7, абзац 3» я беру у вимоги.
2. Структура. Одна копія на файл лишиться, бо саме її читають інші інструменти. Для пошуку текст ділиться на фрагменти за заголовками. На тестовому наборі з 34 запитів зважене злиття BM25 і локальних ембедингів дало 94% у топ-3 проти 91% у найкращого з двох окремо, тому там гібрид. sqlite-vec я розглядав, але для особистого архіву поки вистачає плаского індексу, а FTS5 за вашою порадою гляну.
3. OCR. Tesseract працює локально, українська й англійська. Якість зараз оцінюється на рівні файла, і сумнівні файли позначаються, а впевненість по сторінках і фрагментах стоїть у планах. Ваш приклад з «18» і «1В» дуже влучний.
4. YAML front matter уже є: джерело з типом файла і час генерації. Автора й теки там поки немає, їх варто додати.
5. Синхронізація. Після збереження документ перечитується цілком. Зміну видно спершу за датою й розміром, далі за sha256 вмісту, а перейменований чи переміщений файл впізнається за хешем без повторного розпізнавання. Хешів фрагментів поки немає, бо фрагментних посилань теж ще немає; коли вони з’являться, ваша схема з fragment_id і tombstone дуже доречна. Плагін до Word поки поза межами.
6. Видалений оригінал лишає копію з позначкою, і людина сама вирішує, прибрати її чи ні. Нові файли в теці підхоплюються автоматично.
Щодо P.S.: окремої статистики по собі я не вів. Тестовий набір з пункту 2 зібраний на двох сотнях нормативно-правових документів, а як часто такий пошук трапляється в інших людей, якраз і питає опитування. Чи варте воно окремого застосунку, я хочу зрозуміти з відповідей, тому ваші коментарі корисні мені не менше за опитування.
Тож я припускаю з умов, вимог і припущень, станом на цей момент краще не городити дублікати на усі файли, а вирішувати завдання точково — опрацьовувати пошуковий запит і аналіз знань в детектованих фрагментах документів. Першим етапом просто подати набір релевантних фрагментів із зазначенням джерел, їх версій і дат (документального стану).
Дещо раджу почитати по темі:
dou.ua/forums/topic/60526
dou.ua/forums/topic/60678
Дякую за статті. Прочитав обидві з коментарями, а слідом ще п’ять статей серії, щоб зрозуміти, з чого виросла ваша порада.
За вашою класифікацією зі статті про межу довідки й експертизи мій застосунок належить до довідкових систем, на щабель витягу. Згоден з цим.
Перший етап, як ви його описали, мені близький: видача набором фрагментів, і при кожному джерело, версія й дата документального стану.
Щодо копій на всі файли: ваша шкала форматів зі статті про артефакти якраз пояснює мій вибір. Щоб дістати фрагмент з верстки чи растру, текст однаково доводиться витягти, а це на вашій шкалі найдорожчий крок. Копія зберігає результат цього кроку, тож він не повторюється на кожен запит.
Зі статті про детекцію собі беру дві ідеї. Перша: негативний контроль, як ваш пончик з джемом, тобто запити, відповіді на які в корпусі немає. Друга: запити, виведені з посилань документів один на одного; у нормативних актах таких посилань повно, і набір можна добрати без ручного підбору. Розбіжність вердиктів у HYP-002 між сотнею документів і повним корпусом звучить для мене як пряме попередження.
Історія під архітектурною статтею, де дві версії проєкту злились у пошуку, теж влучила: редакції одного закону майже близнюки, тож фільтр за версією до самого пошуку мені тепер видається обов’язковим.
Розходимось ми хіба в масштабі: ваша серія про організацію зі статусами документів і правами доступу, а я роблю інструмент для однієї людини з її власною текою, тож шару курування в мене не буде. Тріаж фрагментів і довіра за способом видобутку при цьому потрібні так само.
У вашому списку наступних дослідів є юридичні тексти як корпус поза RFC. Якщо дійдете до нього, мені буде цікаво порівняти, що ламається у вас і в мене.
Дякую що поцікавилися моїми статтями. Я маю оновлені і розширені матеріалм але технічні обмеження ДОУ не спонукають мене до додаткових публікацій. Шукайте на GitHub.
Згадані вами (подані ним) дві ідеї на мою думку не найкращі, не варто їх віжразу сприймати і поспішати з реалізацією, звісно рішення за вами. Спробуйте, отримайте результат і знов порідвняйте його з проблемою і очікуванням її вирішення.
Ой справді ви особисто розумієте про що кажете? :)
ні не зовсім про це моя серія.
Але деякі підходи детекції і оцінки знань можливо є релевантними.
Сподіваюсь, що розумію. У досліді про користь пошуку ви порівнювали пошук по сирих абзацах і по кандидатах: на сотні RFC сирий текст трохи виграє, бо нагору спливають службові рядки шапок, а на повному корпусі пошук по сирому тексту сильно просідає, тоді як кандидати тримають той самий рівень. Для мене звідси урок простий: мій замір на невеликому наборі документів нічого не гарантує для великого архіву, і його треба повторити на більшому.
На GitHub прочитав главу про верифікацію бази знань, і там якраз є те, чого бракувало тим двом ідеям. Набір, на якому сам підбираєш налаштування, себе прикрашає, тож потрібен ще запечатаний, якого під час налаштування не бачиш. А випадки варто групувати за документом, щоб майже однакові тексти з одного джерела не опинились по обидва боки.
За уточнення про серію дякую: з книги видно, що вона про доказові системи для галузей з високою ціною помилки, і організаційний шар там лише одна з частин.
Чому так ви вирішили? Спробуйте розглянути варіант де це не нормально і зрозуміти саме чому.
От що це за хрінь? Запечатаний, прикрашає — стоп, подавайте ваші конкретні приклади а не ці от запечатані набори!
Архів, до якого ніхто не повертається, заважає пошуку: стара редакція документа знаходиться поруч з чинною, виглядає так само, і людина бере ту, що вище. У законодавстві це особливо гостро, бо сусідні редакції часто відрізняються кількома рядками.
Про «запечатаний набір» на прикладі. Вагу між пошуком за словами і пошуком за змістом я підбирав на тих самих 34 запитах, на яких потім і назвав 94%. Тобто цей результат підігнаний під знайомі запити, і на нових він найімовірніше буде нижчим. Тому наступного разу набір запитів ділиться надвоє: на одній частині підбирається вага, а результат міряється на другій, якої під час підбору ніхто не бачив.
Spotlight, а що, у віндах такого нема?
Щось схоже є, і вміст Word Windows теж індексує, якщо тека потрапила в індекс. Але результатом буде список файлів, і потрібний абзац далі шукаєш усередині кожного. Саме на цьому кроці я й губив час.
recoll
Дякую, Recoll гарний варіант для локального пошуку. Мені хотілось ще, щоб текстові копії документів лежали поруч з оригіналами і їх могли читати інші інструменти, зокрема AI-асистенти.
Можна замахатись і agentic rag зробити
Замахнутись можна, але агенту так само потрібен чистий і свіжий текст документів. Тому я почав з цього шару, а агентів можна підключити поверх нього.
Тоді, NotebookLM
NotebookLM зручний, коли документи можна завантажити в хмару Google. Мені треба було, щоб робочі документи лишались на компʼютері, а їхні текстові копії оновлювались самі після кожного збереження.
Вообще-то на маке стандартный системный поисковик вроде бы находит все вордовские документы, содержащие заданный в поиске абзац. Разве на Винде не так? Чтоб найти в PDF, скорее всего надо открывать каждый файл и искать там скриптом то, что надо. Если не ошибаюсь, продукты Adobe сделаны scriptable на всех платформах, так что там без проблем
На Windows Word теж знаходиться за вмістом, якщо тека в індексі. Скрипт по PDF працює, але його треба написати й підтримувати, а сканований PDF без OCR він не прочитає взагалі. Мені хотілось, щоб це робилось саме й одразу для всіх тек.