Data engineering
Полнотекстовый поиск: тест на свободное припоминание
Припоминание бьёт перечитывание. На каждый промпт скажи или запиши полный ответ по памяти до того, как откроешь модельный — именно усилие припоминания превращает идеи юнита в то, что можно применить под давлением.
Реконструируй ключевые механизмы юнита — inverted index, конвейер анализа и его правило паритета, BM25 и его ручки, выбор Postgres-vs-движок и операционные ловушки — не подглядывая в урок.
- 01Почему LIKE '%term%' никогда не может быть поиском и какие две разные проблемы full-text search решает вместо него?
- 02Опиши inverted index и что делает запрос быстрым на нём независимо от размера корпуса.
- 03Что делает анализатор и почему один и тот же анализатор должен работать при индексировании и при запросе?
- 04Объясни, почему поиск перешёл от TF-IDF к BM25 и что управляют ручки k1 и b.
- 05Когда Postgres tsvector/GIN — правильный выбор по умолчанию, что толкает к выделенному движку и как выбрать GIN vs GiST внутри Postgres?
- 06Что значит 'near-real-time' для выделенного движка и почему надо проектировать за read-алиасом с первого дня?
Если ты смог реконструировать каждый ответ по памяти, ты держишь стержень юнита: LIKE проваливается и в поиске, и в ранжировании, inverted index делает поиск dictionary lookup, конвейер анализа решает, что такое терм, и его правило паритета не подлежит обсуждению, BM25 насыщает term frequency и нормализует длину, чтобы всплывали полезные документы, Postgres GIN — правильный выбор по умолчанию, пока facets/fuzziness/масштаб не толкнут к выделенному движку, а near-real-time refresh плюс reindex из-за неизменяемых токенов — это причина строить за read-алиасом с самого начала.