Este documento describe los conceptos centrales de la búsqueda de texto completo (full-text search). Explica cómo los motores de búsqueda analizan documentos para crear índices invertidos, procesan consultas para realizar búsquedas y calculan la relevancia de los resultados. También cubre características como snippets, "Did you mean" y facetado que mejoran la experiencia del usuario.

1. Motores de búsqueda
Recuperando información
Ignacio Perez - Ingeniero en IndexTank
ignacio@indextank.com - @nachopg
http://blog.indextank.com

2. Full-Text Search
Introducción
Dentro de la disciplina de recuperación de la información (IR), full-text
search es una de las tareas más aplicadas en lo que es desarrollo web.
Con el crecimiento de las capacidades técnicas, encontrar información no
estructurada dentro de un corpus de datos extenso se ha convertido en
una necesidad para un número cada vez mayor de actores.
Los motores de búsqueda textual ya no son sólo un requisito de los
buscadores web. Las nuevas tendencias en internet implican contenido
generado a muy alta velocidad (muchas veces por los mismos usuarios)
dentro de una misma aplicación: YouTube, Twitter, Facebook, Wordpress,
Digg.

3. Full-Text Search
Conceptos centrales de la
búsqueda full-text

4. Full-Text Search
Full-text Search
• Caso de uso que satisface
o Encontrar documentos textuales a partir de un una consulta de
texto libre.
o Es decir, entender cuáles de los elementos de un corpus está
buscando un usuario a partir de una expresión.
o Es decir, responder una pregunta en lenguaje natural a partir de un
corpus de documentos de texto.

5. Full-Text Search
Full-text Search
• Esto implica varios problemas:
o ¿Cómo busco en un corpus muy grande de documentos?
o ¿Cómo interpreto lo que quiere el usuario?
o ¿Cuál es el criterio para decidir que un documento es adecuado?
o ¿Cuál es el criterio para decidir entre dos documentos adecuados?

6. Full-Text Search
Buscar en un corpus
Primer approach:
Regular expression (automáta finito sin pila) aplicado a todo el
corpus (GREP).
Problema de performance:
O(n) donde n es el tamaño del corpus

7. Full-Text Search
Buscar en un corpus - Índice
• Muchas veces hablamos de 'índice' cuando tenemos una
estructura que nos permite hacer un lookup en O(log(n)) en lugar
de O(n)
• Índices de DB: Indexar uno o más campos, en un determinado
orden. Facilitar tareas de ordenamiento o búsqueda.
• Full-text index
o ¿Por qué es full text?
o Va de subelementos (términos) a documentos

8. Full-Text Search
Índice invertido
• Índice de un libro: nos lleva de un identificador (título) a su
contenido.
• Índices numéricos que identifican elementos (a[1], a[2]).
• La inversión, del “índice invertido” responde a que se va del
contenido al identificador y ya no al revés.

9. Full-Text Search
Índice invertido
• 1: “Todas las hojas son del viento”
• 2: “Ya que él las mueve hasta en la muerte”
• 3: “Todas las hojas son del viento”
• 4: “Menos la luz del sol”
Aquí el índice (identificador) va del número de verso al contenido del verso.

10. Full-Text Search
Índice invertido
• “Del”: 1,3
• “él”: 2
• “Hasta”: 2
• “Hojas”: 1, 3
• “La”: 2, 4
• “Las”: 1, 2, 3
• “Luz”: 4
El índice invertido nos permite ir de una palabra a los versos en que aparece.

11. Full-Text Search
Índice invertido
• Los términos estarán ordenados (naturalmente por orden
lexicográfico).
• Estructura de almace que permita realizar búsqueda binaria con
bajo costo.
• Array:
o Insertar nuevos elementos (tarea poco frecuente), costo mayor.
o Acceder elementos (tarea muy frecuente), costo menor.
o Lookup en O(log(n))

12. Full-Text Search
Document Analyzer
Pero nuestro input son documentos de texto. Son textos libres no
estructurados que debemos procesar para construir el índice.
• ¿Cómo se subdivide un texto para construir un índice invertido?
• La definición de una noción como “palabra” es problemática
incluso en el ámbito de las ciencias del lenguaje.
• Se suelen utilizar criterios gráficos.
• Definiciones accesorias como “lema” o “lexema”
●
No todos los tipos de documentos van a ser sólo un texto. Se los
puede subdividir en campos.

13. Full-Text Search
Document Analyzer
Concepto de término (token)
• Unidad “mínima” en la que se descomponen los documentos
textuales.
• Implica definir un criterio
• Problemas:
o “aren't”, “you'll”, “l'enfant”
o “N.L.P.”
o Compounds del alemán
 Soluciones costosas con diccionario

14. Full-Text Search
Document Tokenizer
• Distintas operaciones durante la tokenización:
o Normalización:
 Homogeneizar diferencias no significativas:
 “a” “á”, “æ” “ae”, “A” “a”
o Stemming
 Remover terminaciones flexivas:
 “casas” “casa”, “encuentran” “encuentr”
