Open iprst opened 1 year ago
Не слишком удобный размер шрифта в нижней строке окна выбора короткой ссылки:
Может уменьшим его на пару пунктов? ПС. И сделать бы окно автоматически закрывающимся после действия — клика по кнопке, использования меню «копировать» или комбинации клавиш CRTL+C.
А есть ли в мантикоре метод, который показывает статистику по всем размеченным словам в базе?
Я не припомню такого метода, не встречал в документации. Надо описать, что мы хотим видеть и придумать алгоритм, который даст такую статистику.
Нам нужен метод, чтобы получить список токенов по всем документам? Странно, что такого метода нет, надо будет посмотреть на форуме, возможно там задавали подобный вопрос.
Есть методы чтобы получать доп. информацию в конкретном запросе (show meta) есть статус индекса и другие статусы (agent, node, threads), но там нет подробной информации по словам. Например, статус индекса дает такое:
mysql> show index common_library status;
+-----------------------------+-----------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
+-----------------------------+-----------------------------------------------------------------------------------------------------------+
| index_type | local |
| indexed_documents | 3830279 |
| indexed_bytes | 14942883771 |
| ram_bytes | 4216 |
| disk_bytes | 35365919438 |
| disk_mapped | 561973649 |
| disk_mapped_cached | 0 |
| disk_mapped_doclists | 0 |
| disk_mapped_cached_doclists | 0 |
| disk_mapped_hitlists | 0 |
| disk_mapped_cached_hitlists | 0 |
| killed_documents | 0 |
| killed_rate | 0.00% |
| query_time_1min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| query_time_5min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| query_time_15min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| query_time_total | {"queries":829, "avg_sec":0.135, "min_sec":0.000, "max_sec":10.945, "pct95_sec":0.208, "pct99_sec":2.855} |
| found_rows_1min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_5min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_15min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_total | {"queries":829, "avg":126672, "min":0, "max":3830279, "pct95":253944, "pct99":3830279} |
+-----------------------------+-----------------------------------------------------------------------------------------------------------+
Но тут только кол-в документов и байтов, и статистика запросов.
upd: Форум мантикоры: https://forum.manticoresearch.com/ Там ребята и русском языке отвечают, можно сформулировать вопрос и задать. Возможно, что это есть в доп. функциях, но я это не могу понять.
Форум мантикоры: https://forum.manticoresearch.com/ Там ребята и русском языке отвечают, можно сформулировать вопрос и задать. Возможно, что это есть в доп. функциях, но я это не могу понять.
Надо обратить внимание на эти ссылки:
https://manual.manticoresearch.com/References#Indextool https://manual.manticoresearch.com/References#Wordbreaker https://manual.manticoresearch.com/References#Spelldump
Предполагаю где-то там скрывается нужный нам метод
Я не припомню такого метода, не встречал в документации. Надо описать, что мы хотим видеть и придумать алгоритм, который даст такую статистику.
В самом предельном смысле хотелось бы получить полную карту слов или их токенизаций — разных слов не будет так уж много, должно быть меньше миллиона, скорее всего в районе 250 тысяч. Карта отображается в виде графа, связи между словами имеют вес, соответствующий связям двух слов во всём корпусе текста, и тд. В общем, это стандартное представление, но думаю нам оно будет очень полезно. Разумеется, если его можно реализовать какими-то доступными средствами, пока не будем упираться рогами в изобретение метода с нуля, просто подумать, держать в голове.
Основное предназначение карты, скорее относится к новой библиотеке К150 (или к ещё большему её старшему брату «вообще всех книг на русском» около миллиона изданий включая художку) — побитие в ней книг на темы абсолютно умозрительное и не соответствует реальному положению дел. В основном потому, что любое побитие множества на подмножества с помощью фиктивных оценок это изначально глупая задача. Мы решаем вопрос — как побить литературу на подмножества, в которых было бы эффективно проводить поиск, например при поиске физического явления не получать эзотерическую практику или экономический отчёт.
Это задача не высокой срочности, но важность её достаточно высока, поэтому пусть в голове полежит, пишу на будущее.
Есть методы чтобы получать доп. информацию в конкретном запросе (show meta) есть статус индекса и другие статусы (agent, node, threads), но там нет подробной информации по словам. Например, статус индекса дает такое:
Наверное нам нужно смотреть на воображаемый граф и думать над: — размером узла (количество повторений слова) — длиной ребра (функция от частоты встречи двух слов на расстоянии Х)
Что-то в таком духе. Я думаю что это стандартная технически задача в целом, но не думаю что её реализация есть в мантикоре из коробки, но тут я знаю меньше и потому вопрос.
Что ещё касается всех библиотек, появилось мнение в результате тестирования.
Нужно пересмотреть отдачу контекста по формуле 3+p+3 в сторону 1+p+Х, поскольку практически никогда два избыточных параграфа в начале контекста не требовались. Чаще всего суть вопроса понятна прямо из оригинального параграфа, иногда из идущего перед ним, но параграфы выше лишь занимают место.
В целом представляется, что для контекста достаточно формулы 1+p+3, то есть всего пять параграфов на странице.
Что ещё касается всех библиотек, появилось мнение в результате тестирования.
Нужно пересмотреть отдачу контекста по формуле 3+p+3 в сторону 1+p+Х, поскольку практически никогда два избыточных параграфа в начале контекста не требовались. Чаще всего суть вопроса понятна прямо из оригинального параграфа, иногда из идущего перед ним, но параграфы выше лишь занимают место.
В целом представляется, что для контекста достаточно формулы 1+p+3, то есть всего пять параграфов на странице.
Да, согласен. Замечал такое, обычно проматывал до середины текста в поисках исходного параграфа и потом начинал движение по тексту, текст выше просматривал, но почти никогда не читал все 7 параграфов. Это по моим наблюдениям, восстановленным из памяти, после вашего сообщения.
Замечал такое, обычно проматывал до середины текста в поисках исходного параграфа и потом начинал движение по тексту, текст выше просматривал, но почти никогда не читал все 7 параграфов.
Возможно и предыдущий параграф можно попробовать не показывать, но может быть показывать всё как сейчас, однако перематывать страницу сразу к id целевого параграфа?
Замечал такое, обычно проматывал до середины текста в поисках исходного параграфа и потом начинал движение по тексту, текст выше просматривал, но почти никогда не читал все 7 параграфов.
Возможно и предыдущий параграф можно попробовать не показывать, но может быть показывать всё как сейчас, однако перематывать страницу сразу к id целевого параграфа?
Перематывать к целевому (исходному) параграфу, с которого нажали контекст, кажется логичным. И кажется логичным изменить схему формирования контекста 1+p+3. Такой вариант мне кажется самым оптимальным.
Здесь собираем обратную связь и собственные наблюдения о процессе тестирования поиска по военно-исторической библиотеке. Из собранных здесь наблюдений, замечаний и предложений можно формировать отдельные issue.
Данный комментарий можно использовать для сбора задач, например:
Отключить сервис коротких ссылок на период тестирования;И так далее. Если предложение проходит проверку обсуждением, добавляем его в этот список и/или открываем issue.