Тестирование поиска по военно-исторической библиотеке #39
Comments
|
Идея интересная, надо посмотреть выдачу, поизучать. Как вариант — да, но, похоже, надо доработать условие, предлагаю еще добавить: если строка начинается с длинного тире Еще: Строка заканчивается двоеточием. По поводу N, его как-то надо определить. В начале можно просто интуитивно выбрать значение. Понадобится доработка парсера, нужно будет все параграфы пропускать через второй фильтр, не только длинные, убирать открывающие и закрывающие div, или вообще эти
Пока думаю, пытаюсь составить запрос, который бы выполнился и не упал, вместе с докером, который бы показал, только дублированные параграфы. Ищу «автоматическое» решение. |
|
Подумал, пока смотрел «Хамовнические казармы» в одной из цитат есть стихотворение — четверостишие
Вот так, объединяя параграфы, мы нашли один из способов парсить стихи. Посмотрел, что иногда диалоги начинаются с обычного тире, например, но в данном случае может попасть под условие N:
Делаем issue по пункту 1?
Предполагаю, о замеченных условиях для объединения/разделения (тире, двоеточие и т.д.) можно писать отдельно и таких условий может набраться N-ое кол-во. |
Да, отлично. Условие по тире можно расширить до любого (почти любого) символа, не являющегося буквой
Верно. Далее будет идти список, или цитата, или ещё какая-то «неразрывная» часть текста. то есть
Так точно. Для того и взята пара месяцев, не спешить с парсером, а погонять в нормальном режиме поисковик, ощутить на шкуре что и как, не спеша. Уже можно не спешить, пусть спокойно собирается ОС, пусть люди придут, начнут щупать, ругать или хвалить, сами пощупаем, поймём что к чему. Мы же как и остальные пока не пользовались, по сути. В качестве смены деятельности можно заняться геодезией )))
Ага. Добавляем в список, потом из него сделаем issue. |
N скорее всего это про оптимальную длину параграфа, которая отмечена первым пунктом в «задачах». Есть проверяемое предположение, что максимум это N×2, а минимум это N/2. В принципе математически это следует из наклона графика длины параграфа, который говорит что левый хвост, то есть минимум, короче правого хвоста, то есть максимума. Физический смысл этого выражения в том, что параграфы склеиваются более эффективно и плотно, чем разделяются. Это логично: мелких обрезков изначально на несколько порядков больше, чем длинных портянок, этим и обеспечивается наклон. Думаю «двойной эн» и «половина эн» это вполне рабочая схема — таким образом вместо определения трёх чисел нужно задать всего одно.
Совершенно верно. Собственно, когда вы про короткие параграфы описали вашу схему в прошлой теме, у меня зачесались руки закрыть тот старый issue, но мы однако не формализовали до конца условия по «стихам» и соответственно это не вполне «решение» — задача особо не поставлена, на уровне идеи. Нужно сформулировать и закрыть. Тут сейчас найден способ собирать строки в строфы, однако нет никакого условия по разделителям строф (четверостишия, или длинные 16 строк и тд) — возможно добавить это в условия парсеру, только как-то сформулировать логику.
Думаю пусть пока висит списком, лучше собрать идей, скорее всего начнутся пересечения и дополнения. Добавил идею в список в начальном комментарии.
Да. Пока записал про «окончание двоеточием» и «начало не с буквы», но можно разбивать на отдельные пункты. |
|
Есть сценарий использования поисковика, который у меня постоянно всплывает — копирование какого-то текста в браузере и поиск его в lib.svodd.ru В хроме есть опция в меню ПКМ search google for …, есть и для других поисковых систем, а также существуют полезные надстройки для такого же поиска в википедии — выделил слово, ПКМ, пункт меню «искать там-то». Очень полезным может быть метод поиска выделенного в тексте на странице любого сайта в нашем поисковике — выделил, ПКМ → «поискать lib.svodd» Идея на будущее. |
Я сегодня не один раз, когда копировал какую либо фразу в поиск, думал, что нужна такая функция. А вот расширение в браузер может быть интереснее, так что почитаю как делать, в фоне задача будет. Я пока вообще ничего про это не знаю. Но это пока. |
Да, именно браузерное расширение я имею в виду. |
|
Отправил письмо со ссылкой, Так же получен из manticore список книг: Файл: Список книг с кол-вом уникальных параграфов.xlsx Со списком параграфов не представляю как работать, смысла в нем далее видимо нет. Например книга: Бабель И. Конармия, всего параграфов 19, уникальных 13, соответственно в списке дублированных параграфов (файл - архив) я нашел 6 записей - параграфов, данные совпали. Кол-во книг, в которых содержатся дублированные параграфы — 2742 шт. |
Удалить дублированные параграфы из базы самое простое решение, но при каждом новой обработке docx файлов парсером, после обработки нужно будет проверять на дубли и удалять их снова из базы, как то это выглядит не рационально, поэтому думаю, что можно сделать. |
Можно его открыть в Sublime или PowerGREP или в подобных редакторах, работающих с regex, и найти подходящий перебиратель дубликатов, который автоматически заменит дубли. Я вчера пробовал делать это внутри docx архивов (полученных из html они самые подозрительные) посредством PowerGREP, в принципе работает, но после очень долгого подсчёта оставшегося времени (где-то час считал), он показал что осталось что-то типа 90 часов, и я выключил — вероятно формула не очень эффективная или docx слишком медленный. Внутри одного файла должно быть быстрее. |
Попробовать сличить список «содержащие дубликаты» и файл html-to-docx — есть подозрение, что они совпадают на 100% в том списке 2784 файла, а у вас получилось 2742. Все дубликаты, которые мне попались вручную при использовании поисковика, кроме тех, у которых чуть разные названия книг которые я пропустил — это были именно дубли внутри одного файла, и это были файлы экспорта из html. |
|
Если установим, что проблема возникает именно в файлах из списке html-to-docx, то просто зачистим сами файлы, пусть даже нерациональным методом на 90 часов обработки, пусть так, зато навсегда. Если проблема шире, то будем смотреть откуда ещё она прилетает системно, пока не представляю. |
В размещенном файле, уже список дублированных параграфов и имя книги, там зафиксирован сам факт, что параграфы повторяются и текст повторяющегося параграфа. В этом файле нет смысла что-то менять, он похоже больше для ознакомления.
Да, хорошо, для начала сравню списки. Потому как начал искать решение, нашел LHS, hash, minhash, simhash и прочее, проблема известная, имеет несколько реализаций, знакома гуглам , яндексам для удаления дублей html станиц и т.д. Например, адреса |
Понял. Я уже потом сообразил, что написал ерунду, но не стал удалять, логика в целом подходит для других объектов, которые можно ре-импортировать в базу.
Так понятно что можно посчитать какие-то хэши в базе и таким образом зачистить дубликаты, но это выгодно на уровне той базы, которая работает с динамическими данными, а так как у нас набор статический, следует обрабатывать сам набор. Вы то же пишете далее.
Существует вопрос актуальности такой задачи — ваше время это ресурс, и пока к нам никто из программистов не присодинился, приходится ваш ресурс учитывать в наиболее оптимальной мере, как это представляется. |
Пока мы даже не добрались до геодезии, а в поисковиках можно зависнуть надолго. |
Да, согласен, но похоже, нужна будет ваша помощь. Я уже не первый день думаю с чего начать, ещё с прошлой недели, я ни один раз прочитал файлы с описанием в геоматрице, но пока так и не смог найти ту ниточку, чтобы образно потянуть и распутать клубок в голове, для меня это еще не сложилось в мозаику, то какой должна быть программа. Ощущение, что близко и вот вот, но пока не сформировал мысль, да и короткие/длинные параграфы на той неделе плотно отвлекли, но итог — запустили библиотеку. И теперь надо начинать. Самое сложное для меня сейчас - это выбрать и с чего то начать. Продолжу далее в геоматрице. |
|
Бот-комментатор, цитирующий относительно случайным образом 1-2 результата выдачи по запросу из «специальных слов», размеченных в системе и найденных в комментарии. Кто-то пишет: «текст текст текст текст текст текст РАБЫ текст текст текст текст САХАР текст текст текст текст текст текст ФРАНЦИЯ» — система ищет «рабы сахар франция» и получает 31 замечательный результат, из которого можно выбрать ответ. Можно гарантировать, что это будет фурор. Протестировать можно без бота, обработав любой комментарий таким образом, взяв из него 3-4 ключевых слова. |
Ага, получится генератор контента, кто-то назовет его ИИ, только в отличии от веб 2.0 совсем иного рода генратор, можно и в телегу выдавать результат, а можно на специальную страницу, на сайте. В установленные промежутки бот будет комментировать. Но вот как определить эти 3-4 слова? Можно, например, закинуть все фразу комментария в запрос: Получить статистику слов: На этой статистики рассчитать tf и tf-idf Получится типа такого: Как-то на основании этих расчетов и плюс еще что-то: рандом, наличие терминов из концептуального словаря или специального другого словаря добавляли бы ранг слову , для решения по его выбору для запроса. Пока все. |
Есть таблица специального словаря, примерно того типа как вы показывали в примере с контент-якорями из «интересных слов». Мы тогда сошлись на том, что ребята изобрели словарь наших сущностей. Далее к этой таблице прикручивается вторая таблица, например частот появления слов и расстояний между якорем и целевым словом. Можно найти и другие подобные критерии. Это уже ближе к ИИ, но не обязательно ИИ, это просто таблица. Соответственно из всех доступных статистических методов включая эти считается некий ранг слова и к нему ищутся 2-3 спутника, вот и получается запрос. Он не всегда будет блестящим, но фурор точно будет.
Да. Это на будушее, и в котелок закинуть, чтобы варилось. НА НЕСУЩЕСТВУЮЩИЕ ЗАПРОСЫ |
|
Может быть ум за разум зашёл, но зачем я написал что нужно отключить короткие ссылки (и оставить кнопку контекста) когда нужно было сделать наоборот? Или нет? Не соображу условий полностью. Но вроде коротким ссылкам всё равно какой длины параграфы и как они побиты — имеет значение только термины запроса. А вот контекст полностью зависит от того, как побиты параграфы и какие у них uuid. |
|
Зашел, и у меня зашел разум, я когда отключал, думал только о параграфах, потом была мысль написать, а зачем мы ссылки отключили, но не написал, тестируем и прочее, хотя сегодня опять утром была мысль написать, давайте включим ссылки, Мы как-то с вами обсуждали короткую ссылку на контекст, что она будет основным доказательством в баталиях, вот такие ссылки сейчас не надо создавать, но такого функционал еще и нет, я его не написал. Так что, мне кажется надо включать ссылки для поисковой строки и пользоваться, а то, судя по статистике, вечера народ без коротких ссылок даже ленится вбивать поисковые запросы в строку, переходят, смотрят, а вбить «галичина 22 июля» не все смогли. |
Ага, вот тут он у меня и зашёл — перепутал проектируемую идею с текущей реализацией и функционалом контекста. Сомнамбулизм!
Да, конечно включаем. Изначально зря отключены, имелся в виду контекст и короткая ссылка на него, а у нас этих сущностей пока нет и отключать нечего.
)))))) |
|
Готово, включил ссылки |
Сразу воспользовался. Игоревич в теме по делу дал предположение, хорошая ОС. Как раз про «галичину 22 июля». |
|
Нужно будет разместить ссылку на военно-исторический поиск в меню сайта. |
Надо придумать сокращенное наименование в верхнее меню, может быть одно слово — «Поиск» |
Текущий вариант действительно нормальный, но когда кончится место и нужно будет сокращать, можно попробовать заменить на «военная история». |
Пока вызвало отрицательную реакцию, осмыслил, похоже связано с тем, что я сходу не знаю как это решить нормально, т.е. эта вроде бы легкая задача тянет у меня в голове такие цепочки, что я под ними сгибаюсь, как думать начинаю.., Происходит выход на уровень javascript, на сторону клиента - пользователя, (это на самом деле и есть фронтенд, то что загружено у клиента (пользователя) в браузере), а эта сфера для меня хоть и не новая, но в ней я имею мало опыта и навыка, написания различных сложных плагинов. Обычно задачи звучат просто, а вырастают в недели работы над фичей с одной кнопкой. В js надо предусматривать кучу вариантов и особенностей работы с интерфейсом браузера, это как бы другая часть разработки, другой уровень абстракций, я обычно нахожусь где-то на стороне сервера, там в глубине ближе к БД, к железу и прыгать с уровня на уровень, бывает тяжело, точно затратно для мозга, вот и реакция. Cтарюсь делать так, если есть что-то готовое, то лучше это взять и попробовать прикрутить, не факт что это будет быстро, но точно быстрее, чем самому изобретать. Вспоминаю, диаграмму график СВОДД, я не одну неделю погружался в эту библиотеку, чтобы ее нормально прикрутить сюда ) С реакцией разобрались) Вопрос, сейчас на десктопе, я так понимаю, хватает места для просмотра, я имею ввиду, что меню сверху и строка поиска не мешают просмотру контента? В мобильном версии и на планшете, это меню в таком виде вообще не отображается, видна только плашка со звездой и кнопка меню, по нажатии которой уже и открывается меню сайта. Я пользуюсь, не 100% доволен, но особого неудобства не испытывал. Details
Вот при просмотре в мобильном у меня иногда возникала мысль убрать верхнюю плашку со звездой и оставить только поисковую строку, но тут же сразу момент вылезает с кнопкой меню, это 3 точки горизонтальных, места они занимают, как кнопка настройки поиска, если это смещать влево, то сама строка поиска уже становиться меньше. И по хорошему сделать это надо так, чтобы в итоге меню и поиск нормально работали и выглядели и на деск топе и на мобилке, То решение, которое сейчас на сайте, я брал в bootstrap как шаблон для меню, и не изобретал своего модуля. В общем это плавно приводит к тому, что надо переделать интерфейс программы. Вот возможно в эту сторону и надо нам будет посмотреть? Еще чуть далее, через пару - тройку сервисов будет понятно, что с этим делать, как располагать элементы, точнее, какие элементы интерфейса вообще получаются. Начиналось то с: поиск, статистика, обсуждение, вопросы. Кстати возможно (технически точно возможно, это быстро, и я умею) надо будет сгруппировать пункты ФКТ в один пункт меню. Чтобы он был выпадающим, как смена темы, и там открывались остальные пункты, не уверен пока в этом. Если меню будет внизу, то пока не понятно, как оно будет отображаться на декстопе, скорее всего такая же кнопка будет меню внизу где то, внизу блок навигации и меню. И все это еще раз плавно выводит меня к тому, что я давно хочу сделать и видимо мы придем к этому рано или поздно и я сделаю. Надо написать фронтенд на js, на reactjs и вот тогда будет раздолье работать с интерфейсом, так уже гораздо проще подключать библиотеки и менять вид приложения. В reactjs у меня меньше опыта, но он есть, делать на Reactjs программу совсем с нуля, я бы не стал, так как долго буду делать выпуск, а вот если уже повторить то, что сделано и улучшить, самое то. И технически к этому почти все готово. Кроме авторизации, которую надо обсудить. Еще мне кажется, что это будет правильнее с точки зрения создания приложения — библиотеки, которую можно установить на локальном компьютере, в которое пользователь может подключать свои БД или подключаться к нашей бд, или пользоваться облачной версией в веб и ничего не ставить. Но все это время, а столько хочется сделать! Надо будет в итоге переписать бэкенд приложения и фронтенд, но мы уже скоро будем иметь рабочую версию, и надо не с нуля все писать. Вот такие мысли от такого простого предложения вылезают. Пока не знаю, что с этим делать, дал ли ответ на вопросы, но мнение точно высказал) Пока не охота залеаать в интерфейс. |
Это если мы используем вариант страница контекста для всех поисков на отдельном поддомене, как отдельный сервис. Как вариант да, но если в этом сервере будет сотни, тысячи или десятки тысяч ссылок, это все вообще не стоить того)) Если много ссылок, да. Но если сервис будет популярен, да это и без если наверное имеет смысл, то только что опубликованная ссылка на форуме чаше просматривается, чем старые ссылки. |
В итоге, я вижу так: Наверху строка с поиском — блок с поиском без каких либо дополнительных меню, строку с поиском можно скрывать при прокрутке вниз, но предлагаю еще подумать над этим, ведь у нас основная цель это поиск, с другой стороны, получаемая лента под запросом, сама может быть как отдельная книга, и результаты этой книги надо почитать, а не просто прокрутить. Так что возможно не исключаю, что скрывать строку с поиском будет лучше. Можно вообще эту опцию в итоге вынести в настройки и пользователь сам решит скрывать панель с поиском или нет, хотя судя по коротким ссылкам пока пользователи в основном переходят по ссылке и потребляют, что им предлагают, сами не ищут в массе, так что и настройкой пользоваться не будут. Внизу блок управления и кнопка меню, при нажатии открывается отдельная страница меню, или слой меню на деск топе, и там происходит работа с сайтом. Управления, переключение страниц, клавиши вверх вниз. Смесь читалки с сайтом? читалка получается))) Но хочется где-нибудь ставить звезду, пока не знаю где. |
Это не срочная задача, а цель для обдумывания в принципе. Можно сформулировать её так — меню и строка поиска занимают место в таких сценариях, где это место будет полезнее отдать информации. Например как это сделано на странице контекста.
Тип устройства влияет только на процент экранного места, но не на суть фактора среды. По сути в режиме чтения меню отнимают полезную площадь экрана. Вопрос по сути в том, нужно ли чтобы это происходило, или нет. То, что с этим можно жить понятно.
В мобильной версии так сделать будет логично.
Да. Сейчас просто собираем наблюдения. Ничего не делаем с ними, просто собираем и пусть они прорастают.
Возможно убрать вообще пункты «поиск», «коб», «фкт», «военно-историческая библиотека» из меню, а сделать их опциями выбора в едином поисковике, типа «искать в…» или что-то подобное.
Пока собираются наблюдения можно раздумывать над решениями. Всё это не критично на текущий момент. Возможно кто-то начнёт пользоваться и придёт сюда помогать с программированием. |
Это логично, но кажется решается другая проблема, типа независимость наследования реальных коротких ссылок от факторов переезда и разработки — пока идёт время изменений, небольшая табличка с сохранённым текстом для выдачи в коротких ссылках на контекст не станет слишком большой за время изменений и нахождения устойчивой схемы работы сервиса. А когда схема будет оформлена и реализована, короткие ссылки уже будут формироваться согласно этой схеме, а сохранившиеся в переходной табличке данные можно будет распарсить в номера id соответствующих параграфов внутри этой сформированной системы. Типа сейчас храним текст параграфов А, Б, В, а потом окажется что это будут параграфы x1. x2. x3. x4. x5. x6. x7. x8. x9 и так далее. Не важно что их число и id могут измениться. По сути параграфы хранятся в переходной таблице только для того, чтобы потом безболезненно перейти от АБВ к х1-9. |
Я тоже думаю что пункты меню, управляющие функционалом поисковика, имеет смысл из меню убрать, а вместо этого сделать их опциями поиска в той или иной форме. Таким образом само меню в итоге избавившись от «поиска» становится вопросами, обсуждением и статистикой. Статистику можно вообще убрать в иконку и сбросить в футер страницы, это вспомогательная функция. Таким образом остаётся только обсуждение на ФКТ и вопросы на ФКТ. Тут уже можно думать, какое место эти сущности занимают в структуре данных. Можно проецировать в будущее, и тд.
Очень маленькая выборка — пока что прошло слишком мало времени. Произвол это штука, которая нарабатывается со временем, сначала должна набраться критическая масса «просто просмотров». Именно поэтому эту тему сейчас я рассматриваю чисто как сброс наблюдений, которые только потом будут собираться — пусть они сначала обработаются в бессознательном режиме, пронаблюдаются ещё, создастся стереотип узнавания. То есть сейчас здесь мы сбрасываем ПФУ-1 и ПФУ-2. Можно к дальнейшим пунктам пока даже не переходить. Пусть обработаются в режиме «количество переходит в качество». А вместо высокочастотных решений по поисковику можно заняться более глобальной схемой. Поисковик нормально работает, всё что нужно он делает, а после сбора ОС и наблюдений к нему будут добавлены улучшения. |
Я сейчас вспоминаю, что ранее мы с вами обсуждали эту задачу и в ходе обсуждения были сформированы такие мысли, Делаем ссылку на контекст и контекст формируется обычным образом из текущих идентификаторов, из центрального uuid и соседних integer id. В тот момент, когда необходимо переиндексировать БД какого-либо из поисков, можно запускать процедуру сохранения этих параграфов в БД контекста в виде сброса центрального параграфа (можно и полный текст сбрасывать, обсудить) или полного текста параграфов, для последующего восстановления, а в случае если автоматического восстановление не удастся (по каким то причинам), то эти параграфы могут далее храниться в виде содержания полного текста в базе данных сервиса контекста и оттуда в этом виде и отдаваться до завершения процедуры нахождения нужного параграфа в новой БД. Я думаю, я переформулировал мысль и так не звучало, но мы с вами обсуждали что-то в этом направлении, надо будет найти это в обсуждении, почитаю ещё. Далее если приложить уже продолжение сегодняшней мысли: текст можно хранить в сжатом виде для экономии ресурсов диска, но при установлении постоянного обращения к такому сжатому тексту, при возникновении проблем с производительностью, можно применить схему кэширования для популярных параграфов контекста. |
Да, собственно это продолжение или ответвление этой мысли и было — чтобы не изобретать механизм пересчёта идентификаторов между базами, можно хранить сам текст, а потом в новой базе поиском установить все идентификаторы этого текста. Чтобы текст не тянул место, можно хранить его в пожатом виде.
А это уже продолжение этой мысли, всё так. |
|
По поводу коротких ссылок для контекста, мы обсуждали и у меня сложилось некоторое непонимание. Есть ли смысл делать для контекста отдельно короткие ссылки, я имею ввиду, повторять механизм коротких ссылок именно для поддомена quote? типа Мы можем использовать обычные короткие ссылки Т.е. страницы контекста будут иметь адрес |
Нет, второй сервис коротких ссылок конечно не нужен. Нужен сервис цитирования, поддомен quote который пока только обсуждался, но нетронут в реальности, то есть сейчас у нас в большой библиотеке нельзя поделиться контекстом, ссылка сейчас это чисто заглушка для адресной строки. Когда система с uuid параграфами и их отбором будет готова, и ссылку можно будет генерировать правильным образом, сокращать её можно будет тем же сервисом сокращений, который у нас уже существует. |
На всякий: МОСКВА, 31 июля. /ТАСС/. Президент РФ Владимир Путин подписал закон, который запрещает регистрацию на отечественных сайтах с помощью иностранной электронной почты. Документ опубликован на официальном портале правовой информации. Согласно закону, с 1 декабря на российских сайтах, предполагающих регистрацию и аутентификацию пользователя, нельзя будет зарегистрироваться через иностранную почту или аккаунты, подключенные через иностранные сервисы, например Google или Apple ID. |
|
Из наблюдений за функционалом ВИБ. Нужно реализовать метод помечания и сохранения в личном кабинете подходящих под тот или иной запрос параграфов, притом такой, который позволял бы организовывать избранные параграфы в группы, возможно персональное и/или публичное облако тегов, возможно группы в отметках или любой подобный метод. Пользовательский кейс можно собрать очень интересный — представьте, что вы искали какую-то информацию по обширной теме, и использовали несколько запросов, листали кучу страниц, и вот набралось 40-50 цитат. Их можно с помощью отметок объединить в ленту, и делиться ею с помощью коротких ссылок, или не делиться, а просто для своей работы иметь под рукой что-то вроде реферата из цитат. При этом можно ленту редактировать, пополнять новым и удалять неудачные записи. Да, можно конечно копировать текст цитаты и источник в отдельный документ, но тут функционал именно для упрощения этого отбора, чтобы не отвлекаться на технические паузы, вместо этого продолжать поиск и разметку. А результаты можно смотреть сразу в личном кабинете в соседнем окне браузера. |
Ну вот, и немного в плюс понимания к будущей регистрации на наших сервисах. Чувствую тенденцию к ограничению в будущем собственных сервисов авторизации и аутентификации, или вообще эта деятельность в перечень лицензированной перейдет. Сделать свой сервис авторизации регистрации, с одной стороны просто, но возможно вскоре будет лучше и проще пользоваться сервисами гигантов ВК, Яндекс или Госуслуги и не заморачиваться контролем у себя. Outh 2 Oauth2 схема давно распространена, особенно гугл авторизация. Она бесплатная, почти (вроде, до нескольких тысяч пользователей) и разработчиков на многих курсах и обучениях, книгах на нее подсаживают, просто пишешь пару строк кода и имеешь готовый модуль на сайте. Будет и хороший бизнес. Нормальный закон. И в целом для такого шага есть веские причины, интересно посмотреть будет как скоро с крупных ресурсов начнут скулить различные псины. И еще бы ВК - mail.ru побороли бы своих как бы бесконтрольно выпускаемых ботов… Посмотрим. |
Уже вовсю. На хабре например, с первых комментариев слёзки крокодильчиков «ай я не разобрался сложный закон», «ничего они тоже» и плюсики, плюсики. В общем всё по обычным рельсам Бронштейна. Про бизнес даже не подумалось ребятам, хотя это разумеется очевидное следствие — просто так чтоли крупные ТНК сделали «бесплатные*» сервисы авторизации.
Конечно. Что хорошо, комментарии станут попроще, без интересной пены, когда интернет по паспорту )))
Постепенно по шагам решаются вопросы. Так что всё будет. |
|
Наблюдения за опытом использования. По текущией длине параграфа — её смело можно сократить в два раза. Сейчас слишком длинные параграфы. Недостающую информацию можно брать со страницы контекста. По датам — в поиске отсутствует удобный механизм обработки дат. Если задать поиском «22 августа», то в любом режиме будет слишком много результатов. Но если попытаться уточнить результаты дополнительным словом в запросе, например «Япония», тогда нельзя будет выбрать режим «по соответствию фразе», поскольку поиск будет проводиться по фразе «22 августа Япония», что не является тем запросом, который вы ищете (с) — дата должна быть «склеена» по логике поиска точного соответствия фразе, а дополнительное слово должно искаться по логике «найти в результатах поиска по дате». |
Это мы можем сделать, у нас уже для этого реализован метод. Мне в начале, когда запустили, параграфы казались гигантскими, я ещё об этом писал, что надо привыкнуть, сейчас привык уже. Теперь некоторые параграфы в поиске коб, которые без сносок, кажутся маленькими… Но думаю да, можно сократить. Метод есть.
По датам, понятно, надо подумать, закинул в голову, так то эту логику надо еще реализовать т.к. этого в коробке мантикоры нет. Хотя может быть и есть, надо посмотреть в sql клиенте, с ним можно делать более сложные запросы, это по аналогии как я выкладывал сервис поиска похожих текстов tf/idf , там запросы в бд производятся через синтаксис sql и похоже можно делать разные сложные вещи). В общем буду думать, как это можно реализовать. |
Да, очень похоже на сложные запросы определённой формы. Пусть варится вопрос, это пока просто наблюдение получилось, несколько раз столкнулся и сформировался фактор среды. |
|
А есть ли в мантикоре метод, который показывает статистику по всем размеченным словам в базе? |
|
Не слишком удобный размер шрифта в нижней строке окна выбора короткой ссылки:
Может уменьшим его на пару пунктов? |
Я не припомню такого метода, не встречал в документации. Надо описать, что мы хотим видеть и придумать алгоритм, который даст такую статистику. Нам нужен метод, чтобы получить список токенов по всем документам? Странно, что такого метода нет, надо будет посмотреть на форуме, возможно там задавали подобный вопрос. Есть методы чтобы получать доп. информацию в конкретном запросе (show meta) есть статус индекса и другие статусы (agent, node, threads), но там нет подробной информации по словам. Например, статус индекса дает такое: Но тут только кол-в документов и байтов, и статистика запросов. upd: |
Надо обратить внимание на эти ссылки: https://manual.manticoresearch.com/References#Indextool Предполагаю где-то там скрывается нужный нам метод |
В самом предельном смысле хотелось бы получить полную карту слов или их токенизаций — разных слов не будет так уж много, должно быть меньше миллиона, скорее всего в районе 250 тысяч. Карта отображается в виде графа, связи между словами имеют вес, соответствующий связям двух слов во всём корпусе текста, и тд. В общем, это стандартное представление, но думаю нам оно будет очень полезно. Разумеется, если его можно реализовать какими-то доступными средствами, пока не будем упираться рогами в изобретение метода с нуля, просто подумать, держать в голове. Основное предназначение карты, скорее относится к новой библиотеке К150 (или к ещё большему её старшему брату «вообще всех книг на русском» около миллиона изданий включая художку) — побитие в ней книг на темы абсолютно умозрительное и не соответствует реальному положению дел. В основном потому, что любое побитие множества на подмножества с помощью фиктивных оценок это изначально глупая задача. Мы решаем вопрос — как побить литературу на подмножества, в которых было бы эффективно проводить поиск, например при поиске физического явления не получать эзотерическую практику или экономический отчёт. Это задача не высокой срочности, но важность её достаточно высока, поэтому пусть в голове полежит, пишу на будущее.
Наверное нам нужно смотреть на воображаемый граф и думать над: Что-то в таком духе. Я думаю что это стандартная технически задача в целом, но не думаю что её реализация есть в мантикоре из коробки, но тут я знаю меньше и потому вопрос. |
|
Что ещё касается всех библиотек, появилось мнение в результате тестирования. Нужно пересмотреть отдачу контекста по формуле 3+p+3 в сторону 1+p+Х, поскольку практически никогда два избыточных параграфа в начале контекста не требовались. Чаще всего суть вопроса понятна прямо из оригинального параграфа, иногда из идущего перед ним, но параграфы выше лишь занимают место. В целом представляется, что для контекста достаточно формулы 1+p+3, то есть всего пять параграфов на странице. |
Да, согласен. Замечал такое, обычно проматывал до середины текста в поисках исходного параграфа и потом начинал движение по тексту, текст выше просматривал, но почти никогда не читал все 7 параграфов. Это по моим наблюдениям, восстановленным из памяти, после вашего сообщения. |
Возможно и предыдущий параграф можно попробовать не показывать, но может быть показывать всё как сейчас, однако перематывать страницу сразу к id целевого параграфа? |
Перематывать к целевому (исходному) параграфу, с которого нажали контекст, кажется логичным. |
Здесь собираем обратную связь и собственные наблюдения о процессе тестирования поиска по военно-исторической библиотеке. Из собранных здесь наблюдений, замечаний и предложений можно формировать отдельные issue.
Данный комментарий можно использовать для сбора задач, например:
Отключить сервис коротких ссылок на период тестирования;И так далее. Если предложение проходит проверку обсуждением, добавляем его в этот список и/или открываем issue.
The text was updated successfully, but these errors were encountered: