De 3 días leyendo informes a una consulta de 10 minutos

Tres profesionales de inversión. 450 empresas en su lista de seguimiento. Antes de cada reunión trimestral del comité, alguien dedicaba de dos a tres días a leer PDFs para preparar un informe cualitativo. Esto es lo que construimos para solucionarlo y lo que hizo falta para hacerlo bien.

TLDR

Emerald Wealth Partners es una family office privada. Su cartera real es pequeña a propósito, de unas 20 a 25 posiciones. Pero la lista de seguimiento que la respalda es deliberadamente amplia: 450 empresas públicas vigiladas como candidatas futuras, puntos de referencia competitivos y contexto sectorial. Tres profesionales de inversión (un socio principal y dos asociados) hacen toda la investigación.

FactSet cubre los datos financieros. Todo lo demás, lo que la dirección dijo sobre poder de fijación de precios, disciplina de capital, posición competitiva o inversión en IA, seguía viniendo de leer los informes a mano.

El problema era el tiempo. Antes de cada reunión trimestral del comité de inversión, alguien dedicaba de dos a tres días a leer PDFs para preparar un resumen cualitativo. Para una nueva posición, la investigación profunda significaba que un asociado trabajara con los últimos cuatro informes anuales de una empresa más las transcripciones recientes de llamadas de resultados (unas 1.200 páginas) durante varios días.

Construimos una herramienta privada de búsqueda con IA sobre todo su corpus de investigación: 2.200 informes anuales y transcripciones de llamadas de resultados de 400 empresas. Los 50 nombres restantes de la lista de seguimiento se excluyeron porque no tenían cuatro años de historial de presentaciones ante la SEC cuando se armó el corpus. El corpus cubre las cuatro presentaciones anuales más recientes por empresa (10-K y 20-F), además de transcripciones obtenidas de los anexos 8-K cuando se presentaron ante la SEC.

Haz una pregunta en lenguaje sencillo. Obtén una respuesta corta con cita a la fuente. Ve el pasaje exacto del que proviene. Haz clic para llegar al informe o la transcripción original de la SEC. Todo se ejecuta en su infraestructura. Sus consultas nunca salen de su entorno.

10 min

Preparación de la investigación para el comité de inversión

Antes eran de 2 a 3 días de lectura manual por ciclo de reuniones.

3×

Nuevas posiciones evaluadas por trimestre

El equipo ahora evalúa de 12 a 15 nombres nuevos por trimestre, frente a 4 o 5.

0%

Errores de cita desde el lanzamiento

Cada respuesta enlaza al pasaje exacto del informe o la transcripción original.

50+

Consultas por semana a los 60 días

Las comparaciones entre empresas y el análisis histórico del tono son los tipos más comunes.

El momento que justificó el proyecto

Las reuniones trimestrales del comité de inversión en Emerald se estructuran en torno a un informe cualitativo: cómo ha cambiado el tono de la dirección en toda la cartera, qué ha cambiado en el lenguaje de los factores de riesgo, si las cosas que las empresas dijeron que harían en el último informe anual aparecen en las llamadas de resultados recientes. Preparar ese informe llevaba de dos a tres días cada trimestre.

Antes de una reunión en particular, el socio principal quería una respuesta sencilla. ¿Habían mantenido 15 empresas minoristas y de consumo la coherencia en cómo hablaban de aranceles y costes crecientes durante los últimos dos años, o el lenguaje había cambiado silenciosamente? Responder eso significaba leer unas 60 presentaciones trimestrales de esas 15 empresas y luego contrastarlo todo con lo dicho en cada llamada de resultados.

El asociado dedicó tres días. La reunión del comité fue el día dos. El socio principal entró con notas parciales.

Después, ella dijo lo que llevaba diciendo un año: «Tiene que haber una mejor manera de hacer esto». Esta vez nos pidió que lo evaluáramos.

Lo que ya habían probado

