Добавлена опция склейки параграфов до минимального значения в символах

[audetv]

Добавлена опция склейки мелких параграфов до минимальной границы.

Значение по умолчанию установлено 800 символов.

Пул реквест пока повисит в статусе — открыт, позже сделаю слияние и выпуск.

При вызове парсера можно будет указать опцию ./book-parser.exe -m 250 и мелкие параграфы будут склеены до минимального размера, размер параграфа в символах станет не менее 250 символов.

Так же можно указать значение 0 при вызове ./book-parser.exe -m 0 и склейка параграфов производиться не будет, все будет как и ранее.

Вчера прогнал старый набор из 7733 файлов со склейкой параграфов до 800 символов, итоговое кол-во параграфов в БД уменьшилось до 4.6 миллионов вместо 22+ миллионов. Выигрыша в итоговом размере данных индекс и БД в Гб нет.
Немного уменьшилась БД postgess. но увеличился индекс мантикоры.

Планирую сегодня протестировать на локальном на фронтенде., как будет происходить поиск.

Я вчера сделал тестовый вариант, и потом было ваше сообщение, есть связь:

Если поискать сразу во всей книге с опцией «не далее чем столько символов», думаю деление на параграфы, возможно 2-3 параграфа, это будет наиболее оптимальным вариантом поиска. Это можно проверить. Про поиск в двух или трёх параграфах мы говорили ещё в начале. Но думаю на текущий момент и с одним всё в порядке.

#27 (comment)

[iprst]

Значение по умолчанию установлено 800 символов.

Правильно понимаю, что это значение отвечает за команду типа «обрабатывать все параграфы менее 800 символов»? Или сущность «мелкие параграфы» задана в алгоритме как-то иначе?

[iprst]

Вчера прогнал старый набор из 7733 файлов со склейкой параграфов до 800 символов, итоговое кол-во параграфов в БД уменьшилось до 4.6 миллионов вместо 22+ миллионов. Выигрыша в итоговом размере данных индекс и БД в Гб нет.
Немного уменьшилась БД postgess. но увеличился индекс мантикоры.

Ну тут очевидно выигрыш в логике — «мелкие параграфы» это по большей части мусор, который при склейке обретает как минимум в теории какой-то смысл при обработке словосочетаний и расстояний.

[audetv]

Логика такая, парсится параграф и проверяется его длина, если она менее 800 символов, то параграф не записывается в БД, а записывается в буфер, далее прасер читает следующий параграф и склеивает то, что было в буфере с тем что прочитал сейчас, сравнивает итоговую длину склеенных параграфов, если длина менее 800 символов, то операция повторяется, если длина более 800 происходит запись результата в БД.

Значение 800 можем изменить, задать произвольное при запуске парсера.

Вот пример из БД как это выглядит по длинам:

Один из удачных на мой взгляд примеров склейки:

Есть примеры концентрированного мусора, хотя еще надо разбираться)

[iprst]

Логика такая, парсится параграф и проверяется его длина, если она менее 800 символов, то параграф не записывается в БД, а записывается в буфер, далее прасер читает следующий параграф и склеивает то, что было в буфере с тем что прочитал сейчас, сравнивает итоговую длину склеенных параграфов, если длина менее 800 символов, то операция повторяется, если длина более 800 происходит запись результата в БД.

Ага — «склеиваем все параграфы, пока не наберём значение».
В таком случае можно 800 смело увеличить вдвое. Визуально параграфы будут чуть длиннее среднего обычного, но будут содержать примерно то же количество информации в байтах. Впрочем это на глаз, а можно и реальное среднее значение узнать из базы.

Один из удачных на мой взгляд примеров склейки:

Да, отлично. Это и ожидалось.

Есть примеры концентрированного мусора, хотя еще надо разбираться)

Какие-то дивы обрезались и пролезли. Нужно по файлам пройтись c regex-ом.

[audetv]

