La respuesta corta
Reconocer una vez, leer muchas. Leer un documento es con diferencia lo más caro que hace un campo de IA, así que exactamente un campo lee los adjuntos y escribe una hoja de trabajo estructurada, en JSON, en un campo de texto largo. Todos los demás campos son lectores baratos de solo texto que apuntan a una ruta dentro de esa hoja de trabajo. Veinte valores extraídos cuestan una lectura de documentos más veinte lecturas de texto, y cada valor se deriva de la misma lectura en lugar de veinte lecturas independientes que no coinciden.
La restricción que condiciona todo lo demás: un proceso lee una instantánea del registro tomada al arrancar, por lo que un campo de IA no puede ver lo que otro campo de IA escribió en el mismo proceso. Por eso cada dependencia entre campos de IA es una frontera de proceso: una pasada de IA por proceso, encadenadas al finalizar.
El problema de negocio
Un revendedor compra a proveedores y vende a clientes finales. Cada oportunidad lleva dos documentos: el presupuesto del proveedor, lo que cuesta la mercancía, y el presupuesto propio de la empresa al cliente, el precio al que se venderá. El margen de la oportunidad es la diferencia, y está en esos dos PDF.
En la práctica, nadie lo calculaba en el momento de la oportunidad. El campo de margen del CRM venía rellenado con un porcentaje por defecto, y la cifra real aparecía semanas después, al facturar. Cada informe del pipeline, cada previsión y cada proyección de comisiones intermedia se basaba en una suposición en la que nadie tenía motivos para confiar.
Lo que quería el negocio era sencillo de enunciar:
- el coste real de la venta y el margen real, calculados a partir de los documentos, en el momento en que se adjuntan los presupuestos;
- un registro de auditoría visible: de qué documento sale cada cifra y cómo se llegó al cálculo;
- una señal explícita cuando los documentos no permiten una respuesta fiable, en lugar de una cifra errónea presentada con seguridad;
- ninguna entrada de datos nueva para el equipo de ventas.
Lo interesante son las complicaciones. Los dos documentos rara vez se corresponden uno a uno. Un presupuesto marco del proveedor puede cubrir mucha más capacidad de la que realmente vende la oportunidad, de modo que comparar los totales de los documentos da un margen completamente erróneo: la comparación correcta escala según la cantidad que realmente se vende. Los documentos contienen más de un total general, y el correcto no siempre es el mayor. Los nombres de las empresas aparecen en ambos documentos, así que el lado de compra y el de venta deben distinguirse por su papel y no por su nombre. Y una empresa hermana en otro país hace que una compra intragrupo parezca una compra a un tercero.
Por qué falla el enfoque obvio
El instinto es directo: decidir qué veinte valores se quieren, crear veinte campos de IA, apuntar cada uno de ellos a los documentos del registro, escribir un prompt para cada uno y pulsar Update Fields. Falla de cuatro maneras distintas, y solo la primera es evidente.
Son veinte lecturas de documentos, no una
Leer un PDF es la operación cara: se midieron aproximadamente 23 segundos para un conjunto de dos documentos, frente a unos 11 segundos para una lectura de solo texto. Veinte campos que abren los mismos documentos multiplican por veinte la parte más lenta del trabajo, para obtener información que ya se había extraído diecinueve veces.
Las cifras no coinciden entre sí
Peor que lento. Cada campo vuelve a derivar por su cuenta las cifras subyacentes y, con un conjunto de documentos no trivial, no todos llegan a la misma respuesta. Se acaba con un coste de la venta de un campo y un margen de otro que no son coherentes entre sí, y sin forma de saber cuál es el erróneo.
No hay un orden garantizado
Los campos lanzados desde el botón Update Fields se ejecutan sin una secuencia definida. Cualquier campo que deba basarse en la salida de otro es una condición de carrera, y parecerá funcionar en la primera prueba y fallará de forma intermitente para siempre.
Un campo no puede ver lo que un campo hermano acaba de escribir
Comportamiento de la plataforma. Un proceso de automatización lee una instantánea del registro tomada al arrancar. Un campo de IA no puede ver lo que un campo de IA anterior escribió dentro del mismo proceso: lee sin avisar el valor anterior. Entre procesos distintos funciona correctamente.
Esta es la mayor restricción arquitectónica de todo el diseño, y falla en silencio: el valor que lee es un valor real, solo que el antiguo.
Modelo de datos: reconocer una vez, leer muchas
Un campo hace la lectura. Todo lo demás lee la salida de ese campo.
- Un campo de hoja de trabajo, de texto largo, tiene los documentos activados como fuente de datos. Su prompt le indica que devuelva un único objeto JSON y nada más. Es el único campo que abre alguna vez un PDF.
- Los campos lectores, uno por cada valor que se quiera en un campo tipado real, tienen los documentos desactivados. Cada uno lee la hoja de trabajo y extrae de ella una ruta.
- Los campos de fórmula se encargan de la aritmética entre valores reconocidos. Siempre están actualizados y no pueden desincronizarse, cosa que sí haría un tercer campo de IA que hiciera sumas.
La regla de las capas. Un campo lee los documentos o lee un campo de hoja de trabajo, nunca ambos. Un lector al que se le deja activado el acceso a los documentos volverá a derivar los valores de la fuente y contradirá la hoja de trabajo que debía analizar. Desactive explícitamente los documentos en cada lector.
Por qué JSON y no líneas etiquetadas
No existe un tipo de campo JSON, pero un campo de texto largo cuyo prompt dice «devuelva
solo este objeto JSON, sin texto antes ni después» emite JSON válido de forma fiable.
Admite anidamiento, contiene arrays, y un lector puede apuntar a una ruta como
totals.cost_of_sale en lugar de a un prefijo de línea. Una salida plana
KEY: value también funciona y está bien donde ya está probada, pero JSON es la
mejor opción por defecto para trabajo nuevo.
Capas de dependencias
Cada campo pertenece a una capa determinada por lo que necesita, no por preferencia. En la implementación de referencia:
| Capa | Campos | Lee |
|---|---|---|
| L0 | Clasificación de documentos | los PDF |
| L1 | Estado del conjunto de documentos | L0 |
| L2 | 10 lectores de identificación + el cálculo + una comprobación cruzada independiente | L0 / los documentos |
| L3 | La hoja de trabajo descriptiva | L2 |
| L4 | 3 lectores de importes + 4 lectores descriptivos | L2, L3 |
El campo de estado de L1 está solo en su capa a propósito. Es la barrera que decide si el conjunto de documentos es utilizable, y mantenerlo aparte es lo que evita gastar doce llamadas de IA en un conjunto que nunca iba a producir una respuesta.
Configuración a nivel de campo
En qué puede escribir un campo de IA y en qué no
El servidor enumera sus propios tipos admitidos:
| Admitidos | No admitidos |
|---|---|
currency, email, float, input (texto de una línea), integer, phone, text_area, url |
date, dropdown, checkbox, lookup |
Dos consecuencias que conviene tener en cuenta en el diseño desde el principio. Una fecha reconocida debe guardarse como texto: no hay forma de que un campo de IA rellene un campo de fecha real. Y un valor de tipo enumeración debe ser un campo de texto cuyo prompt restrinja la salida a una lista fija de códigos, con los informes agrupando por la cadena resultante en lugar de por opciones de desplegable. La misma restricción aparece en el lado de la importación: un valor de desplegable sin opción coincidente queda vacío e informa de éxito.
Cómo escribir el esquema JSON en un prompt
El editor de prompts analiza los prompts como HTML y elimina sin avisar todo lo que
esté entre corchetes angulares. Exprese el esquema con valores literales
"", 0, [] y null, nunca con
<placeholders>.
En la implementación de referencia, una sola edición en la interfaz destruyó 23 de 26 marcadores de posición en el contrato de salida de un prompt, dejando etiquetas sueltas y fragmentos deformados. Todas las reglas en prosa sobrevivieron, así que el daño era invisible sin un diff. Mantenga los prompts en control de versiones fuera de la plataforma y haga un diff después de cualquier edición hecha a través de la interfaz.
Campos de fórmula para la aritmética
- Las fórmulas simples no admiten ninguna llamada a funciones: aritmética sobre referencias a campos y literales, nada más. Los nombres de funciones se rechazan al analizar la fórmula.
- Las fórmulas avanzadas sí admiten funciones, pero el campo debe crearse como campo de fórmula calculada. Aplicar a posteriori una fórmula avanzada a un campo numérico existente se acepta, se publica, se relee intacto… y nunca se calcula, porque el campo conserva su naturaleza de columna almacenada. Créelo; no lo convierta.
- Nunca divida por un valor reconocido. Un campo numérico vacío se lee como cero sin ninguna protección, así que una fórmula de porcentaje provoca una división por cero en cada registro que todavía no se ha procesado.
La presencia en el formulario es funcional
Un campo de IA solo puede leer un campo que esté en el formulario de edición de la entidad. Un campo que existe, está publicado, tiene activada la vista previa en la interfaz y se lee perfectamente por la API es invisible para un lector de IA si no está colocado en el formulario. El lector no escribe nada en absoluto, ni siquiera el valor de reserva que especifica su propio prompt.
La prueba: dos campos de hoja de trabajo que estaban en el formulario tenían sus quince lectores funcionando; una hoja de trabajo recién creada que no estaba en el formulario tenía sus tres lectores escribiendo cero en cada ejecución. La comparación de la configuración campo por campo mostró que los lectores que funcionaban y los que fallaban eran idénticos en todos los atributos. Toda la solución consistió en añadir el campo al formulario.
Lo mismo se aplica a los campos calculados, que fuera del formulario no se calculan en absoluto. Y un campo de fórmula recién añadido permanece vacío en todos los registros existentes hasta que se vuelve a escribir en ese registro: actualice un campo a su propio valor para forzar el recálculo.
Automatización y lógica
La implementación de referencia ejecuta doce procesos. No es un exceso de ingeniería; es la consecuencia directa de la restricción de la instantánea del §2. Eso sí, significa que la disciplina de nombres y de responsabilidad descrita en el Blueprint 011, sobre cómo mantener las automatizaciones, se aplica desde el primero.
Un nodo de IA por capa de dependencias
La finalización de un nodo es la única señal que indica «esta capa ha terminado». Repartir una capa entre dos nodos encadenados produce dos señales de finalización independientes, y la que termine primero dispara los pasos posteriores demasiado pronto. Por eso todos los campos de una capa van en un único nodo: en la implementación de referencia, un nodo lleva doce campos y otro lleva siete. Es una regla de corrección, no una cuestión de pulcritud.
Encadenar al finalizar, no con nodos hijos
Desde que los campos de IA pasaron a ser asíncronos, el propio nodo de acción de IA tiene una propiedad de proceso a disparar que se activa al terminar la escritura. Ahora es la única forma segura de llegar a cualquier cosa que lea lo que el nodo ha escrito.
Un nodo hijo normal ya no espera a la IA. Un disparador hijo se activa mientras los campos todavía se están escribiendo, y el proceso posterior lee el valor anterior, sin avisar. El registro de ejecución hace visible la diferencia: el nodo aparece primero como scheduled, después como correcto con un número de campos, y solo entonces aparece la línea del disparador.
Fuente sobre el encadenamiento de procesos. Centro de ayuda de Coevera, Automatizer — triggering a process from another process: los usuarios pueden crear «procesos más reducidos y luego encadenarlos en un flujo de trabajo unificado». Esa página trata solo del encadenamiento de procesos, no de los nodos de IA ni de cuándo terminan.
Un proceso es un único camino lineal
Las condiciones pueden ramificarse, pero una vez dentro de una cadena de acciones no se puede volver a restringir, y un nodo de acción puede tener exactamente un hijo, así que tampoco hay bifurcación desde una acción.
La trampa: la segunda rama de una condición se almacena, se valida, se relee idéntica byte a byte e informa de que está sana, y nunca se ejecuta. No se omite: nunca se evalúa, y no deja ninguna línea en el registro de ejecución. Todo lo condicional posterior a la primera acción tiene que convertirse en otro proceso al que se llega mediante un nodo disparador.
Cuando una finalización debe llegar a varios procesos posteriores, dispara un enrutador: un proceso cuyos únicos nodos son una cadena de nodos disparadores. Como cada subproceso se filtra a sí mismo y una condición falsa detiene ese proceso, encadenar en serie procesos que se filtran a sí mismos funciona, y el orden importa cuando uno posterior lee lo que escribió uno anterior.
Una regla estructural más: el primer nodo de cualquier proceso debe ser un nodo de filtro. Una acción en la raíz se almacena correctamente, informa de que está sana y muestra un lienzo vacío sin ningún error.
Técnicas de prompt que marcaron una diferencia medible
- Compruebe la aritmética de sus ejemplos resueltos. Un porcentaje de margen fue erróneo durante semanas porque el ejemplo incluido en el prompt indicaba un resultado ligeramente incorrecto. El modelo copiaba fielmente un mal ejemplo; no redondeaba con descuido.
- Una autocomprobación debe obligar a obtener una cifra derivada de forma independiente. «Multiplique el porcentaje de vuelta y compare» funcionó. «Sume la lista y compárela con el total» se satisfacía escribiendo dos veces el objetivo, y ocultó dos errores reales.
- Sustituya el juicio por disparadores mecánicos. Una puntuación de confianza descrita en prosa se asignaba de forma incoherente; derivarla de una tabla explícita sobre la lista de indicadores la hizo fiable.
- Incluya el fallo observado como contraejemplo. Cada corrección que funcionó cita la salida errónea real que pretendía evitar.
- Haga que el modelo muestre su razonamiento donde necesite auditarlo. Un bloque de desglose intermedio convirtió una cifra que variaba de forma irreproducible entre ejecuciones en una que podía diagnosticarse dentro de una sola ejecución.
- Las tolerancias en comprobaciones mal condicionadas deben ser proporcionales. Una tolerancia absoluta fija en una comprobación que multiplica la diferencia de dos porcentajes casi iguales produjo veredictos de discrepancia falsos en oportunidades demostrablemente exactas.
Límites y compromisos
Todos los modos de fallo informan de éxito
Ese es el tema. Casi todas las formas en que este diseño sale mal parecen sanas desde fuera.
| Síntoma | Causa real | Cómo distinguirlo |
|---|---|---|
| El nodo registra éxito, updated 0 fields | Agotamiento de los créditos de IA | Afecta al final de una cadena, porque los nodos anteriores gastaron los últimos créditos. Se lee exactamente como «el último paso está roto». |
| El nodo registra éxito, updated 0 fields | Un campo que nombra el prompt no está en el formulario | Otros nodos de IA de la misma ejecución escribieron correctamente. |
| El lector devuelve un valor plausible pero desactualizado | Instantánea del mismo proceso, o un nodo hijo que no esperó a una escritura asíncrona | El valor es un valor anterior real, no un error. |
| La rama nunca se ejecuta, sin error | La segunda rama de una condición: almacenada, validada, nunca evaluada | No hay ninguna línea de evaluación para ella en el registro de ejecución. |
| Campo de fórmula permanentemente vacío | No está en el formulario, o una fórmula avanzada aplicada a posteriori en lugar de creada | La comparación de la configuración con un campo de fórmula que funciona los muestra idénticos. |
| Campo notificado como ausente justo después de una ejecución | Lectura hecha antes de que se asentara la última escritura | La misma lectura, momentos después, devuelve el valor. |
El bloqueo que dio forma a todo el proyecto
Los AI Smart Fields se ejecutaban originalmente de forma síncrona y bloqueaban la base de datos mientras se ejecutaban. Una pasada completa de reconocimiento bloqueaba el espacio de dos a cinco minutos. En un espacio compartido con una docena de usuarios eso no se puede desplegar, y la implementación se mantuvo fuera de producción exactamente por ese motivo: era correcta e inutilizable al mismo tiempo.
Esto quedó resuelto con la versión asíncrona, y la cadena se rehízo sobre disparadores de finalización el mismo día en que se publicó. Merece la pena dejar constancia de ello en lugar de borrarlo discretamente: explica por qué la arquitectura tiene la forma que tiene, y volver a ejecutar los dos casos de prueba después del cambio produjo cifras idénticas a las originales síncronas, que es como se sabe que cambió la fontanería y nada más.
Otras restricciones encontradas en esta implementación
- Las operaciones por lotes tienen un límite de 100 registros.
- Las fórmulas avanzadas no pueden validarse a través de la API: se aceptan nombres de funciones inventados sin ninguna queja, y una lectura normal del registro no devuelve los valores calculados. Confíe solo en el editor de fórmulas de la interfaz.
- La ejecución requiere un administrador. Un token de acceso personal puede configurarlo todo y no ejecutar nada; la ejecución manual de procesos requiere un usuario real.
- Los procesos con ámbito de espacio son de solo lectura a través de la API. Las actualizaciones se rechazan con un error de permisos, así que el trabajo en procesos necesita una ventana en la que tengan ámbito personal.
- Cambiar el nombre de un campo no lo cambia en el formulario: el formulario guarda su propia copia de cada etiqueta.
- No se publican los límites de tipo de archivo, tamaño y volumen de los documentos. Verifíquelos empíricamente con su propio conjunto de documentos.
- El modo asíncrono es ligeramente más lento de principio a fin: unos 3½ minutos frente a 2–3 en modo síncrono para la misma cadena, porque cada traspaso espera a un evento de finalización. Ya no bloquea el espacio, que era precisamente el objetivo.
El equilibrio entre coste y detalle
De los 22 campos de IA de la implementación de referencia, solo seis son esenciales: el estado, dos importes totales, el porcentaje de margen, la puntuación de confianza y la lista de indicadores. Los otros 16 son lectores descriptivos que rellenan el registro para las personas. Eliminarlos reduce aproximadamente a la mitad el tiempo de ejecución, a costa del detalle reconocido en el registro. Conviene saberlo antes de dar por hecho que toda la cadena es necesaria.
Verificación
El registro de ejecución es el único relato fiel de lo que se ejecutó. Las relecturas de configuración, los estados de éxito y los indicadores de salud mienten todos de las maneras concretas catalogadas en el §6. Lea el registro de actividad del proceso después de cada ejecución.
Lo que se comprobó realmente:
- Número de campos por nodo, en cada ejecución. Un nodo que debe escribir doce campos debe registrar doce. Esta es la comprobación más importante, porque un campo que no se escribe sin avisar conserva su valor anterior y correcto, de modo que una ejecución sobre un registro sin limpiar puede parecer perfecta y estar desactualizada.
- Limpiar y volver a ejecutar desde vacío. Todos los campos de IA se pusieron a null antes de una pasada completa, para que ningún valor pudiera heredarse de una ejecución anterior.
- Dos conjuntos de documentos contrastados, de principio a fin: un par sencillo uno a uno y un par marco en el que el presupuesto del proveedor cubre mucho más de lo que vende la oportunidad. El segundo es el que demuestra el diseño, porque ahí comparar los totales de los documentos da una respuesta muy equivocada.
- Cada lector comparado con su propia hoja de trabajo de origen, no solo revisado para ver si era plausible.
- Un campo de comprobación cruzada independiente que lee los documentos directamente y deriva la misma cifra por otra vía, con la diferencia visible en el registro. Que dos cifras derivadas de forma independiente coincidan es una prueba; que una cifra parezca razonable no lo es.
- Orden de los disparadores confirmado en el registro: que el enrutador disparó sus destinos en el orden del que depende una barrera posterior.
- Nueva ejecución tras el cambio a asíncrono, comparada con los resultados de referencia síncronos. Las cifras idénticas demostraron que cambió la fontanería y no la lógica.
Qué indicaría una regresión: un nodo que registra menos campos de los que contiene su capa; un lector que devuelve un valor que contradice la hoja de trabajo que lee; que la diferencia de la comprobación cruzada aumente; un reconocimiento que produce una salida segura sobre un conjunto de documentos que debería haberse rechazado como inutilizable.
Preguntas frecuentes
¿Puede la IA leer un PDF adjunto a un registro del CRM y rellenar campos a partir de él?
Sí. En Coevera CRM, los AI Smart Fields pueden tomar como fuente de datos los documentos adjuntos al registro y escribir un valor extraído en un campo. El enfoque ingenuo —un campo de IA por valor, cada uno leyendo los documentos— es caro e incoherente, porque leer un documento es con diferencia la operación más costosa y cada campo vuelve a derivar las cifras subyacentes por su cuenta. El patrón fiable es reconocer una vez, leer muchas: un campo lee los documentos y escribe una hoja de trabajo estructurada en JSON en un campo de texto largo, y todos los demás campos son lectores baratos de solo texto que apuntan a una ruta dentro de esa hoja de trabajo. Una extracción de veinte valores pasa de veinte lecturas de documentos a una lectura de documentos más veinte lecturas de texto.
¿En qué tipos de campo puede escribir un AI Smart Field?
El servidor enumera como tipos admitidos currency, email, float, input (texto de una línea), integer, phone, text_area y url. Un AI Smart Field no puede escribir en campos desplegables, de fecha, de casilla de verificación ni de lookup. Una fecha reconocida debe guardarse como texto, y un valor de tipo enumeración debe ser un campo de texto cuyo prompt restrinja la salida a una lista fija de códigos, con los informes agrupando por la cadena.
¿Por qué mi campo de IA informa de éxito pero no escribe nada?
Hay dos causas habituales y ambas informan de éxito. La primera, la presencia en el formulario: un AI Smart Field solo puede leer un campo que esté colocado en el formulario de edición de la entidad. Un campo que existe, está publicado y se lee sin problemas por la API es invisible para un lector de IA si está fuera del formulario: el lector no escribe nada en absoluto, ni siquiera el valor de reserva que especifica su propio prompt. La segunda, el agotamiento de los créditos de IA, que registra el nodo como correcto con cero campos actualizados. Se distinguen según si otros nodos de IA de la misma ejecución escribieron correctamente: si lo hicieron, sospeche de la presencia en el formulario; si los fallos se concentran al final de una cadena, sospeche de los créditos.
¿Puede un campo de IA leer lo que otro campo de IA acaba de escribir?
No dentro del mismo proceso de automatización. Un proceso lee una instantánea del registro tomada al arrancar, por lo que un campo de IA no puede ver lo que un campo de IA anterior escribió en ese mismo proceso: lee sin avisar el valor anterior. Por eso cada dependencia entre campos de IA debe ser una frontera de proceso: una pasada de IA por proceso, con el siguiente proceso disparado al finalizar. Desde que se publicaron los campos de IA asíncronos, el propio nodo de acción de IA tiene una propiedad de proceso a disparar que se activa cuando termina la escritura; un nodo hijo normal no espera a la IA y leerá datos desactualizados.