Uno de los asociados había construido un prototipo por su cuenta: la API de OpenAI, unos pocos PDFs subidos por sesión y una interfaz de chat sencilla. Funcionaba para preguntas de una sola empresa y una sola presentación. No podía mantener más de uno o dos documentos en contexto, lo que descartaba cualquier pregunta entre empresas o entre años. Y en ocasiones las respuestas hacían referencia a pasajes que, al contrastarlos con la presentación original, no decían exactamente lo que el modelo afirmaba.

Ella lo llamaba alucinación plausible. La respuesta incorrecta suena exactamente correcta. Es peor que no tener respuesta porque no sabes que debes verificarla.

Dos memorandos de inversión salieron resumiendo el lenguaje de la dirección de una empresa sobre poder de fijación de precios usando citas que el modelo había fabricado parcialmente. Los pasajes citados existían. Las frases concretas citadas, no. No fue un gran problema porque ambos memorandos eran para discusión interna.

Cuando vinieron a nosotros, el requisito era sencillo: o la respuesta viene con una fuente a la que puedes hacer clic y verificar, o no hay respuesta.

FactSet, Bloomberg AI y las herramientas de búsqueda de IA de propósito general no bastaron

Su suscripción a FactSet maneja los datos cuantitativos con precisión. Cuando necesitan ingresos, márgenes, ratios de deuda o estimaciones de consenso, FactSet es la herramienta correcta. Lo que la estación de trabajo estándar de FactSet no hace es responder «¿cómo ha descrito esta dirección su enfoque de asignación de capital en los últimos cinco informes anuales, y ha cambiado ese lenguaje?». Esa pregunta requiere lectura. FactSet ha añadido funciones de IA en los últimos años, pero funcionan sobre el universo de datos propio de FactSet, no sobre un corpus privado y curado limitado a las 400 empresas que realmente siguen.

Las herramientas generales de búsqueda con IA (Perplexity, funciones de IA integradas en varias plataformas de investigación) citan artículos de noticias y comentarios de analistas. Para la investigación fundamental basada en fuentes primarias, una paráfrasis en un artículo de noticias no es una cita. Quieres la frase del 10-K, no el resumen que alguien hizo de ella.

El prototipo del asociado tenía los instintos correctos: privado, local, trabajando directamente con fuentes primarias. Pero solo funcionaba una sesión a la vez. No podía mantener una biblioteca permanente de 2.200 documentos. No podía responder preguntas entre empresas porque no podía mantener más de uno o dos documentos a la vista a la vez. Y se inventaba cosas con la frecuencia suficiente como para no ser utilizable.

Lo que necesitaban era algo que mantuviera todo el corpus en memoria de forma permanente, que buscara por significado y por palabras exactas al mismo tiempo, y que se negara a responder cuando la evidencia no fuera lo bastante sólida para respaldar una respuesta segura. Ese último comportamiento (decir «no hay datos» en lugar de adivinar) resultó ser lo más difícil de construir correctamente.

También había una cuestión de datos que plantearon pronto y nos tomamos en serio. Lo que Emerald investiga es la señal más sensible posible para una oficina de inversión. Que eso pasara por los sistemas de un proveedor externo creaba un riesgo que no estaban dispuestos a asumir. La herramienta se ejecuta en su infraestructura con sus claves de API. Una consulta sobre lo que Nvidia dijo sobre capacidad en sus últimas tres llamadas de resultados nunca toca un servidor que no sea suyo.

La construcción de siete semanas

Siete semanas desde el inicio hasta una herramienta que el equipo pudiera poner ante un memorando real del comité. Cada semana aportó algo concreto, y saltarse cualquiera de ellas habría dejado una herramienta en la que nadie pudiera confiar de verdad.

1. 01

   Descubrimiento + alcance del corpus

   Definir qué 400 empresas importaban de verdad para la lista de seguimiento, para que la herramienta respondiera preguntas sobre el universo correcto desde el primer día

2. 02

   Pipeline de ingesta: informes + transcripciones

   2.200 informes anuales y transcripciones de llamadas de resultados convertidos en un corpus buscable, que se actualiza solo cada semana sin intervención de ingeniería