Позже могу обновить БД на сервере, и можно оценить , что получилось со склейкой и с новыми файлами, но ближе к вечеру. Если ок, оставляем вариант со склейкой, или скорректируем. Можно сейчас скорректировать длину параграфа 800 символов если есть предложения.

При выборе значения 800, я руководствовался записями из это темы:

По моим замерам «нормальный» параграф лежит в разбеге от 800 символов / 100 слов до 2500 символов / 300 слов. Верхнюю границу наверное можно удвоить, и получить максимум — 5000 символов / 600 слов. В книгах ВП СССР есть сноски длиннее этой границы (легко найти 6000 символов / 1000 слов), но вроде бы в обычной литературе такое очень редко.

#23 (comment)

[audetv]

Какие-то дивы обрезались и пролезли. Нужно по файлам пройтись c regex-ом.

Это скорее всего результат работы regex где-то был сбой и поломалась html структура, например когда вырезаны были некоторые теги и с ними кавычки «"» эти кавычки обрамляют классы и дата атрибуты, если порядок нарушен, то стандартные парсеры xml не сможет адекватно прочитать строку и будут артефакты.

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

[iprst]

Позже могу обновить БД на сервере, и можно оценить , что получилось со склейкой и с новыми файлами, но ближе к вечеру. Если ок, оставляем вариант со склейкой, или скорректируем. Можно сейчас скорректировать длину параграфа 800 символов если есть предложения.

Я попытаюсь добить длинные параграфы и предлагаю уже обновлять с новыми файлами, я их подгружу туда же, и просто те что в архиве нужно будет заменить на новые (чтобы не собирать и не перекачивать весь архив).

При выборе значения 800, я руководствовался записями из это темы:

По моим замерам «нормальный» параграф лежит в разбеге от 800 символов / 100 слов до 2500 символов / 300 слов

Так всё верно — 1х = 800/100 символов/слов, 3х=2500/300 символов/слов, соответственно «средний» будет как раз 2х = 1500/200 символов/слов. У меня была указана вилка минимум/максимум, вы взяли по минимальной оценке, это логично, а я предлагаю взять по средней оценке, иными словами к параграфам «минимальным» будет добавляться обрезок например заголовок, таблица и так далее. Пусть все параграфы в целом усредняются, нам это ничем не мешает, только улучшает систематическое поведение алгоритмов по вхождению, расстоянию и тд. С той же целью бьются большие параграфы — чтобы улучшить поведение системы, выдавать более предсказуемые результаты.

[audetv]

Какие-то дивы обрезались и пролезли. Нужно по файлам пройтись c regex-ом.

Это скорее всего результат работы regex где-то был сбой и поломалась html структура, например когда вырезаны были некоторые теги и с ними кавычки «"» эти кавычки обрамляют классы и дата атрибуты, если порядок нарушен, то стандартные парсеры xml не сможет адекватно прочитать строку и будут артефакты.

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

Посмотрел, сделал этот же запрос без <div> в строке запроса и были показаны те же параграфы но без дивов, это режим мантикоры что ли такой. в общем буду разбираться, пока не надо regex-ом проходить, возможно ложная тревога.

Details

[iprst]

Посмотрел, сделал этот же запрос без <div> в строке запроса и были показаны те же параграфы но без дивов, это режим мантикоры что ли такой. в общем буду разбираться, пока не надо regex-ом проходить, возможно ложная тревога.

Внутри файлов таких ошибок не нашлось, запрос [0-9a-zа-я]div> не дал ни одного результата. Так что это уже дальше по ходу дела появляется.

Если мантикора ищет внутри тегов, тогда видимо логично, слэш / в закрывающих тегах отбрасывает как escape-символ и показывает остаток тега как текст. Если поискать закрывающий див, то так и получается.

[iprst]

Хотел протестировать локально, но так понимаю что соответствующий .exe пока ещё не собран. Буду ждать, интересно прогнать локально, посмотреть, что получится.

[audetv]

да, не успел выгрузить, сделал выпуск:
https://github.com/terratensor/book-parser/releases/tag/v.0.2.0