De una página a un campo estructurado: un pipeline de datos para LLM

¿Qué hay que decidir antes de que un parser toque la página?

Se deciden la entidad y los campos antes de mirar una plantilla. Un producto puede necesitar un identificador, un nombre, un precio, una moneda, una marca de disponibilidad, un vendedor, una región, una URL de origen y un momento de observación. Un aviso puede necesitar una autoridad, una fecha de efecto y un estado. Si un campo no está en esa lista, el parser no lo inventa. La lista es también la regla de minimización. Los nombres personales, los identificadores de cuenta y los relatos en texto libre se quedan fuera salvo que una finalidad revisada los haya puesto ahí.

El canal se decide en el mismo paso. Si el editor ofrece una API o un archivo con licencia con esos campos, se usa. El parseo de la página es la vía residual para material lícitamente disponible solo como página renderizada. Añadir un dominio es un hecho de gobernanza, con un responsable y una fecha de revisión. MetaEdge puede encaminar la petición y devolver la respuesta que la plantilla permite. La plantilla no se vuelve más permisiva porque una demo necesite una columna más.

El fallo se decide antes del éxito. Un precio ausente no es cero. Una fecha sin parsear no es hoy. Una página que devuelve un desafío no es un catálogo vacío. Cada uno de esos resultados necesita un estado sobre el que el sistema posterior pueda ramificar. Los equipos que solo especifican el JSON feliz verán a un modelo llenar los huecos con valores por defecto fluidos. Se escriben primero en el esquema los nulos, los enumerados y las condiciones de parada.

¿En qué se diferencia la extracción del resumen?

La extracción copia un valor que está en la página a una ranura tipada. El resumen escribe una frase nueva sobre la página. La primera se puede comprobar contra la cadena de origen. El segundo no, salvo con otra lectura. Para precios, fechas, identificadores y estados, la extracción es el trabajo adecuado. Un resumen puede explicar un aviso después de que existan los campos. Es un mal lugar para esconder el precio. Si el único artefacto es un párrafo, el sistema siguiente parseará el párrafo, y ese parser es peor que el que se saltó.

Se guarda el tramo de evidencia. Para cada campo extraído se conserva la subcadena en bruto y, cuando existe, un puntero estable dentro de la página. Un revisor puede ver entonces que 19,90 se volvió 19.90 EUR y no 1990. Sin el tramo, una disputa se vuelve una cuestión de gusto. Con el tramo, se vuelve un diff. Es ingeniería de datos ordinaria, y también es el modo en que una cita de agente sigue siendo honesta. El modelo cita el campo. El campo apunta al tramo. El tramo apunta a la URL y a la hora.

No se pide a un modelo que extraiga y resuma en una sola llamada si se necesita un número sobre el que se va a calcular. El camino atractivo es un prompt que devuelve prosa más un blob JSON. El blob deriva cada vez que deriva el prompt. Los parsers deterministas van en los campos que tienen gramática, y un modelo se usa solo donde la página es lengua y no un valor. Cuando se usa un modelo, se valida la salida contra el esquema y se rechaza el registro si falla. Un objeto bonito que no valida no es un registro.

¿Qué normalizaciones frenan errores silenciosos entre mercados?

Los números, las fechas y el dinero son donde viven los errores silenciosos. Una coma puede ser una marca decimal o un separador de millares. Una fecha escrita 10/06/2026 no es el mismo día en cada locale. Un precio puede incluir el impuesto en un país y excluirlo en otro. Se normaliza solo después de conocer el locale de la página, y se guarda la cadena original junto al valor canónico. Si no se puede saber, el campo queda desconocido. Adivinar el lugar decimal a volumen entrenará a cada gráfico posterior a fiarse de una ficción.

Las unidades y los identificadores piden la misma disciplina. Un paquete de seis no es la misma oferta que una unidad suelta a un precio parecido. Un sku de vendedor no es un id global de producto. Colores y tallas que se parecen entre idiomas pueden ser variantes distintas. La resolución de entidades debe rechazar una fusión cuando la clave es débil. El coste de una fusión perdida es una fila duplicada. El coste de una fusión mala es una serie de precios que compara dos productos y llama a la diferencia un movimiento de mercado.

La región permanece en el registro durante la normalización. Una ruta residencial o de centro de datos puede haber hecho falta para ver la página local, pero la ruta no es la moneda. Se escriben las dos. MetaEdge puede situar la petición en la geografía que nombra la plantilla y devolver la respuesta. El parser tiene que registrar igualmente lo que mostró la página. Un valor en euros normalizado sin región y sin marca fiscal no está listo para un asistente que compara ofertas a través de fronteras.

¿Dónde debe situarse un modelo de lenguaje y dónde debe quedarse fuera?