(Implementación libre de sintaxis de stemming Snowball:
http://snowball.tartarus.org/)
o Stopwords
 Remover términos muy comunes no significativos. Palabras
funcionales (artículos, preposiciones)

15. Full-Text Search
Consulta (Query)
●
El texto de la query no es simplemente texto libre, va a
implicar una sintaxis a partir de la cual es entendida por el
motor de búsqueda.
●
Sintaxis laxa, pero poderosa a la vez.
●
Semánticamente supone un matcheo binario, e impacta en la
relevancia de los documentos (elegir entre
documentos matcheados)

16. Full-Text Search
Query Parser / Analyzer
El texto de la query funciona distinto al del documento.
• AND, OR, phrase query
• Agrupaciones
• Operador caret
●
El query parser descompone la sintaxis de la query.
●
Los términos son trabajados por el tokenizer.
Operaciones de tokenización que pueden ser exclusivas del query parser: aplicación de
sinónimos

17. Full-Text Search
Query Parser / Analyzer
Ejemplo de query para nuestro índice:
(Del AND "las hojas") OR mue*
Qué resultados matchean y por qué:
• 1: “Todas las hojas son del viento”
• 2: “Ya que él las mueve hasta en la muerte”
• 3: “Todas las hojas son del viento”
¿Cómo funciona la búsqueda por prefijo (el término "mue*")? ¿Y los operadores?
¿Cómo funciona la búsqueda por frase (porción entre comillas) con nuestro índice?

18. Full-Text Search
Query Parser / Analyzer
●
El Query Parser analiza el texto de la consulta a partir de los operadores (AND,
OR, NOT, paréntesis.
●
Operadores booleanos comunes. Afectan matcheo binario.
●
El Query Parser También interpreta el término con asterisco ("mue*"). Búsqueda
por prefijo.
●
Ejemplo: "bus*"
•
"burlon": ...
•
"bus": ...
•
"busca": ...
•
"buscar": ...
•
"busqueda": ...
•
"buzo": ...

19. Full-Text Search
Índice invertido - Posiciones
• “Del”: 1(5),3(5)
• “él”: 2(2)
• “Hasta”: 2(3)
• “Hojas”: 1(3), 3(3)
• “La”: 2(2), 4(6)
• “Las”: 1(2), 2(3), 3(2)
• “Luz”: 4(3)
Al agregar las posiciones de los términos, se puede realizar búsqueda por frase y
usar el operador AROUND.

20. Full-Text Search
Query
●
Hasta este punto, elementos de la query que determinan el matcheo
binarioqué elementos del corpus matchean y cuáles no.
●
Un documento cumple o no con una condición textual. Tiene o no los
términos que el usuario está buscando.
●
Parte importante pero insuficiente en un corpus extenso.
●
La query debe implicar criterios para decidir entre todos los
documentos matcheados.

21. Full-Text Search
Query
●
Criterio para ordenar: relevancia de un documento respecto de una query.
●
Calculo de relevancia difiere entre casos de uso. A partir de muchos
elementos.
El cálculo de la relevancia debe llevarse a cabo para cada elemento matcheado del corpus,
independientemente de cuestiones de paginado.

22. Full-Text Search
Relevancia Textual
Criterio de relevancia más vinculado con el mismo texto de la query.
Determinar cuánto “responde” un documento al texto de la query.
Proceso similar al del matcheo binario:
– Determinar relevancia de cada término, componer relevancia de la query.
Relevancia de cada término: TF-IDF (term frequency – inverse document frequency)
Composición de la query: Criterios a partir de los operadores booleanos y el
calificador caret (“^”).

23. Full-Text Search
Relevancia Textual
TF-IDF: término más relevante para un documento cuanto más aparezca en ese
documento (frecuencia en el documento) y menos en el corpus (frecuencia
inversa de documento).
Calificador caret: boostea alguna o algunas de las expresiones.
Esto es muy útil para ciertas búsquedas muy comunes:
si estoy buscando a una persona es mucho más relevante el match en el campo nombre
que en el campo descripción

24. Full-Text Search
Relevancia por variables
La relevancia también puede estar dada por características absolutas de los
documentos o relativas a la query.
●
Variables propias de un documento
●
Fecha del documento
●
Cantidad de vistas
●
Número de votos
●
Clickthrough
●
Variables relativas a la query
●
Geolocación: pueden ser más importantes aquellos documentos geográficamente más
cercanos al usuario.
●
Grafo social (problema técnico)
●
Carecterísticas del usuario (edad, búsquedas anteriores)

25. Full-Text Search
Features que mejoran la
experiencia del usuario

26. Full-Text Search
Snippets
• Impacto en la UX
o Permiten al usuario entender la relación entre su query y los
resultados.
o Permiten al usuario elegir el resultado con más criterio.
• Dificultades técnicas
o Best window
o Highlighting de términos

27. Full-Text Search
Did You Mean
●
Errores de tipeo no dan resultados. El usuario no se entera.
●
Sugerirle al usuario queries alternativas (como el “Did you mean” de
Google) a partir del índice.
●
Encontrar en el índice términos “parecidos” al buscado, pero con mejores
resultados.
●
Distintos criterios para decidir cuándo y qué sugerencia mostrar.
Buscar elementos “parecidos” en el índice:
●
Utilizar distancia de edición (en general, Levenshtein)
●
Recorrer elementos del índice en forma eficiente (trie tree)
(Posible solución entendiendo ambas cuestiones como autómatas finitos)

28. Full-Text Search
Faceting
Muchas veces, el corpus está estructurado en categorías y subcategorías.
Los resultados de la búsqueda pueden estructurarse entonces en facets.
El usuario acota su consulta a partir de categorías.

Precio

De 0 a 100 (13)

De 101 a 500 (45)

De 501 a 5000 (15)

Tamaño

Chico (20)

Mediano (35)

Grande (18)

29. Full-Text Search
Faceting
Muchas veces, el corpus está estructurado en categorías y subcategorías.
Los resultados de la búsqueda pueden estructurarse entonces en facets.
El usuario acota su consulta a partir de categorías.

Precio

Precio

De 0 a 100 (13)

De 0 a 100 (0)

De 101 a 500 (45)

De 101 a 500 (45)

De 501 a 5000 (15)

De 501 a 5000 (0)

Tamaño

Tamaño

Chico (20)

Chico (16)

Mediano (35)

Mediano (18)

Grande (18)

Grande (11)

30. Full-Text Search
Instant Search
Se puede mejorar la experiencia del usuario dándole resultados a
medida que escribe.
• A la Google
o Las queries de otros usuarios van a servir de referencia.
• A la Facebook
o Se busca directamente sobre el contenido textual índice. Prefix search.

31. Full-Text Search
Requerimientos no funcionales
El tiempo de respuesta de una query es fundamental. La
experiencia del usuario se degrada fuertemente a los pocos
milisegundos.
• Estudios hechos en Google mostraron que unos pocos milisegundos tienen
muy alto impacto en la experiencia del usuario:
o 200ms de delay implicaron 0.29% de reducción de tráfico.
o 400ms de delay implicaron 0.59% de reducción de tráfico.
• Al tiempo que consume el motor de búsqueda, hay que sumarle los tiempos
de renderización de resultados.

32. Full-Text Search
Tarea accesoria

33. Full-Text Search
Crawling de documentos
Fuera del motor de búsqueda en sí. Tareas común a muchos buscadores.
Crawler: ingenio que a partir de una serie de criterios, recorre la web
periódicamente, fetchea páginas y las deja listas para ser indexadas.
●
Se recorren las páginas a través de los links que contienen.
●
Politeness: para evitar que la IP del crawler sea bloqueada por los distintos
sitios, hay que respetar ciertas políticas.
●
Profundidad: para realizar buscadores verticales se suele partir de ciertas
páginas y se recorre hasta cierta profundidad respecto de ellas.
●
Frecuencia: revisar más frecuentemente aquellas páginas que cambian
más frecuentemente.

34. Full-Text Search
Nuestra implementación
IndexTank

35. Full-Text Search
Objetivos buscados
• RealTime: un documento es buscable desde el mismo instante
en que es indexado.
• Ease of use: encender, configurar e integrar un índice con una
aplicación sin esfuerzo.
• Flexibilidad en el manejo de la relevancia: variables por
documento actualizadas frecuentemente; funciones de
relevancia configurables que se pueden probar inmediatamente
sin reindexar.
• Escalabilidad (para el usuario y para el servicio): correr en la
nube (AWS) con un paradigma de self-service.
• Muchas de las features vistas: snippets, faceting, geolocation,
instant search, did you mean, prefix search, stemming

36. Full-Text Search
Índice RealTime
Índices en memoria con una solución híbrida:
●
Un índice muy performante en cuanto a utilización de espacio para el largo
plazo.
●
Un índice realtime con todos los documentos que todavía no llegaron al
índice de largo plazo.
●
Una estructura realtime para el manejo de eliminaciones y modificaciones

37. Full-Text Search
Flexibilidad de relevancia
●
Variables adosadas a los documentos en estructuras que pueden
ser modificadas muy frecuentemente (votos, visitas).
●
Posibilidad de pasar variables junto con la query que pueden ser
consideradas en las funciones de relevancia.
●
Relevancia de los documentos calculada en el momento de
matchear.

38. Full-Text Search
Escalabilidad
Trabajamos sobre la plataforma de AWS, con una arquitectura que permite crecer
en el número de índices elásticamente.
●
Una capa de API que maneja los requests de los usuarios.
●
Un grupo elástico de máquinas (workers) que contienen los índices.
●
Un componente de manejo de workers que crea, distribuye y mueve los
índices (en forma transparente), crea nuevos workers y alerta sobre
distintos problemas que pudiera surgir en la infraestructura.