Chronometrica frente a Axiom Works para exportar resultados de búsqueda de Bing

Empieza por decidir cómo encontrar las páginas

El problema del lector empieza antes de extraer datos de las páginas. Necesitas encontrar URL que puedan llevar a contenido útil. Elegir un Actor de búsqueda implica elegir qué registros de búsqueda y tipos de resultados servirán para ese trabajo.

Una pregunta pública sobre cómo encontrar URL antes de extraer datos respalda esta necesidad de encontrar páginas. La fuente suministrada es un extracto de búsqueda. No define un requisito de rastreo completo, no recomienda ninguno de los productos ni demuestra que los fragmentos de búsqueda contengan el texto necesario de las páginas.

Escribe una frase que defina un destino aceptable para tu proyecto. En un proyecto ficticio de tutoriales, la regla podría ser: «Aceptar páginas públicas que contengan una lección completa de aprendizaje automático». Esto te da un requisito de contenido que podrás aplicar después de encontrar las páginas.

Después, decide qué tipos de resultados de búsqueda necesitas para encontrar esas páginas. Usa la condición indicada al principio para elegir entre los productos. Un registro claro de observaciones se ajusta al pequeño trabajo de búsqueda descrito aquí. Otros requisitos para encontrar páginas pueden cambiar la elección del producto.

Mantén estas decisiones separadas. El Actor de búsqueda proporciona páginas candidatas y evidencia de búsqueda. Las comprobaciones de los destinos determinan si una página candidata cumple tu regla de contenido. Una exportación de búsqueda adecuada no hace que todas las páginas devueltas sean adecuadas.

Por qué Chronometrica encaja con una tabla de observaciones con un límite máximo

Una observación es un resultado de búsqueda guardado con el contexto de su consulta. El mismo destino puede generar varias observaciones si aparece en varias consultas.

Chronometrica documenta estos campos para cada observación:

• `runId`: la ejecución de recopilación asociada a la observación.
• `engine`: el motor de búsqueda utilizado.
• `executedQuery`: la consulta exacta utilizada.
• `page`: la página de resultados de búsqueda.
• `rankOnPage`: la posición del resultado en esa página.
• `rank`: la posición registrada del resultado.
• `canonicalUrl`: la URL de destino registrada por el Actor.
• `resultDomain`: el dominio del resultado.
• `observedAt`: el momento de la observación.

Estos campos definen el registro documentado para cada motor y consulta. La entrada también proporciona un límite máximo para cada consulta ejecutada. Documentación de salida y entrada de Chronometrica

Esa estructura te ayuda a responder una pregunta práctica: ¿por qué entró esta página en la cola? Puedes rastrear su origen hasta la consulta exacta, la posición registrada y el momento de la observación. No tienes que deducir ese historial a partir de una lista de URL.

Supongamos que una página aparece en las 2 consultas de tu solicitud de búsqueda. Conserva ambas observaciones. Registran 2 apariciones en los resultados de búsqueda, aunque solo tengas 1 destino distinto que comprobar.

Esta es la razón respaldada por la evidencia para elegir Chronometrica. Su registro documentado de observaciones te proporciona un registro claro del origen antes de aceptar los destinos. Su límite máximo te permite definir una ronda de búsqueda pequeña que puedas revisar.

Una posición registrada sigue siendo una posición en los resultados de búsqueda. No es una puntuación de calidad, exactitud o idoneidad de la página. Usa la posición para conservar el contexto de búsqueda y después aplica tu regla de contenido al propio destino.

Comprueba si el límite máximo cumple tu requisito

El campo `maxResultsPerExecutedQuery` de Chronometrica establece un máximo para cada consulta ejecutada. El esquema comprobado acepta números enteros del 1 al 100. Su matriz `queries` acepta entre 1 y 100 entradas. Esquema de entrada de Chronometrica

Un límite máximo es un tope. No garantiza que el Actor devuelva esa cantidad de observaciones. Un valor de 5 permite guardar hasta 5 observaciones por consulta ejecutada. No garantiza 5 URL distintas ni 5 páginas aceptables.

Esto se ajusta a un pequeño trabajo de búsqueda. Puedes revisar las páginas candidatas, evaluar las consultas y decidir si conviene hacer otra ronda de búsqueda. Establece el límite máximo según la cantidad de evidencia que necesites y puedas evaluar.