Un modelo es útil cuando la página es prosa: un aviso de incidencia, un párrafo de política, una descripción de producto que hay que clasificar en un conjunto pequeño de etiquetas. Se le da el texto pertinente, un conjunto cerrado de etiquetas y un esquema. Se le pide que se abstenga cuando el texto no sostiene una etiqueta. Un modelo es una mala calculadora y un mal reloj. No debe sumar impuestos, convertir monedas ni decidir que una página sin fecha es actual. Esas son funciones con pruebas. Quedan fuera del prompt.

El modelo se queda fuera de la obtención. No elige dominios, rutas ni ritmos. Un bucle de planificación que puede editar el rastreador ampliará el alcance en cuanto un campo esté vacío. La herramienta de obtención toma una clave de fuente de la lista permitida y devuelve bytes más un estado. La etapa de parseo es aparte. MetaEdge encamina y recoge dentro del alcance que recibe. El modelo de lenguaje ve campos, no el derecho a ensanchar la recolección. Esa separación es la diferencia entre un pipeline y un navegador sin revisar.

Se evalúa el modelo en el campo, no en la fluidez. Se muestrean páginas en las que cambió la plantilla, en las que falta el valor y en las que dos locales formatean el mismo número de modo distinto. Se puntúa la coincidencia exacta en identificadores y una tolerancia escrita en los precios. Una puntuación alta en una rúbrica de resumen puede esconder un error decimal sistemático. Se publican los casos de fallo junto a los de éxito. El plan de The NEST y cualquier plan posterior de GPU no califican esta prueba. La califican los casos de prueba.

¿Cómo se guarda la observación en bruto junto al campo derivado?

Se guardan dos capas. La capa en bruto guarda la URL, el momento de obtención, el estado, un hash del cuerpo y una muestra o un puntero con una retención corta. La capa derivada guarda los campos tipados, la versión del parser y la subcadena en bruto de cada campo. Comparten un id de documento. Cuando cambia un parser, se puede reprocesar desde la muestra en bruto sin fingir que el parseo nuevo es lo que se observó el mes pasado. Cuando un abogado pregunta qué se conservó, se puede señalar la regla de retención en lugar de un cubo que creció sin una.

Los hashes hacen visible la deriva. Si el hash del cuerpo cambia y los campos no, el parser puede estar ciego a un movimiento de plantilla. Si los campos cambian y el hash no, alguien editó aguas abajo. Se alerta en los dos casos. Un pipeline que solo mira HTTP 200 sigue en verde mientras los precios vuelven vacíos. La completitud de campos, las violaciones de esquema y los saltos bruscos de valor están en el mismo panel que la latencia. MetaEdge puede devolver la respuesta y la ruta. Su validador decide si esa respuesta se convirtió en un registro.

La supresión tiene que cruzar las dos capas. Si una fuente sale de la lista permitida, la muestra en bruto y los campos derivados se van con ella, y también las entradas de índice que un agente todavía podría citar. Un id de documento hace posible la búsqueda. Los manifiestos de entrenamiento que apuntaban al id se pueden reconstruir sin esos ejemplos. No es la afirmación de que un modelo ya entrenado olvida. Es el control que impide que la siguiente ejecución repita la inclusión. Una procedencia que no se puede consultar es un párrafo de una política, no un pipeline.

¿Qué aspecto tiene un registro de producción cuando llega a la recuperación?

Un registro de producción es pequeño y explícito. Lleva la clave de entidad, los campos tipados, el locale, la región de la petición, el tipo de ruta, la URL de origen, el momento de observación, la versión del parser y un estado. El texto opcional de explicación va en un campo aparte, marcado como texto. La recuperación puede filtrar por edad y por estado antes de que el modelo vea nada. Una herramienta de agente devuelve este objeto, no una página. Si un campo obligatorio es nulo, el estado dice por qué, y el agente no es libre de rellenarlo.

El mismo registro puede alimentar más de un almacén si la etiqueta de finalidad viaja con él. Un índice vivo para RAG guarda las filas actuales. Una instantánea estática para evaluación congela una versión. Una mezcla de entrenamiento toma solo las filas cuya finalidad y cuya revisión de derechos lo permiten. Copiar la tabla porque está limpia es el modo en que una serie de precios se vuelve dato de entrenamiento que nadie aprobó. MetaEdge puede entregar la carga estructurada. El registro del cliente decide qué puerta atraviesa.

La prueba del pipeline es una pregunta que una persona puede auditar. Qué página, observada cuándo, por qué ruta, produjo este precio, y qué parser convirtió la cadena en un número. Si el sistema puede responder, un asistente puede citarlo y una ejecución de entrenamiento puede incluirlo o excluirlo a propósito. Si no puede, el modelo está resumiendo una página que nadie puede reconstruir. Los campos estructurados son el modo en que los datos web siguen siendo inspeccionables. No son la afirmación de que cada página de la web sea suya para tomarla.

FAQ