3. 03

   Búsqueda más inteligente + emparejamiento de empresas

   El motor que garantiza que una pregunta sobre una empresa no devuelva respuestas sobre otra distinta

4. 04

   Suite de evaluación (de 13 a 83 casos fundamentados)

   Una prueba permanente de si la herramienta da respuestas correctas, no solo respuestas que suenan plausibles, antes de que nadie del equipo de inversión la viera

5. 05

   Ajuste de recuperación + tres versiones del mismo error

   Cerró la brecha entre «devuelve una respuesta» y «devuelve la respuesta correcta siempre», incluidos errores que habrían atribuido citas a la empresa equivocada

6. 06

   Capa de fidelidad + visor de fuentes

   Cada respuesta enlaza a la frase exacta de la que proviene, para que nada llegue a un memorando del comité sin poder verificarse con un clic

7. 07

   Puertas CI + entrega

   Fijó de forma permanente el listón de precisión, formó al equipo y entregó una herramienta que se mantiene al día sola

Construido con: OpenAI para el motor de búsqueda, Supabase para almacenar y buscar el corpus, el feed de datos públicos de SEC EDGAR para obtener los informes y un pipeline personalizado para mantenerlo todo organizado y buscable. La interfaz de consultas es una aplicación web interna ligera. Los costes de infraestructura y API rondan los $150-250 al mes con el volumen de consultas actual del equipo.

Cómo meter 2.200 documentos en un corpus buscable

Las dos primeras semanas fueron pura configuración. Nada más podía construirse hasta que los 2.200 documentos se descargaran, se dividieran en piezas buscables y se almacenaran.

El pipeline descarga cada informe directamente de SEC EDGAR, elimina el formato y divide el documento en dos capas. Los pasajes pequeños, de unas 220 palabras cada uno, son lo que la búsqueda escanea realmente para encontrar la respuesta correcta. Las ventanas más grandes, de unas 650 palabras cada una, son lo que la herramienta lee para redactar la respuesta. Un fragmento de 220 palabras rara vez tiene suficiente contexto alrededor para tener sentido por sí solo. La herramienta necesita el pasaje más completo para explicar lo que encontró.

Las transcripciones de llamadas de resultados necesitaron un enfoque diferente. Muchas empresas presentan sus transcripciones ante la SEC poco después de la llamada, como anexo de un informe rutinario. El pipeline las descarga igual que el resto de informes, pero las trata de forma distinta una vez que las tiene: mantiene cada pregunta del analista emparejada con su respuesta, en lugar de dividir la conversación.

El corpus también incluye empresas extranjeras de la lista de seguimiento, como ASML, TSMC y SAP, que presentan tipos de informes distintos a los de las empresas estadounidenses. El pipeline maneja ambos. Algunas de esas presentaciones extranjeras resultan ser portadas en blanco sin contenido real. Se registran y se omiten automáticamente, sin detener el resto.

Final de la semana 2: 400 empresas, 2.200 informes anuales y transcripciones, unas 160.000 piezas buscables.

El pipeline además se ejecuta solo a partir de entonces, con una frecuencia semanal. Cuando llegan informes nuevos al sitio de la SEC, los descarga y los añade a lo ya existente, sin duplicar nada ni tener que reconstruirlo desde cero. Cada ejecución semanal produce un informe con lo que se actualizó y lo que, en su caso, se omitió. Nada de eso requiere que un ingeniero lo supervise.

La primera versión y por qué fallaba en silencio

La primera versión de la búsqueda era básica. Entraba una pregunta, la herramienta encontraba los 12 pasajes que sonaban más parecidos y esa era la respuesta. Sin comprobar de qué empresa trataba realmente la pregunta. Sin coincidencia de palabras clave junto a la búsqueda por significado. Sin forma de decir «no lo sé» cuando el corpus no tenía nada relevante.

Funcionaba con preguntas directas. «¿Cómo habló Nvidia del riesgo en la cadena de suministro de IA?» devolvía pasajes de Nvidia. Todo lo demás fallaba.

