Taxbit lanza un asistente de IA para profesionales fiscales: el 55% de los usuarios vuelve con otra pregunta

Si alguna vez ha creado un chatbot de soporte, ya sabe como suele funcionar. El bot responde con seguridad, cita una fuente poco clara y, despues, envia al usuario a una pagina a la que no tiene acceso. En el ambito fiscal, un error asi sale caro: las personas toman decisiones sobre la presentacion de sus declaraciones. El equipo de Taxbit, una plataforma de cumplimiento fiscal para bolsas de criptoactivos y brokers, explico como construyo Assist, un asistente en el que se puede confiar dentro de un entorno regulado.

Los requisitos que definieron la arquitectura

El asistente tiene cuatro restricciones estrictas. Cada respuesta debe citar una fuente que el usuario pueda abrir y, si no existe una respuesta, el bot debe decirlo. El bot tiene en cuenta el rol y la organizacion del usuario: no puede enviar a un empleado de soporte a un flujo de administracion. Tampoco ofrece asesoramiento fiscal: puede explicar como calcula Taxbit la base de coste, pero no recomendar que metodo elegir. Por ultimo, los datos deben permanecer dentro de su region correspondiente.

El agente funciona con Strands Agents SDK dentro de AgentCore Runtime. Es una pequena aplicacion en Python compuesta por un prompt de sistema, un modelo y ocho herramientas de alcance limitado. Entre ellas se incluyen la busqueda en la base de conocimiento, dos comprobaciones de acceso y cuatro herramientas para trabajar con tickets de soporte. El agente no tiene ningun acceso a los datos fiscales de los clientes.

La decision de seguridad fundamental es que el modelo no trabaja con la identidad. El correo electronico, el ID de la organizacion y el rol llegan desde un servicio de confianza y se incorporan a las herramientas mediante un cierre. El modelo puede decidir si debe comprobar los permisos, pero no puede elegir los permisos de quien se comprobaran. La entrada del usuario se sanea, de modo que una inyeccion de prompt no pueda falsificar el contexto de confianza.

De donde procedieron realmente las mayores mejoras de calidad

El equipo dedico la mayor parte de sus esfuerzos a la base de conocimiento: Amazon Bedrock Knowledge Bases sobre S3 Vectors, con embeddings de Cohere Embed English v3. Utiliza tres fuentes: el sitio publico de documentacion y el centro de ayuda, documentacion generada a partir del codigo fuente del producto y articulos redactados manualmente.

La primera mejora inesperada llego al limpiar el corpus. El sitemap contenia alrededor de 400 URL, pero solo unas 70 servian para responder preguntas. Mas de 300 paginas de /blogs/ eran contenido de marketing y competian con el centro de ayuda como fuentes para las respuestas sobre cumplimiento normativo. Excluir el blog llevo unos minutos y no exigio ningun cambio en el modelo.

La segunda mejora, y la mas potente, procedio de la fragmentacion contextual. Un fragmento extraido de la mitad de un documento pierde la informacion sobre aquello a lo que se refiere. Es peligroso devolver un parrafo sobre las reglas aplicables a regimenes de informacion no estadounidenses como respuesta a una pregunta sobre el formulario 1099 del IRS.

Por eso, una funcion Lambda en la etapa POST_CHUNKING anade al principio de cada fragmento el encabezado H1 del documento y un parrafo introductorio de unos 128 tokens. El cuerpo del fragmento se limito a 384 tokens para que todo cupiera en la ventana de 512 tokens del modelo de embeddings. Una comprobacion en produccion mostro que cerca del 28% de los fragmentos se situaba en el intervalo de 385 a 512 tokens, por lo que sus partes finales se habrian truncado de forma silenciosa.

La busqueda funciona como un embudo: 75 candidatos del indice vectorial, reranking con Cohere Rerank 3.5 dentro de la misma llamada Retrieve, los 12 mejores resultados, un maximo de dos fragmentos por documento y los cinco mejores fragmentos enviados al modelo. La amplia seleccion inicial es necesaria porque los articulos adecuados suelen aparecer entre los puestos 20 y 50 de los resultados vectoriales y solo ascienden despues del reranking. Solo se pueden citar fuentes publicas, y esta regla se aplica en el codigo, no en el prompt.

Seguridad y control de calidad

Bedrock Guardrails comprueba cada mensaje entrante mediante una llamada independiente a ApplyGuardrail que analiza unicamente el turno actual. Las contrasenas, los codigos CVV y las claves de servicios en la nube se bloquean. Los SSN, ITIN, datos bancarios e IBAN se enmascaran en el mismo lugar, por lo que el agente puede ayudar con el proceso sin ver los valores. Para el historial de la conversacion, es esencial que el ID del actor proceda del servicio que realiza la llamada: el runtime funciona con un unico rol de servicio y, de lo contrario, el historial de todos los usuarios acabaria en una sola particion.

La calidad se mide sobre trafico real sin bloquear las respuestas. Las evaluaciones en linea de AgentCore toman una muestra del 10% de las sesiones y las valoran mediante seis jueces LLM integrados: utilidad, nocividad, coherencia, seguimiento de instrucciones, seleccion de herramientas y precision de los parametros de esas herramientas. Ademas, se ejecutan jueces propios que evaluan por separado la fidelidad a las fuentes y la relevancia del material recuperado. La separacion es deliberada: una respuesta puede ser fiel a unas fuentes que nunca deberian haberse recuperado y, en ese caso, el culpable no es el modelo, sino el sistema de busqueda. Un clasificador independiente vigila que las respuestas no deriven hacia el asesoramiento fiscal.

Principales conclusiones

Primero: limpie el corpus antes de ajustar el modelo. Las paginas de marketing incluidas en el indice pueden estropear las respuestas mas de lo que cualquier prompt puede corregir. Segundo: si un fragmento no sabe a que pertenece, anada un encabezado y su ambito de aplicacion. Tercero: mantenga todo lo relacionado con permisos e identidad fuera del espacio de decision del modelo. Cuarto: separe las metricas de recuperacion y generacion; de lo contrario, acabara corrigiendo el componente equivocado.

Tambien hay que tener en cuenta las limitaciones. La cifra del 55% de preguntas repetidas procede de las analiticas internas de Taxbit y mide la participacion, no la precision. La solucion esta estrechamente vinculada al stack de AWS. Por ahora, el agente no lee ningun dato de los clientes, por lo que no puede responder a preguntas como «¿Por que se obtuvo asi mi calculo?». Aun asi, como modelo para un asistente de IA en cualquier sector regulado —ya sean las finanzas, la medicina o el derecho—, el caso resulta muy practico.