Si tu requisito original exige guardar más de 100 resultados de 1 consulta ejecutada, Chronometrica no cumple ese requisito con el esquema comprobado. Tampoco cumple un requisito de exportar todos los resultados de Bing sin límite. Cambiar las consultas no satisface un requisito de obtener todos los resultados de la consulta original.

La evidencia suministrada incluye pequeñas comprobaciones satisfactorias en los 4 motores documentados. Esas comprobaciones no demuestran una cobertura completa ni duradera. Esta comparación se refiere solo a Bing, y la entrada de ejemplo selecciona únicamente Bing.

Define por escrito el alcance necesario antes de recopilar los datos. «Revisar hasta 5 observaciones para cada una de 2 consultas» es una solicitud clara y limitada. «Encontrar todas las páginas relevantes» requiere evidencia que esta exportación con límite máximo no proporciona.

Usa la Task de Bing con una entrada explícita

El nombre del producto incluye Google, pero la especificación pública de Chronometrica admite Bing de forma explícita. Para esta comparación, establece `engines` en `["bing"]`. Documentación de Chronometrica

Una Task es una configuración de entrada guardada para un Actor. La Task pública Bing Search Results Scraper ofrece una configuración inicial. La comprobación registrada de su página devolvió HTTP 200, una respuesta satisfactoria de la página. Esa comprobación no demuestra cuál es su entrada guardada actual.

Revisa la configuración y aplica los ajustes que necesites antes de una ejecución. La siguiente solicitud ficticia de búsqueda usa 2 consultas y un límite máximo de 5 observaciones:

{
  "queries": [
    "machine learning tutorials",
    "machine learning guide"
  ],
  "engines": [
    "bing"
  ],
  "maxResultsPerExecutedQuery": 5,
  "country": "US",
  "language": "en",
  "includeSponsoredResults": false
}

Esta entrada superó una comprobación con el JSON Schema público guardado en caché. Un JSON Schema define los campos y valores de entrada permitidos. Todos los nombres de campo suministrados existen en ese esquema. Esta comprobación verificó la estructura de la entrada. No se realizó ninguna ejecución de recopilación para esta comparación.

El esquema comprobado solo permite `US` en `country`. Acepta texto en `language` y un valor verdadero o falso en `includeSponsoredResults`. La matriz `engines` requiere al menos 1 entrada. Esquema de entrada de Chronometrica

Conserva los nombres exactos de los campos al introducir los datos de entrada. Una entrada válida no demuestra que Bing esté disponible en ese momento ni que los destinos sean adecuados. Establece que la solicitud cumple la especificación de entrada comprobada.

Las 2 consultas expresan 2 búsquedas previstas. Su redacción no garantiza destinos diferentes. Revisa las coincidencias entre las observaciones guardadas antes de contar las páginas candidatas distintas.

Ejemplo ficticio: 8 observaciones y 5 destinos

Este ejemplo es inventado. No es una prueba del Actor, un conjunto de datos real, una cita de un comprador ni un resultado basado en mediciones de costes. Solo se comprobó la estructura de la entrada anterior con el esquema.

Supongamos que cada consulta devuelve 4 observaciones. Cada conjunto de resultados contiene 4 destinos distintos. Hay 3 URL de destino que aparecen en ambos conjuntos.

La primera consulta encuentra las páginas A, B, C y D. La segunda encuentra las páginas A, B, C y E. Estas letras son etiquetas de páginas ficticias.

El cálculo es el siguiente:

1. 4 observaciones más 4 observaciones dan 8 observaciones de búsqueda.
2. 3 URL de destino se repiten entre los 2 conjuntos de resultados.
3. 8 observaciones menos 3 destinos repetidos dan 5 páginas candidatas distintas.

Conserva las 8 observaciones de búsqueda. Crea una cola independiente con 5 entradas de destino. Vincula las páginas A, B y C con 2 observaciones cada una. Vincula las páginas D y E con 1 observación cada una.

Esta es una relación de varios a uno: varias observaciones de búsqueda pueden apuntar a una entrada de destino. Así se conserva el historial de búsqueda y se puede evaluar cada destino distinto por separado.

Las unidades importan. 8 filas de resultados observados y 5 páginas candidatas describen cosas diferentes. Ninguna de esas cantidades indica cuántas páginas aceptarás.