Una pregunta sobre presión en los costes de los insumos podía devolver tres pasajes del mismo informe sobre un tema totalmente ajeno, solo porque la redacción sonaba parecida. Una pregunta amplia como «¿qué empresas mencionaron disciplina de precios en llamadas de resultados recientes?» devolvía la misma empresa seis veces, porque nada empujaba a la herramienta a sacar de varias empresas. Una pregunta sobre una empresa que ni siquiera estaba en el corpus seguía obteniendo una respuesta que sonaba segura.

Lo medimos. Aproximadamente dos de cada tres veces, el pasaje correcto ni siquiera era el primer resultado. Cada corrección posterior apuntaba a uno de estos fallos concretos.

El error del ticker: tres apariciones

El fallo más instructivo apareció tres veces con disfraces distintos.

La primera versión emparejaba nombres de empresas comprobando si alguna parte del nombre aparecía en la pregunta. Los tickers de una sola letra lo rompieron de inmediato. El ticker de AT&T es «T». La palabra «discussed» contiene la letra T. Toda pregunta sobre estrategia de IA se encaminaba a AT&T, y también a Disney, porque el ticker de Disney, DIS, está dentro de la palabra «discussed». La solución: emparejar solo palabras completas, nunca letras escondidas dentro de otras palabras.

Luego el mismo problema volvió con otra forma, esta vez con palabras comunes incrustadas en nombres legales de empresas. «Companies» forma parte de «Lowe’s Companies, Inc.». Una pregunta como «¿qué empresas mencionaron disciplina de precios?» filtraba los resultados hasta Lowe’s. «Electric» forma parte del nombre de General Electric. «Technology» aparece en el nombre legal completo de varias empresas del corpus. La solución: cualquier palabra que aparezca en el nombre de más de una empresa se elimina de la lista de emparejamiento, dejando solo las palabras que de verdad identifican una única empresa.

Tercero, las abreviaturas. Alguien que escribía «IA» en una pregunta no coincidía con informes que escribían «inteligencia artificial» completa. Un analista que buscaba inversión en IA se perdía la mitad de los resultados sin saberlo. La solución: la herramienta ahora expande las abreviaturas comunes antes de buscar.

Ninguno de estos problemas apareció solo con leer el código. Los tres se detectaron porque la suite de pruebas seguía haciendo una pregunta sencilla tras cada búsqueda: qué empresas volvieron realmente, y ¿es esa la lista correcta?

El fantasma de la búsqueda de 40 segundos

Durante aproximadamente una semana, las búsquedas tardaban 40 segundos. Habíamos construido el índice de búsqueda, confirmado que funcionaba, y veíamos cómo cada pregunta avanzaba a paso de caracol.

La causa era un único ajuste escondido en la configuración de búsqueda de la base de datos. Limitaba silenciosamente cada búsqueda a 40 resultados, sin importar cuántos se hubieran pedido. Las preguntas amplias que necesitaban 80 resultados para sacar respuestas de varias empresas solo obtenían 40, sin aviso de que algo se había cortado. Los resultados simplemente se veían pobres y el ranking parecía mal. Además, la búsqueda hacía trabajo extra innecesario en segundo plano para cada pregunta grande, que era lo que la ralentizaba.

Cambiar un ajuste lo arregló. Pero encontrar ese ajuste solo fue posible porque la suite de pruebas ya estaba haciendo la pregunta correcta: ¿por qué una búsqueda amplia sigue devolviendo resultados de la misma empresa?

Mide antes de ajustar

Antes de tocar cualquiera de los ajustes de búsqueda, construimos una suite de pruebas etiquetada. Trece casos escritos a mano al principio: preguntas que deben devolver empresas concretas, preguntas que deben sacar temas concretos y preguntas que deben devolver nada: empresas que no están en el corpus, temas ausentes de cualquier informe.

