Конвейер обработки текста в Sphinx

[@grossws]

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

Для портера это, видимо, один слог, т. к. дальше резать некуда. Если глянуть его код (канонический вариант на языке snowball), то можно увидеть, что он очень тупой и не имеет понятия о «нормализованной» форме. Он тупо стеммит.

[@grossws]

Судя по статье, пайплайн обработки в Sphinx крайне примитивный в сравнении с тем, что есть в Apache Solr.

[@klirichek]

Он достаточен для работы. И к тому же уже достаточно сложен для филоофии unix-way.
Вот плагины (упомянутые в самом конце) — это фактически еще один большой «дьявол в деталях».

[@grossws]

Он достаточен для работы.

Я где-то утверждал, что его недостаточно для простых задач? Я всего лишь сравнил с серьезной поисковой системой, где:
— цепочки обработки могут настраиваться хоть per-field (строго говоря, per fieldtype, но fieldtype можно использовать и для одного поля),
— цепочки для поиска и индексации могут не совпадать,
— базовых кубиков 3 типа CharFilter, Tokenizer и TokenFilter, цепочка обработки состоит из 0 и более CharFilter, 1 Tokenizer и 0 и более TokenFilter,
— CharFilter'ы работают на уровне символов, могут удалять, добавлять или замещать символы (плюс обязательно пересчитывают смещения, чтобы подсветка работала корректно),
— Tokenizer штука простая — преобразует в токены (с указанием границ токенов),
— TokenFilter'ы удаляют, добавляют и модифицируют токены: удаления стопслов, стеммеры, вставка синонимов, замены слов по словарям, ascii-folding и многое, многое другое (в том числе, самописное).

И к тому же уже достаточно сложен для филоофии unix-way.

При чем здесь unix-way? К чему вы его приплели?

[@klirichek]

«серьёзная посковая система»? Ну-ну.
Мне просто на первый взгляд показалось, что от Вашего комментария веет троллингом. А вот такой формулировкой Вы меня окончательно в этом убедили!

unix-way был упомянут как подход «простых понятных инструментов». В сфинксе ставка на скорость индексации, и потому многие моменты объединились, оптимизировались и снаружи стали менее прозрачными (увы). Но цель, при этом, достигнута: по сравнению с «серьёзной поисковой системой» есть в продакшне как очень большие индексы (~22E9 доков), так и очень загруженные (комфортно обслуживают ~3E8 запросов в сутки).

[@grossws]

Мне просто на первый взгляд показалось, что от Вашего комментария веет троллингом. А вот такой формулировкой Вы меня окончательно в этом убедили!

unix-way был упомянут как подход «простых понятных инструментов». В сфинксе ставка на скорость индексации, и потому многие моменты объединились, оптимизировались и снаружи стали менее прозрачными (увы). Но цель, при этом, достигнута: по сравнению с «серьёзной поисковой системой» есть в продакшне как очень большие индексы (~22E9 доков), так и очень загруженные (комфортно обслуживают ~3E8 запросов в сутки).

Solr более сложный и гибкий, и, логично, более медленный. Ви так говоr'ите, как будто это что-то плохое.

Индексы 10^8-10^10 документов (10^9+, естественно, в шардах, т. к. солр использует int32 для внутренних id, что ограничивает количество документов в одном индексе ~2*10^9; хотя эти шарды могут быть и в одной jvm) вполне нормально живут в солре. По 10^10 обычный поиск занимает 30-100 мс, если вам нужно меньше latency — то может и sphinx поможет. По индексам ~10^8 документов спокойно считается faceted search (например, top N персон, которые встречались в выборке в рамках текущего запроса по полнотексту).

У нас с вами, вероятно, существенно разные требования к поиску. Нам нужна гибкость (в том числе, свой query parser), хорошо регулируемая налету точность-полнота, удобный drill down и т. п.

Из примеров стандартных плагинов солра — WorlDelimiterFilter: по токену с пунктуацией (wi-fi) или изменению кейса (РосГидроМет) выдаст различные варианты токенов (запишет с той же начальной позицией, что и оригинальное слово; сдвинет позиции остальных токенов): «wifi», «wi fi», «Рос Гидро Мет РосГидроМет».

[@klirichek]

Solr более сложный и гибкий, и, логично, более медленный. Ви так говоr'ите, как будто это что-то плохое.

Да не, это вы так говорите, как будто sphinx «примитивный» и «несерьёзный». Я всего лишь пытаюсь «корректно ругаться» в ответ.
Наверное единственное, в чём его можно обвинить — так это в том, что он не на java :).
А в остальном гибкости хватает. Просто новые фичи в основном делаются не just for fun, а когда есть конкретная потребность. Например, упомянутые вами особые моменты токенизации — да, либо плагином, либо ещё каким-то внешним обработчиком. И это исключительно потому, что встраивать их просто никто не просит. А вот та же лемматизация АОТ прямо «искаропки» — пожалуйста. Как раз-таки потому что кому-то стало нужно, и вот, встроили. То же касается либы RLP для более хитрой токенизации CJK.

[@klirichek]

Есть один забавный момент с морфологией.
Если используется лемматизатор (а кроме возможных плагинов из коробки поддерживается АОТ), то у него возможно два варианта работы. Один — упомянут в статье (с суффиксом _all); он добавляет все варианты слова. А вот тот, что без суффикса, не мудрствуя, просто берёт самый короткий из вариантов (конечно, если их несколько). В подавляющем большинстве этот выбор — правильный (ну просто так язык устроен). Но бывают и забавные исключения. Например, «лососёвая путина» преобразуется в «лосось путин».