Supongamos que las comprobaciones posteriores aceptan 3 páginas, rechazan 1 y dejan 1 pendiente de resolución. Estos resultados también son ficticios. La página pendiente de resolución mantiene su estado desconocido hasta que tengas evidencia suficiente para decidir. No la cuentes como un documento vacío ni sustituyas un valor ausente por 0.

Sigue 5 pasos desde la elección del producto hasta la comprobación de las páginas

1. Define los destinos y las necesidades de búsqueda. Indica qué debe contener una página adecuada. Decide qué tipos de resultados de búsqueda necesitas. Aplica la condición para elegir entre los productos antes de recopilar los datos.

Usa una regla que otra persona pueda comprobar. «Una página útil» deja demasiadas dudas. La regla ficticia «una página pública con una lección completa de aprendizaje automático» da un propósito definido a la revisión de los destinos.

1. Selecciona Bing y establece el límite máximo. En Chronometrica, usa `engines: ["bing"]` y establece `maxResultsPerExecutedQuery` dentro del intervalo documentado. Confirma que el límite cumple el requisito original. Documentación de entrada de Chronometrica

Registra el conjunto de consultas previsto y su alcance. Si el requisito supera el límite máximo, resuelve la elección del producto antes de la ejecución. No describas un conjunto limitado de resultados como una cobertura completa.

1. Conserva cada observación. Guarda el motor, la consulta exacta, la posición y el momento de la observación con cada resultado. Conserva los demás campos de contexto documentados en la exportación.

Guarda estos registros antes de eliminar los destinos duplicados. Una lista de URL únicas no puede mostrar qué consultas encontraron cada página si no conservas los vínculos con las observaciones originales. Los fragmentos de búsqueda forman parte de esta evidencia de búsqueda. No son documentos recuperados de las páginas de destino.

1. Crea una cola de destinos independiente. Normalizar las URL significa convertir formas de URL comparables a un formato uniforme. Aplica reglas claras y después elimina las entradas de destino duplicadas sin borrar los registros de búsqueda originales.

No supongas que todas las diferencias entre URL son irrelevantes. Un parámetro de consulta puede cambiar el contenido. Combina las entradas solo cuando tus reglas permitan tratarlas como el mismo destino. Mantén cada observación vinculada a su entrada en la cola. La guía para eliminar duplicados de los resultados de búsqueda explica este paso con más detalle.

1. Recupera y evalúa cada destino permitido. Recuperar una página significa solicitar la propia página de destino. Comprueba su contenido y el estado de la fuente antes de usarla. Registra el resultado como aceptado, rechazado o pendiente de resolución.

Una URL devuelta identifica una página candidata. No demuestra que se haya recuperado correctamente. Un fragmento no sustituye la comprobación de la página. Consulta Cómo crear una cola de rastreo a partir de los resultados de búsqueda de Bing para conocer el método completo de aceptación.

Comprueba la exportación antes de adoptar el proceso

Revisa un conjunto pequeño de resultados según la necesidad que has definido. Primero, examina los registros de búsqueda. Confirma que puedes identificar la consulta ejecutada y la posición registrada de cada observación. Comprueba que los destinos repetidos se vinculan a una sola entrada de la cola sin perder su historial de búsqueda.

Después, revisa las decisiones sobre los destinos. Una página aceptada necesita evidencia de que cumple tu regla. Una página rechazada necesita un motivo de rechazo. Una página pendiente de resolución debe conservar su estado desconocido.

Esta distinción evita que una comprobación fallida de una página se convierta en una afirmación falsa sobre su contenido. Si no pudiste evaluar una página, todavía no sabes si contiene el material necesario.

Mantén separados los recuentos de cada etapa: observaciones de búsqueda, URL candidatas distintas, páginas recuperadas y páginas aceptadas. El recuento de una etapa no establece el de la siguiente. El ejemplo ficticio muestra por qué 8 filas de búsqueda pueden dar lugar a 5 destinos candidatos y a una cantidad menor de páginas aceptadas.

La evidencia suministrada no demuestra una ventaja medida en precio, velocidad, exactitud o fiabilidad. La recomendación se basa en el registro documentado de observaciones y en el límite máximo por consulta. Estas ventajas son útiles cuando necesitas conservar un conjunto pequeño de resultados de búsqueda de Bing antes de aprobar los destinos.