A partir de ahí, la suite creció sacando temas reales del propio corpus y generando preguntas de prueba en torno a seis categorías: una sola empresa, comparaciones lado a lado, tendencias históricas, coincidencia de alias, búsquedas filtradas y preguntas deliberadamente imposibles de responder, pensadas para comprobar que la herramienta dice «no hay datos» en lugar de adivinar. Cada pregunta de prueba generada se ejecuta contra la herramienta en vivo antes de añadirse a la suite. Si la herramienta no puede responderla de verdad con el corpus actual, la pregunta no entra. Nada en el archivo de pruebas espera una respuesta que el corpus no pueda dar.

La suite creció hasta 83 casos fundamentados. Construirla encontró más problemas que la revisión de código.

Una lección recurrente: las preguntas de prueba deben crecer junto con el corpus. «¿Qué empresas mencionaron inversión en IA?» se escribió cuando solo había un puñado de empresas indexadas. Contra las 400 completas, una buena respuesta saca 20 o más empresas distintas. La prueba original, escrita para esperar una lista corta y fija, estaba mal, no la herramienta. Cualquier prueba así ahora comprueba un número mínimo de empresas en lugar de una lista exacta, para que siga teniendo sentido a medida que el corpus crece.

29 intentos de ajuste, una mejora real

Una vez que la suite de pruebas fue lo bastante grande para confiar en ella, intentamos ajustar la búsqueda: cuánto peso dar a la coincidencia por significado frente a la de palabras clave, cuántos resultados recuperar para una pregunta amplia y cuán estricto ser antes de que la herramienta confíe en una coincidencia lo bastante para responder. 29 combinaciones distintas, probadas un cambio a la vez contra el mismo conjunto de casos.

La configuración inicial ya estaba cerca de lo correcto. La única mejora real: recuperar menos resultados para preguntas amplias (40 en lugar de 80) hacía que el pasaje correcto apareciera más arriba con más consistencia, sin caída de precisión. Un grupo más pequeño significaba que los pasajes que de verdad respondían la pregunta no quedaban enterrados bajo coincidencias más débiles.

La parte contraintuitiva: combinar la mejor configuración de cada categoría por separado empeoraba las cosas en lugar de mejorarlas. El mejor equilibrio entre palabras clave y significado rompió por sí solo una pregunta de comparación. El mejor tamaño de grupo no tocó esa misma pregunta por sí solo. Juntos, ambos hicieron daño. Cada cambio que conservamos se probó contra la suite completa antes de salir a producción.

Asegurarse de que las respuestas no se alejen de la evidencia

Comprobar que cada cita apunta de verdad a un pasaje real recuperado fue la primera salvaguarda. Necesaria, pero no suficiente por sí sola. Una respuesta puede citar pasajes reales y aun así afirmar algo que esos pasajes no dicen.

Por eso un segundo modelo de IA revisa el trabajo del primero. Después de cada respuesta, relee la respuesta contra sus pasajes citados y marca cualquier frase que vaya más allá de lo que la evidencia afirma realmente. La primera ejecución de esta comprobación detectó dos problemas que la comprobación de citas había pasado por alto.

Una respuesta sobre Apple, Cisco e IBM incluía una frase que sonaba razonable pero no estaba en ningún pasaje citado. Era una pequeña inferencia que el modelo había sacado, no algo que dijera ningún informe. Una respuesta comparativa recuperó pasajes de Tesla y Rivian pero generó una respuesta que solo hablaba de Rivian, dejando caer en silencio la mitad de la comparación.

Dos correcciones: la herramienta ahora le dice al modelo exactamente qué citas son válidas para usar, para que deje de inventar números de cita que no apuntan a nada real. Y cuando nada de lo que el modelo escribe pasa la comprobación de precisión, la respuesta alternativa ahora muestra 5 pasajes en bruto en lugar de 3, para que ambos lados de una comparación sigan apareciendo incluso en la alternativa.

Esas dos correcciones subieron la tasa de aprobación de la comprobación de precisión de 8 de cada 10 a un 10 de cada 10 limpio.

Tres cosas que se rompieron

