Como los agentes de QA amplian por si solos la base de conocimiento y reducen de 2 horas a 10 minutos la busqueda de la causa de un bug

Imagine que un profesional de QA dedica dos horas a averiguar por que el escaparate para recogida en tienda esta vacio. Al final, no se trata de un bug. La cache de disponibilidad se actualiza cada pocos minutos y un mock de existencias estaba anulando el proxy real debido a una prioridad incorrecta. El conocimiento se obtiene, pero queda en la cabeza de una sola persona o en un chat que nadie encontrara una semana despues. Un mes mas tarde, otro profesional de QA invierte las mismas dos horas en lo mismo. Un agente de IA, por su parte, carece por completo de memoria entre sesiones, por lo que repite ese recorrido cada vez.

El equipo de pruebas de Techville resolvio el problema con una plataforma independiente llamada MKP, o Multi Knowledge Platform. A continuacion analizamos como funciona y que pueden aprovechar de ella otros equipos.

Que es MKP y como realiza las busquedas

MKP es una plataforma interna con bases de conocimiento y busqueda inteligente. Hay dos tipos de bases: evawiki, integrada y dotada de documentacion corporativa, que MKP solo puede leer, y bases Markdown de los equipos, donde es posible crear, actualizar, eliminar y buscar documentos por significado. Se puede trabajar mediante una interfaz web, una API REST o un servidor MCP para agentes de Cursor, Claude Code y Codex. MCP dispone de solo cinco herramientas: listar las bases, hacer una consulta semantica, obtener un documento por numero, crear o actualizar y realizar un borrado logico.

Por debajo utiliza RAG, aunque no en su version mas ingenua. La recuperacion hibrida dense/sparse combina la busqueda semantica con la busqueda por palabras clave. Esto es critico para QA: la busqueda puramente vectorial tiende a perder identificadores como GetExists, is_pickup o CMA-14699. Despues se aplican multi-query, donde el modelo reformula la pregunta, reranking y recuperacion parent-child: se buscan fragmentos pequenos, pero se entrega el contexto de toda la seccion. La respuesta siempre incluye el texto, las fuentes con score y snippet, ademas de un trace_id para diagnostico.

El agente escribe por si mismo en la base

La idea principal es que nadie incorpora documentos manualmente; de lo contrario, seis meses despues solo habria otra wiki abandonada. En su lugar, MKP esta integrada en el kit de QA, un repositorio con reglas y skills para Cursor y Claude Code. El agente actua como editor: selecciona el conocimiento verificado de la sesion en vez de volcar todo el dialogo en la base.

Para cada dominio, como catalogo, busqueda o recomendaciones, se han creado cuatro bases:

• wiki — conocimiento duradero: arquitectura, entornos, mocks y como realizar correctamente las comprobaciones;
• outputs — textos completos de planes de prueba, resultados y comentarios para Tracker;
• daily — registros diarios y un indice a modo de tabla de contenidos;
• artifacts — evidencias sin procesar: curl, SQL, JSON y mocks.

Antes de mostrar un plan de pruebas, el agente debe realizar cuatro busquedas: si hubo una nueva prueba para los numeros exactos de los documentos, que se detecto en casos similares dentro de outputs, que sabe el equipo sobre el servicio en wiki y que dice el producto en eva-wiki. Despues de las pruebas, registra el plan, el resultado y el comentario en outputs, la jornada en daily y cualquier nuevo dato duradero en wiki.

Que aporta en la practica

Para un escaparate vacio, una consulta a catalog-wiki devuelve ahora en 24 segundos una lista de nueve puntos. Incluye la cache de disponibilidad, los pedidos anticipados, la prioridad del mock en WireMock y un error 403 del proxy de busqueda. Un profesional de QA la completa en diez minutos en lugar de dos horas. Nadie redacto esta lista como un articulo: se construyo a partir de analisis de tareas en los que el agente fue agregando los datos uno a uno.

En una tarea sobre productos analogos, el agente recupera de antemano los resultados de dos ejecuciones anteriores. Un nuevo profesional de QA sabe que fixtures debe preparar, evita abrir un DEFECT falso para una ruta legacy inaccesible que un companero ya marco como QUESTION y anade de inmediato una comprobacion para saber si hay codigo antiguo sin filtro en el entorno. Al consultar el indice de daily, el responsable puede ver que hizo el equipo sin celebrar una reunion de seguimiento independiente.

Permisos y disciplina

El acceso esta organizado de forma estricta. Hay dos roles, admin y user, mientras que los permisos read y write se conceden por separado para cada base. Para cada agente se crea un usuario independiente con privilegios minimos, y se puede impedir que un usuario tecnico acceda a la UI. El agente lee las bases de su dominio y eva-wiki, pero solo escribe en sus cuatro bases. El autor del documento se identifica por la clave de API y el equipo aparece en los metadatos. El registro de accesos se almacena en git.

Limitaciones y conclusion

El articulo no evalua la calidad de los registros ni explica como se filtra el conocimiento erroneo que un agente haya incorporado a la wiki. Las cifras de ahorro de tiempo son internas y se basan en ejemplos concretos. Ademas, un documento nuevo no aparece inmediatamente en las busquedas: primero pasa por el estado processing.

La conclusion practica para los equipos que trabajan con agentes es que no necesitan otra wiki, sino un ciclo de "recordar, trabajar, registrar". La configuracion minima consiste en separar el conocimiento duradero de los resultados de las ejecuciones, obligar al agente a buscar antes de trabajar, concederle permisos limitados y almacenar las fuentes junto a la respuesta. Asi, cada tarea abarata la siguiente.