En investigación de mercado, las preguntas abiertas son un arma de doble filo: capturan una riqueza y una especificidad deseable pero cuantificarlas es siempre un desafío por la ambigüedad, la variedad semántica y los errores ortográficos que traen. En Moiguer desarrollamos nuestra propia solución in-house para este problema de antaño en encuestas de opinión desarrollando nuestro propio software de codificación de preguntas abiertas.
Para convertir texto libre en datos existe un proceso que se llama codificación. Alguien lee todas las respuestas, agrupa las que dicen lo mismo, asigna un número a cada grupo y reemplaza el texto por ese número en la base. “Hellmanns”, “Jelman” y “hellmans” terminan bajo un mismo código, el que corresponde a Hellmann’s.
Es un trabajo tedioso, repetitivo y propenso a errores de consistencia. Cuando se trata de miles de respuestas a múltiples preguntas, para varios proyectos corriendo en paralelo, además es caro e ineficiente. Ese fue el punto de partida.
El objetivo era aumentar la eficiencia (de recursos y tiempo), sin perder efectividad (hablo de la fidelidad del resultado final) y de ser posible, incrementarla.
Dos problemas, no uno
Toda pregunta abierta cae en una de dos situaciones, y cada una exige una lógica distinta.
Cuando ya existe un libro de códigos. En estudios longitudinales, paneles o proyectos con múltiples olas, las categorías se definieron en una medición anterior. Hay un archivo (el libro de códigos) con una lista de claves numéricas y los valores que les corresponden. La tarea es imputar: tomar cada respuesta nueva y mapearla a la clave correcta. El desafío central es la variabilidad ortográfica: “Cocca-cola”, “coca cola” y “CocaCola” refieren a la misma clave.
Cuando no existe ningún libro de códigos. En estudios nuevos, o en preguntas que nunca se hicieron, hay que codificar las categorías desde cero. El analista no sabe de antemano qué va a encontrar, puede intuirlo, pero si quiere predefinir el libro de códigos incurre en el riesgo de introducir su sesgo por encima de lo que dicen los encuestados. Primero hay que descubrir qué categorías emergen de los datos, después asignar cada respuesta a una, y finalmente producir un libro de códigos reutilizable para las próximas olas.
Los dos flujos comparten infraestructura pero resuelven cosas diferentes. La distinción no es menor: la imputación sigue una pauta que ya existe, mientras que la codificación lo fabrica.
Proyectos múltiples y respuestas múltiples
La herramienta no se pensó para un único estudio. El menú inicial lista todos los proyectos de una carpeta central, y cada uno tiene su propia estructura: los datos de entrada, el libro de códigos, las variaciones aprendidas y los resultados con sus checkpoints. Los subproyectos se detectan de forma automática, y cuando los archivos siguen un patrón de olas la herramienta pregunta qué ola procesar. Cada proyecto puede tener además sus propios códigos especiales.
No importa qué tan claramente se redacte una pregunta, mientras las preguntas sigan siendo respondidas por personas con agencia propia seguirá existiendo la libre interpretación de las preguntas (y esperemos que así siga siendo), lo que hace que muchas veces el usuario responda con más de un factor en su respuesta. Por ejemplo, ante la pregunta “¿Qué es lo que te resulta más atractivo de este producto?”, el encuestado puede responder: “Me gusta su presentación y la variedad que ofrece”. Ideamos una lógica para captar ambas dimensiones, presentación y variedad, diferenciando entre top of mind o driver principal y secundarios.
El flujo de imputación
Cuando el libro de códigos ya existe, entra como insumo de solo lectura. El objetivo es una única salida: la base codificada.
El sistema resuelve primero lo barato: los valores ya vistos salen de una caché y las respuestas especiales (vacíos, “no sé”, “ninguno”) se asignan por reglas de procesamiento de lenguaje natural, sin llamar a ningún LLM. Solo el resto va a un modelo, que clasifica en lotes con alta tolerancia a errores de tipeo. Lo que quedó en “otros” pasa por una segunda vuelta más exigente antes de la revisión humana.
Ese trabajo del modelo deja un residuo valioso. Cada vez que mapea una variación nueva (“cocca-cola” a Coca-Cola), la relación se guarda. En la corrida siguiente esas variaciones conocidas ya no necesitan al modelo: se resuelven en la pre-clasificación. Con el transcurrir de las iteraciones, el sistema depende cada vez menos del LLM.
El flujo de codificación
Cuando no hay libro de códigos, el trabajo es más ambicioso y tiene dos salidas: la base codificada y un libro nuevo. Ese libro es lo que convierte la próxima ola en un problema de imputación.
La separación en dos pasos es deliberada. Hecho todo junto, el modelo tiende a crear demasiadas categorías específicas o a agrupar de forma inconsistente entre lotes. Al fijar primero la lista de categorías, la asignación posterior trabaja sobre un espacio de respuesta constante y produce clasificaciones coherentes. Entre un paso y otro, el analista corrige la lista: agrega, borra, renombra o fusiona categorías.
Las frecuencias como señal de calidad
Un modelo, por sí solo, no siempre detecta bien qué merece categoría propia. Entre 500 respuestas distintas, la marca A puede aparecer cinco veces de 5 formas diferentes. Cada una parece un caso raro; juntas son una categoría relevante.
La solución fue pasar las frecuencias normalizadas junto con los valores. Antes de armar el pedido, se normaliza todo el texto (minúsculas, sin acentos, sin puntuación), se cuenta cuántas veces aparece cada término y los más frecuentes van al modelo.
La interactividad no es un defecto, es el producto
La automatización total nunca fue el objetivo. Logramos una herramienta eficaz y eficiente que facilita la actividad del analista mientras garantiza un agrupamiento de mayor calidad.
Antes de clasificar puede editar las categorías propuestas. Después de clasificar puede revisar cada categoría y mover los valores mal asignados. Antes de guardar ve la distribución completa con frecuencias y porcentajes. El modelo elimina el trabajo mecánico; el analista aporta el criterio.
Este proyecto refleja cómo se cruzan ciencia de datos, desarrollo de software e investigación de mercado para acortar la brecha entre la voz de los usuarios y los insights que necesitan las marcas. Si te enfrentaste al mismo desafío en procesamiento de texto, me interesa saber qué enfoques te funcionaron.