La evaluación estaba midiendo lo equivocado

Tres semanas después, ejecutamos la suite y obtuvimos una tasa de aprobación que parecía saludable. Luego miramos qué significaba realmente «aprobar» para una categoría de casos.

Varias preguntas tenían expectativas de listas fijas de empresas escritas cuando el corpus tenía un puñado de empresas. Contra 400 empresas, una buena respuesta a «¿qué direcciones mencionaron presión en la cadena de suministro en llamadas de resultados recientes?» saca 30 o 40 empresas distintas. La prueba de tres empresas que habíamos escrito estaba mal, no la herramienta. Estábamos marcando respuestas correctas como fallos y obteniendo una tasa de aprobación que parecía saludable por la razón equivocada.

Arreglar esas pruebas tomó medio día. Lo mismo volvió a pasar dos semanas después, una vez que se añadieron más empresas extranjeras. Las preguntas de prueba necesitan mantenimiento continuo. Escribirlas una vez y olvidarlas no funciona.

La detección de empresas se rompió tras una actualización del corpus

El día después de añadir 28 empresas nuevas al corpus, la herramienta empezó a no detectar algunas de ellas en sus resultados. No a menudo. Pero lo bastante a menudo como para importar.

Dos de las empresas nuevas tenían palabras de nombre que deberían haberse excluido del emparejamiento, la misma regla de «aparece en el nombre de más de una empresa» del error del ticker anterior. Pero esa lista de exclusión se había construido a mano al principio y nunca se volvió a comprobar cuando se añadieron empresas nuevas. Se había quedado desactualizada.

La solución: cada vez que se añade una empresa nueva, el sistema comprueba automáticamente su nombre contra la lista de emparejamiento existente, marca cualquier conflicto antes de que la empresa entre en producción y escribe un resumen sencillo de con qué coincidirá. Alguien puede revisar ese resumen sin leer código. Esta comprobación ahora se ejecuta en cada actualización, no solo la primera vez.

El límite del «no hay datos» se movió durante el desarrollo

La herramienta tiene una regla integrada para las preguntas que no puede responder de verdad. Si la evidencia que encuentra es demasiado escasa para respaldar una respuesta real, dice «no se encontraron datos» en lugar de adivinar. Este era un requisito central desde el primer día. El equipo ya había sufrido una vez por respuestas que sonaban seguras y estaban mal.

Pero mientras el corpus aún se estaba construyendo, algunas empresas solo tenían dos o tres informes indexados hasta ese momento. Las preguntas sobre esas empresas a veces superaban el listón de «suficiente evidencia» por una cuestión técnica y producían respuestas técnicamente fundamentadas pero demasiado escasas para ser útiles. Un asociado no podía saber si una respuesta débil significaba que la herramienta tenía un problema real o solo que los informes de esa empresa aún no estaban cargados del todo.

Añadimos un indicador de cobertura: cuando la empresa consultada tiene menos de cinco documentos indexados, la respuesta incluye una nota de que la cobertura es limitada. «El sistema no puede responder a esto» y «el corpus aún no tiene suficiente» son situaciones distintas con respuestas distintas: la segunda tiene una vía de resolución.

Los resultados a los 60 días

El equipo de Emerald empezó a usar la herramienta desde la primera semana después del lanzamiento. El feedback cualitativo ha sido constante: la herramienta eliminó el cuello de botella, no el pensamiento. Encontrar lo que Nvidia dijo sobre inversión en capacidad en sus últimas cuatro llamadas de resultados toma 10 minutos y devuelve los pasajes exactos con enlaces a las fuentes. Lo que eso significa para la tesis de inversión sigue siendo trabajo del asociado y sigue tomando el tiempo que necesite.

10 min

Preparación del comité de inversión

Un informe de investigación que antes tomaba de 2 a 3 días ahora se prepara la misma mañana de la reunión.

12–15

Nuevas posiciones evaluadas por trimestre

Antes eran de 4 a 5. El mismo equipo de tres personas.

50+

Consultas por semana

