Autores: Jorge Serrano Cobos y Ana Quintero Orta (Universidad de Granada)
Citación recomendada: Jorge Serrano Cobos; Ana Quintero Orta. Elección de un motor de búsqueda: pasos a seguir [en linea]. "Hipertext.net", núm. 1, 2003. <http://www.hipertext.net>
1. Introducción
2. Estudio del servicio /auditoria de informacion
3. Estudio cuantitativo de la información y los usuarios
4. Diseño del servicio
5. Benchmarking
6. Valoración del modelo de recuperación a usar
7. Valoración del software / hardware a usar
8. Investigación de empresas desarrolladoras
9. Decisión final
10. Bibliografía
Cuando creamos un servicio de información (léase biblioteca, centro de documentación, departamento de business intelligence....) el primer paso es ver cómo vamos a organizar la información, y después nos fijaremos en cómo vamos a recuperarla.
El profesional de la información normalmente diseña el sistema previendo cómo él mismo va a poder recuperar lo anteriormente organizado, y qué lenguaje de interrogación va a utilizar. Necesita una serie de recursos y herramientas muy potentes, que no conocerán sus usuarios o clientes, y que no tienen por qué conocer. El proceso completo será en general transparente para el usuario. Pedirá una información y la obtendrá de nuestras manos.
El problema surge cuando en el proceso de obtención de una información no aparece la figura del intermediario sino que se da a través de medios que posibilitan que sean los usuarios los que consulten directamente al sistema de recuperación de información. Entonces, entender al usuario se convierte en un paso obligado y prioritario. Por eso, antes de pensar en que necesitamos un motor de búsqueda y un hardware que solventen ese servicio, debemos determinar toda una serie de factores.
Todo servicio de información que traslade su actividad al ámbito de internet debe tener claras algunas premisas básicas de arquitectura de información y usabilidad. Al ofrecer información a través de la web, abrimos el interface a cualquier tipo de usuario, en general al no entendido. Ello implica conocer a nuestro usuario potencial, y por tanto, adaptar las posibilidades de recuperación de información a sus capacidades y su forma de buscar.
El usuario de internet encuentra lo que busca de dos formas: siguiendo la estructura jerárquica de un sitio web o directamente, por palabra clave, mediante un motor de búsqueda interno. Al diseñar un proyecto de recuperación de información basado en el web, deberemos contemplar ambas estrategias básicas de búsqueda, de forma que los resultados que se obtengan de un modo u otro sean compatibles.
Al delimitar qué motor de búsqueda o software de recuperación de información vamos a usar, nos plantearemos al menos los siguientes pasos:
Estudio del Servicio
Estudio cuantitativo de la información y los usuarios
Diseño del servicio.
Benchmarking.
Valoración del modelo de recuperación a usar.
Valoración del software / hardware a usar.
Investigación de empresas desarrolladoras.
Decisión final.
El Primer paso es conocer nuestra institución, su información y sus usuarios. Para ello necesitaremos conocer ciertos elementos previos sobre las características de la organización enfocados a las necesidades del servicio de información Algunos de estos elementos se traducirán en una serie de indicadores cualitativos:
Tipo de público / usuario / cliente potencial a quien está dedicado el servicio.
Tipo de información (estructurada, no estructurada, dinámica tipo noticias, estática tipo artículos...)
Tipo de amplitud temática (muy especializado y vertical, muy horizontal, con gran variedad temática)
Utilidad intrínseca del buscador (dar información, fomentar la compra de productos, conectar personas...)
Valoración de la importancia y prioridad del servicio dentro de toda la organización.
A partir de ellos podemos deducir lo siguiente:
Tipo de público / usuario / cliente potencial a quien está dedicado el servicio.
Afecta principalmente al diseño del interfaz, este puede ser de un manejo muy sencillo y lleno de colores atrayentes si está dedicado a niños pequeños, o puede ser todo lo complejo que se necesite, permitiendo toda clase de juego con la búsqueda avanzada si el usuario es un buscador experimentado, y entre un extremo y otro, una amplia gama de posibilidades.
Si pensamos en el gran público, lo cierto es que las estadísticas nos dicen que el usuario medio usa poco la búsqueda avanzada, despreocupándose de reformular su cadena de búsqueda o de acotar mejor sus necesidades. Sin embargo, frente a estos datos, constatamos una tendencia creciente de los grandes buscadores tipo google, alltheweb, altavista, a aumentar y mejorar las opciones avanzadas. Por todo ello lo mejor será, en la medida de lo posible, obtener información estadística del log del buscador o de un prototipo para conocer cómo buscan nuestros usuarios, y no otros, pues son ellos hacia quienes enfocamos el servicio. Atendiendo a sus necesidades, conformaremos el sistema.
Tipo de información (estructurada, no estructurada, dinámica tipo noticias, estática tipo artículos...)
El servicio dependerá en gran medida de la estructura de nuestra base de datos, de nuestro modelo de datos, y de la cualidad de información que deseemos ofrecer al usuario; podemos dejar al usuario que busque sólo una parte de nuestros contenidos (libros, discos, artículos) o mostrar de un vistazo todos los posibles contenidos del sistema, de forma que elijan cuál es de todas la información que le interesa. Podemos incluso tener distintos buscadores especializados y no uno sólo que integre todas las fuentes documentales, todo esto dependerá del servicio que queramos dar.
Tipo de amplitud temática (muy especializado y vertical, muy horizontal, con gran variedad temática)
Este indicardor nos será muy útil para definir el algoritmo a implementar en el buscador, bien sea del tipo estadístico, o lingüístico.
Si la temática es muy abierta, muy heterogénea, y el número de documentos muy amplio, la heterogeneidad semántica se multiplicará, por lo que un sistema de tipo estadístico nos dará una calidad media adecuada y una alta rapidez de respuesta. Si la temática es muy concreta y la dispersión de significados acotada, podemos optar por un algoritmo que emplee lingüística computacional, que juegue con tesauros, glosarios e incluso le matice y en general..., nos permita controlar el lenguaje.
Utilidad intrínseca del buscador (dar información, fomentar la compra de productos, conectar personas...)
De nuevo este criterio nos permitirá diseñar la usabilidad del servicio, la apariencia no sólo de la ubicación del buscador en pantalla, sino de la presentación de los resultados. Este aspecto es clave para dar al usuario lo que necesita lo antes posible y de la forma más clara.
Valoración de la importancia y prioridad del servicio dentro de toda la organización. Si el servicio no necesita de una exquisitez extrema en el control del vocabulario, por mucho que para el documentalista esa característica sea clave, y lo sea el precio, por ejemplo, habrá que rendirse a la evidencia, y optaremos por un buscador que permita un rendimiento de calidad aceptable al mínimo costo. En cualquier caso, hay opciones gratuitas que permiten el desarrollo de tesauros como herramienta acompañante del buscador, como por ejemplo el motor de búsqueda PLS (www.pls.com)
Estos indicadores relativos al sistema, a la información y a los usuarios a los que daremos servicio, nos permitirán hacernos una idea de las necesidades técnicas de volumen y rendimiento.
Indicadores cuantitativos:
Volumen medio de páginas o documentos.
Tasa de crecimiento del número de páginas.
Volumen medio de visitas.
Tasa de crecimiento de visitas.
Tendencia futura prevista en el volumen de búsquedas
Presupuesto inicial.
A partir de ellos podemos deducir lo siguiente:
Volumen medio de páginas o documentos:
La cantidad de documentos influye en el tiempo de respuesta (eficacia) y si utilizamos un buscador que use un algoritmo estadístico para obtener una clasificación automática mediante "clustering", nos dará una idea de la heterogeneidad semántica que puede producir. Como regla general recordar que obviamente, a mayor cantidad de documentos, mayor heterogeneidad.
Tasa de crecimiento del número de páginas:
Si el número de páginas es pequeño y manejable, los requerimientos de hardware (potencia de cálculo) no necesitan ser muy altos. Pero aun así, si sabemos a ciencia cierta que van a aumentar rápidamente, será mejor pensar a medio y largo plazo, antes que necesitar cambios de hardware y software cada cierto tiempo.
Volumen medio de visitas, tasa de crecimiento de visitas, tendencia futura prevista en el volumen de búsquedas:
La conjunción de los tres indicadores nos dará idea de la cantidad de búsquedas diarias y aún más importante, simultáneas, que concurrirán en el servicio. Muchas visitas / búsquedas (aunque no tienen por qué ser directamente proporcionales) suponen una carga enorme para el servidor, lo que influye en la eficiencia del sistema.
Presupuesto inicial:
Dato obvio que nos permitirá determinar nuestros límites iniciales. Ello no implica que el servicio tenga qué ser de baja calidad si el presupuesto inicial es bajo. La imaginación es una buena aliada en estos casos, y dependiendo de los recursos humanos, existe software gratuito o de licencia gratuita perfectamente adaptable a diversas situaciones, incluso en entornos de grandes cantidades de información.
Como vemos, en general, estos indicadores nos permiten conocer a priori la potencia que necesitaremos del sistema en términos de rendimiento eficiencia / precio. Los factores claves a considerar serán la capacidad de soportar múltiples búsquedas sin que peligre la estabilidad del sistema (que no se "caiga" el servidor) y su rapidez de respuesta.
Una vez conocidos estos datos estamos en condiciones de caracterizar las necesidades de información de nuestros usuarios, potenciales o reales, la variedad informativa de que dispondremos y su modelo de datos, estructuración, catalogación, aplicación de metadatos e incluso disposición física.
A partir de ahí diseñaremos el tipo de búsqueda y la presentación de resultados que queremos dar a los usuarios. El proyecto se definirá siguiendo modelos de arquitectura de información y usabilidad ya establecidos, de forma que sean lo más sencillos de usar. Generaremos una lista de requerimientos, desde las necesidades más acuciantes a las ideales, y en ese orden de prioridades.
Consultaremos otros servicios que puedan resultar similares al nuestro, observaremos sus virtudes y carencias, y averiguaremos qué herramientas utilizan para dar el servicio.
Es muy importante determinar el modelo a seguir, antes de decidir el producto comercial (o gratuito) que se va a utilizar. El modelo recuperará de una forma u otra dependiendo de nuestras necesidades, es importante tener claro qué queremos hacer que sea fundamental. Normalmente muchos productos hoy día contienen en sus algoritmos de funcionamiento varios de los modelos clásicos, combinando sus características para obtener los mejores resultados dependiendo de las necesidades de cada usuario. Ello conlleva productos más abiertos, personalizables, con APIs que permiten programar funciones específicas, pero también más caros.
Como vemos, los aspectos cualitativos antes destacados son los más difíciles de determinar, porque en ellos ninguno de los indicadores es determinante, al menos de forma absoluta. En cada caso el profesional debe decidir si, dentro de un proyecto específico, será más útil una herramienta que siga el modelo de la lingüística computacional, o o el estadístico; incluso podemos pensar en programas que empleen técnicas de ingeniería artificial, lógica fuzzy o algoritmos genéticos que se adapten a las cambiantes necesidades de un usuario a lo largo del tiempo.
Las posibilidades son tan variadas como el tipo de organización en el que se desarrolle el proyecto: si trabajamos en una institución con temática muy concreta, es factible pensar en modelar muy bien las relaciones semánticas, la matización, etc., puedo dedicar tiempo y recursos a generar diccionarios de sinónimos y relaciones mediante tesauros especializados, etc., de forma que la relevancia aumente.
Lo contrario ocurrirá en organizaciones con una variedad temática enorme, sin personal especializado para administrar el buscador o herramientas de apoyo al mismo, y con un volumen enorme. Tenderemos a sistemas que se rijan más por una búsqueda estadística simple, que no controle el lenguaje pero que recupere sobre la base de los textos de la base de datos.
Dependiendo del presupuesto y dedicación, incluso se puede seguir el modelo cognitivo, superando los anteriores (aunque tomándolos como base) realizando estudios de experiencia de usuario, cruzando expresiones en lenguaje natural con las expresiones usadas por los autores, tesauros basados en el sentido común de las personas cruzados con un tesauro formal, adaptando la jerga particular a modelos establecidos. Como decimos, las posibilidades son múltiples.
Es ahora donde podemos empezar a pensar en qué software de búsqueda y sobre qué hardware funcionará. Ahora que tenemos claro lo que queremos hacer y en qué parámetros nos movemos. Hay que recordar que, dependiendo del software, necesitaremos asimismo un hardware adecuado.
Los requerimientos de cálculo que se le exigirán a los servidores serán más altos cuanto más complejas sean las búsquedas a realizar, mayor sea el volumen de información a tratar, y mayor sea el número de usuarios que buscan simultáneamente, lo que puede encarecer sobremanera lo que a priori ya es bastante caro.
Crearemos una tabla comparativa con los diversos productos que encontremos en el mercado. Estos son algunos criterios prácticos de comparación de software de recuperación de información:
Características por defecto
Formularios de búsqueda (sólo simple o también avanzada)
Capacidad de búsqueda booleana
Operadores de proximidad
Truncamiento y Stemming
Términos compuestos (utilizando comillas o buscando frases)
Diferenciación entre mayúsculas y minúsculas
Búsquedas por campos
Límites a las búsquedas y capacidad de personalización
Palabras vacías
Métodos de ordenación de los resultados (por relevancia, por fecha...)
Filtros (por ejemplo al sexo)
Tiempo de respuesta (eficacia)
Eficiencia del almacenamiento de información de cada web, medida por el número de bytes que se precisan para almacenar los datos
Clasificación temática asociada y/o asociable (clustering automático / basado en criterios manuales)
Control del vocabulario (eliminación de sinonimias y polisemias)
Ayudas a la búsqueda e información sobre características (manual de uso)
Formato de información añadida / configurable a cada respuesta
Conceptos relacionados (por clustering, clustering difuso, query by example)
Exhaustividad: ratio de documentos relevantes recuperados en una búsqueda dada, sobre el número de documentos relevantes para esa búsqueda
Precisión: ratio del número de documentos relevantes recuperados, sobre el número total de documentos recuperados.
Precio
Tiempo y complejidad de instalación-configuración en el website.
Periodicidad de indexación.
Un factor muy importante que raramente se tiene en cuenta es la empresa que puede desarrollar el proyecto. Nunca hemos de pensar que comprando un software hemos terminado el proyecto. Un proyecto sigue muchas más etapas de las que huelga hablar ahora, pero competen a él toda la instalación, programación ad hoc, diseño y presentación del interfaz de búsqueda y respuestas bajo requerimientos específicos, , tests de usuarios para comprobar el grado de satisfacción, y mantenimiento técnico.
Recordemos que el proyecto debe ser un proceso iterativo, desarrollado mediante ensayo-error. La tendencia de las empresas desarrolladoras es trabajar al límite del plazo contratado, de forma que la rigurosidad metodológica se verá mermada en pro del cumplimiento del contrato. La experiencia nos dice que es mejor un proyecto que se toma su tiempo para llegar a la etapa de producción (time to market) que otro que, simplemente, se haga deprisa y corriendo.
Elegir la empresa a quien compremos el software implica conocerla, saber de su experiencia, de la del componente humano encargado de implementar el software, de su conocimiento de la herramienta y de su integración con nuestro sistema, porque normalmente, uno de los mayores problemas en todo tipo de proyectos tecnológicos es la integración de diversas herramientas y plataformas.
Otra cuestión es realizar el proyecto in house por personal interno. Ganaremos en comunicación con los desarrolladores y conocimiento de las otras herramientas del sistema con los que se tiene que integrar el buscador, pero es importante también Valorar las implicaciones en términos de coste de tiempo y recursos humanos, dinero al fin y al cabo.
En definitiva, ¿cuál es el verdadero quid de la cuestión? Paradigmas aparte, en la vida real es más importante el ROI (return on investment o "retorno de la inversión") que el modelo a aplicar. Esto es, si tenemos medios humanos y técnicos y dinero para hacerlo perfecto, perfecto; si no es el caso, y se puedo solventar la recuperación de información de manera satisfactoria aunque no se ajuste a la perfección, optaremos por esto último.
Así pues, podemos concluir que:
Debemos tener claro para qué queremos un buscador, y cuál será su función dentro del servicio de información que demos.
Los factores claves, determinantes, serán finalmente los recursos disponibles y la satisfacción del usuario.
Normalmente, la presentación de los resultados puede resultar más importante que los resultados en sí. Por ejemplo, google no siempre presenta los mejores resultados, pero al ver resaltadas las palabras clave usadas en la cadena de búsqueda, el usuario lo percibe como una respuesta correcta.
No todo son los paradigmas que subyacen bajo los algoritmos, para decidir qué motor de recuperación de información se va a usar. No hay un modelo perfecto, sólo situaciones distintas.
Nuestra labor será discernir cómo obtener la mejor calidad y satisfacción del usuario, mientras rentabilizamos la inversión realizada al mayor plazo de tiempo y posible.
Francisco Javier Martínez. Méndez Introducción a los Sistemas de Recuperación de Información. [en línea] Universidad de urcia.<http://www.um.es/gtiweb/fjmm/sarisite/tema1.html>[Consulta: 02 abril 2003].
Searchenginewatch. [en línea] <http://www.searchenginewatch.com/reports/index.html>[Consulta: 02 abril 2003].
Searchengineshowdown. [en línea] "Features"http://www.searchengineshowdown.com/features/ [Consulta: 02 abril 2003].
Toni Vicens Arasanz Normas básicas de usabilidad para buscadores internos. [en línea] Octubre 2002 <http://www.evolucy.com/esp/columns/20021024_usabilidad_buscadores.html> [Consulta: 02 abril 2003].
