10 de junio de 2026. Estoy abriendo una vía de ingesta dual de OpenText porque una canalización documental debe responder a más que si puede extraer texto. Debe mostrar de dónde procede un documento, dónde reside su archivo binario preservado, qué permisos se aplican y qué representación para la recuperación se creó. El diseño mantiene separados el material de origen y su residencia gobernada: el texto alimenta los embeddings, un PDF opcional se preserva en Alfresco y el registro resultante lleva el linaje tanto del origen como de la residencia. El trabajo de hoy es un piloto con datos propiedad de Dave. No autoriza ni valida la ingesta de material de Partner N, que sigue sujeta a autorización.
La vía asigna una función a cada elemento
La implementación incluye un lector de OpenText, un orquestador de ingesta dual, un punto de entrada por línea de comandos, un segundo esquema de embeddings y un servicio local de embeddings. La fuente definitiva de contenido es Edit_Sentence. El lector utiliza esos archivos de texto para crear la entrada de los embeddings y empareja un PDF opcional por nombre base; los PDF se preservan como archivos binarios de referencia y nunca se utilizan para generar embeddings. El lector de la interfaz de programación de aplicaciones (API) de OpenText Content Server sigue siendo un esqueleto. Define una interfaz futura, pero no es una integración de API terminada.
El orquestador registra datos del archivo, linaje de origen, eventos de ingesta, instantáneas de listas de control de acceso (ACL), permisos y embeddings. Un linaje canónico de Alfresco identifica la residencia preservada; un linaje de OpenText identifica el origen. Esta separación permite que una revisión posterior explique tanto el sistema de registro oficial como la fuente que aportó el contenido. La vía de recuperación más reciente utiliza un modelo nomic de 768 dimensiones servido localmente mediante LM Studio y puede añadir un prefijo contextual antes de generar el embedding. La vía anterior de 384 dimensiones sigue disponible. Esta implementación está pensada para comparar, no para afirmar que un modelo sea universalmente mejor.
Lo que establece la validación del piloto de hoy
El registro de validación de hoy informa de una carga real en Alfresco y de una ingesta completa de un documento con material propiedad de Dave. Registra dos filas de linaje, una instantánea ACL, permisos de lectura y administración para el propietario y embeddings de fragmentos. Una nueva generación de embeddings sobre el mismo material del piloto produjo 36 fragmentos contextualizados de 768 dimensiones. Una consulta semántica de ejemplo devolvió tres resultados pertinentes con puntuaciones de similitud coseno informadas de 0,85, 0,85 y 0,84. Las pruebas del lector informan de 10 resultados satisfactorios de 10. Esto establece que la vía integrada puede funcionar con el material y el entorno seleccionados. No es un estudio comparativo, una medición amplia de recuperación ni un resultado generalizable a un corpus de clientes.
La escala cambia la siguiente prueba
Un ensayo anterior del corpus, de solo lectura, identificó 139 documentos y proyectó unos 316.777 fragmentos con granularidad de una oración. Ese resultado impulsó la elección final de agrupación: varias oraciones se agrupan en un fragmento, reduciendo la proyección a unos 75.000 fragmentos. La canalización también admite recuperación contextual por documento, de modo que la pasada de contexto requiere unas 86 llamadas en lugar de una por cada fragmento. Los valores predeterminados de la línea de comandos ahora agrupan cinco oraciones con una oración de solapamiento y generan contexto una vez por documento. Estas configuraciones son decisiones inspeccionables, de modo que una ejecución posterior pueda comparar el coste y la calidad de recuperación con el enfoque anterior por oración. Esos cambios hacen más práctico el experimento masivo, pero no producen hoy un resultado de procesamiento masivo. La siguiente prueba es una ejecución controlada con los fragmentos agrupados y el contexto por documento, después de decidir quién controla la unidad de procesamiento gráfico (GPU). Debe volver a inspeccionar las reejecuciones idempotentes, los permisos, el linaje y la calidad de recuperación.
Base histórica: hito del repositorio del 10 de junio de 2026, commit bdf7cce.