Sobre todo comparaciones entre empresas y análisis histórico del tono: las preguntas que la lectura manual no podía responder en absoluto.

0

Errores de cita desde el lanzamiento

Cada [1] se ha verificado contra la fuente original. La puerta de fidelidad se ejecuta en cada respuesta.

El cambio más grande no fue la velocidad en consultas individuales. Fue qué preguntas se molesta el equipo en hacer. Algo como «¿cómo ha descrito esta dirección su filosofía de asignación de capital en los últimos cinco años, y el lenguaje se ha vuelto más o menos específico?» antes era una semana de trabajo, así que nadie la hacía. Ahora toma 15 minutos, así que la hacen.

Aquí tenía sentido lo a medida; una plataforma, no

Para equipos con conjuntos de documentos pequeños y necesidades de investigación ocasionales, una herramienta de IA de propósito general (o incluso un espacio de NotebookLM bien mantenido) probablemente sea suficiente. Este proyecto tenía sentido para Emerald por tres razones concretas.

Primero, el corpus es demasiado grande y cambia con demasiada frecuencia para cualquier herramienta que solo funcione una sesión a la vez. 2.200 documentos en la entrega, y creciendo cada semana según se presentan nuevos informes anuales y transcripciones. Subir documentos de nuevo en cada sesión no puede seguir ese ritmo.

Segundo, la integridad de las citas no es negociable. Las decisiones de inversión (incluso las internas) dependen de poder verificar la fuente de cada afirmación. La puerta de fidelidad y los enlaces profundos a los informes originales no son extras. Son el producto.

Tercero, la sensibilidad de los datos. La actividad de investigación de una oficina de inversión (qué estudian, qué empresas están sondeando, qué preguntas hacen sobre la credibilidad de la dirección o la disciplina de capital) es señal propietaria. Que eso pase por una plataforma de IA de terceros crea una exposición que no estaban dispuestos a aceptar. Cada consulta permanece dentro de su entorno.

Qué haríamos distinto

Empezaríamos la suite de pruebas en la semana 1, no en la 4. El error del ticker se habría detectado en la primera semana en lugar de tres semanas después. La ralentización de los 40 segundos habría sido evidente desde el primer día, porque «¿por qué una pregunta amplia sigue devolviendo resultados de la misma empresa?» es exactamente el tipo de pregunta que una suite de pruebas está pensada para hacer, no algo en lo que se tropieza por accidente más tarde. Construimos la suite de pruebas como una herramienta de desarrollo y solo descubrimos su valor real por lo que atrapó en el camino. Deberíamos haber sabido para qué servía antes de necesitarla.

También seríamos más agresivos con la composición del corpus en la semana 1. Emerald tenía una idea clara de qué empresas importaban, pero ninguna definición escrita de cuál era el universo de cobertura real de la herramienta. Algunas empresas estaban en la lista de seguimiento por razones claras. Otras estaban incluidas por razones históricas que nadie podía reconstruir. Volver a pasar una empresa por el pipeline solo la actualiza en lugar de crear un duplicado, así que cuanto antes se fije la lista de empresas, antes se estabiliza el emparejamiento de nombres y las preguntas de prueba siguen siendo válidas.

Tercero, pondríamos una versión de solo lectura delante de un asociado en la semana 4 en lugar de la 7. Nuestras propias pruebas detectan errores de lógica. Las preguntas de investigación reales detectan todo lo demás: nombres de empresas que no habíamos contemplado, transcripciones de llamadas de resultados que se dividieron de forma extraña, preguntas formuladas como los asociados realmente hablan en lugar de como imaginábamos que hablarían. Una persona ejecutando una semana de preguntas reales nos enseñó más que otras 20 preguntas que escribimos nosotros.

Empieza la suite de evaluación el primer día, cierra el corpus antes de ajustar nada y pon a un usuario real delante de una versión funcional lo antes posible. La construcción se vuelve más fácil cuando sabes qué estás midiendo de verdad. Todo lo anterior es adivinar con formación.