Detectar texto de LLM sin otro LLM

Si trabajas con contenido generado por modelos de lenguaje, seguro ya viste el problema: necesitas distinguir entre texto humano y texto sintético, pero no siempre quieres meter otro LLM en el pipeline para que haga de juez. Eso encarece, agrega latencia y, en muchos casos, te deja con una caja negra difícil de auditar.

El enfoque de este artículo es distinto: usar machine learning “clásico” para detectar texto generado por LLM. No hablamos de magia ni de un detector perfecto. Hablamos de un sistema práctico, entrenable, más barato de operar y bastante más fácil de explicar a un equipo de moderación, fraude o QA.

Por qué no usar otro LLM como detector

La opción más obvia para detectar texto sintético es pedirle a otro LLM que lo clasifique. Suena cómodo, pero en producción suele traer tres problemas: costo, latencia y consistencia. Si tu flujo procesa miles de textos por hora, sumar una llamada extra a un modelo grande puede duplicar el tiempo de respuesta o disparar la factura.

Además, un LLM como detector no siempre responde igual ante entradas parecidas. Si cambias el prompt, el idioma o el formato del texto, la salida puede moverse bastante. Para un equipo de control de calidad eso es incómodo; para fraude o moderación, puede ser un dolor serio porque necesitas reglas estables y trazables.

El enfoque clásico no intenta “entender” el texto como lo haría un chat model. En cambio, extrae señales estadísticas y de estilo, y luego entrena un clasificador tradicional. Eso te permite medir qué variables pesan más, ajustar umbrales y revisar errores con más claridad.

Qué gana un equipo con este enfoque

La primera ganancia es operativa. Un modelo como logistic regression, random forest o XGBoost puede correr rápido en CPU, sin GPU, y con una huella de infraestructura mucho menor. Si tu plataforma está en AWS, GCP o Azure, eso se traduce en menos complejidad de despliegue.

La segunda ganancia es de control. Puedes versionar tus features, guardar datasets de entrenamiento y explicar por qué un texto cayó en la clase “sintético”. Eso ayuda cuando un analista pregunta por qué un comentario fue marcado como sospechoso o por qué un ticket de soporte fue escalado.

La tercera ganancia es de mantenimiento. Si mañana cambian los modelos que usan tus usuarios, no necesitas reescribir todo el sistema. Puedes reentrenar con nuevos ejemplos y comparar métricas de forma simple.

Qué señales funcionan mejor en texto sintético

Cuando detectas texto generado por LLM, no buscas una sola pista. Buscas un conjunto de señales que, combinadas, separen bastante bien el texto humano del sintético. El artículo original de referencia muestra que con features “clásicas” se puede lograr un desempeño competitivo, especialmente si el dataset está bien armado.

Las señales más útiles suelen caer en cuatro grupos: longitud y estructura, distribución de palabras, patrones de puntuación y medidas de perplejidad o rareza estadística. No necesitas usar todas desde el día uno, pero sí conviene probar varias y medir su aporte real.

Una ventaja de este enfoque es que no depende de que el detector “entienda” semánticamente el contenido. Le basta con notar que el texto tiene una cadencia demasiado uniforme, repite estructuras previsibles o usa un vocabulario menos variable que el de un humano.

Features que sí vale la pena probar

Aquí tienes un resumen práctico de variables que suelen aportar valor:

No todas las features pesan igual en todos los casos. En español, por ejemplo, la longitud de oración puede variar mucho según el tipo de contenido: un artículo técnico no se comporta como un comentario de WhatsApp. Por eso conviene entrenar con datos cercanos a tu caso real.

Si trabajas en Latinoamérica, también importa el dominio. Un texto de soporte al cliente en Ecuador no se parece a un post corporativo en México ni a una reseña de e-commerce en Colombia. La señal existe, pero el contexto cambia bastante el umbral de decisión.

Cómo montar el pipeline sin complicarte

La idea no es construir un laboratorio académico. La idea es tener un flujo que puedas operar, medir y ajustar. Para eso, un pipeline simple suele bastar: recolectas ejemplos, etiquetas, extraes features, entrenas un clasificador y validas con un set aparte.

En un caso real, el dataset debería mezclar texto humano y texto generado por varios modelos, no solo uno. Si entrenas con un solo LLM, corres el riesgo de aprender su estilo particular y no la categoría general de “texto sintético”.

También necesitas ejemplos del mismo dominio donde vas a desplegar. Detectar texto de soporte técnico, reseñas o descripciones de producto no es igual que detectar ensayos académicos. El dominio cambia el vocabulario, la longitud y la estructura.

Flujo recomendado paso a paso

1. Reúne texto humano del dominio objetivo: por ejemplo, 20 mil tickets, 15 mil respuestas de chat o 10 mil reseñas.
2. Genera texto sintético con varios prompts y varios modelos, no solo uno.
3. Limpia y normaliza: elimina HTML, espacios raros y duplicados exactos.
4. Extrae features con reglas reproducibles en Python o TypeScript.
5. Divide en train, validation y test, idealmente 70/15/15.
6. Entrena un clasificador base y compáralo contra otro más fuerte.
7. Mide precision, recall, F1 y false positive rate por dominio.
8. Ajusta umbrales según el costo del error en tu negocio.

Si tu caso es moderación, quizá te importe más el recall para no dejar pasar texto sintético no deseado. Si es fraude, tal vez te preocupe más el false positive rate porque no quieres bloquear usuarios legítimos. En QA, en cambio, te conviene un balance que no castigue demasiado al equipo con falsos alarmas.

Ejemplo mínimo en Python

No necesitas una infraestructura rara para empezar. Con scikit-learn puedes montar un baseline decente y medir rápido si el problema es viable en tu contexto.

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import Pipeline
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

texts = ["texto humano 1", "texto sintético 1", "texto humano 2", "texto sintético 2"]
labels = [0, 1, 0, 1]

X_train, X_test, y_train, y_test = train_test_split(texts, labels, test_size=0.25, random_state=42)

model = Pipeline([
    ("tfidf", TfidfVectorizer(ngram_range=(1, 2), max_features=5000)),
    ("clf", LogisticRegression(max_iter=1000))
])

model.fit(X_train, y_train)
preds = model.predict(X_test)
print(classification_report(y_test, preds))

Ese ejemplo es básico a propósito. En producción, normalmente querrás sumar features manuales, calibrar probabilidades y evaluar por segmentos. Pero como punto de partida sirve para validar si tu data tiene señal.

Qué modelos clásicos suelen rendir mejor

No hay una respuesta universal, pero sí hay patrones bastante claros. Para features tabulares, logistic regression y XGBoost suelen ser buenos primeros candidatos. Si tu feature set es pequeño y bien diseñado, logistic regression te da una línea base sólida y fácil de explicar.

Random forest también puede funcionar, aunque a veces pierde frente a boosting cuando las señales son sutiles. Si trabajas con features densas y mezcladas, XGBoost o LightGBM suelen capturar interacciones mejor. Si tu equipo ya usa scikit-learn, vale la pena empezar por ahí antes de complicarte.

Para texto crudo, TF-IDF con n-grams sigue siendo un baseline fuerte. No necesitas embeddings de un LLM para empezar. De hecho, en varios escenarios el TF-IDF combinado con un clasificador lineal compite bastante bien, sobre todo cuando el dominio está acotado.

Comparación práctica de opciones

La decisión no debería basarse solo en accuracy. Si tu dataset está desbalanceado, una accuracy alta puede esconder que el modelo falla en la clase que te importa. Mira precision, recall y matriz de confusión, no solo un número grande.

También conviene revisar calibración. Un score de 0.92 debería significar algo parecido en distintos lotes, no solo en el test inicial. Si el score no está bien calibrado, tu umbral de decisión se vuelve inestable y eso complica la operación.

Riesgos, límites y cómo reducir falsos positivos

Ningún detector de texto generado por LLM va a ser perfecto. Si el texto humano es muy formal, muy breve o muy templado, el modelo puede confundirlo con salida sintética. Esto pasa mucho con textos corporativos, respuestas de soporte y contenido legal.

También ocurre lo contrario: un LLM muy bien guiado puede imitar bien el estilo humano y esconder patrones típicos. Por eso no conviene vender este tipo de sistema como una verdad absoluta. Lo correcto es tratarlo como una señal más dentro de un flujo de revisión.

Para reducir falsos positivos, te conviene trabajar con umbrales por caso de uso. No uses el mismo punto de corte para moderación automática que para una revisión manual asistida. Y si la decisión tiene impacto directo en usuarios, agrega una capa de revisión humana en los casos dudosos.

Buenas prácticas que sí ayudan

• Entrena con texto de varias fuentes y varios modelos generadores.
• Separa por dominio y por idioma si tu producto atiende varios mercados.
• Revisa errores por longitud: los textos cortos suelen ser más difíciles.
• Guarda ejemplos de falsos positivos y falsos negativos para reentrenar.
• Monitorea drift mensual, no solo al lanzar el modelo.
• Usa umbrales distintos según el costo del error.

Si tu equipo opera en Latinoamérica, además conviene considerar variación regional. El español de Chile, Perú o Ecuador puede cambiar en léxico y sintaxis, y eso afecta tanto el entrenamiento como la evaluación. Un detector que funciona bien en un corpus de España no necesariamente se comporta igual en tu data local.

Cómo lo aplicaría en moderación, fraude y QA

En moderación, el objetivo no es solo detectar texto sintético, sino priorizar revisión. Puedes usar el score para mandar a cola manual los casos con mayor probabilidad de ser generados, sobre todo cuando el contenido automatizado viola políticas de spam, reseñas falsas o manipulación de reputación.

En fraude, el uso es más delicado. Un texto sintético puede aparecer en formularios, reclamaciones o respuestas automatizadas que intentan simular actividad humana. Aquí el detector sirve como una señal adicional junto con reputación, comportamiento y metadatos de sesión.

En control de calidad, el caso más común es revisar si un equipo está usando LLMs donde no debería, o si el contenido entregado al usuario final cumple estándares de naturalidad. Por ejemplo, una marca puede querer detectar respuestas demasiado genéricas en soporte o descripciones de producto que suenan copiadas.

La ventaja del enfoque clásico es que puedes integrarlo como un servicio pequeño. Un endpoint recibe el texto, calcula features, devuelve score y decisión. No necesitas depender de un modelo grande para cada consulta, y eso simplifica mucho la observabilidad.

Cómo medir si realmente te sirve

Antes de ponerlo en producción, define métricas ligadas al negocio:

• Precision: qué porcentaje de lo marcado como sintético realmente lo es.
• Recall: qué tanto texto sintético logras atrapar.
• False positive rate: cuántos textos humanos marcas por error.
• Latencia p95: cuánto tarda el sistema en el peor tramo normal.
• Costo por mil textos: cuánto te cuesta operar el detector.

Si el detector reduce la carga manual en 30% pero dispara falsos positivos, quizá no te conviene. Si baja la revisión manual y mantiene un error controlado, ya tienes una pieza útil para el stack.

Para equipos que trabajan con alto volumen, la latencia importa tanto como la precisión. Un modelo clásico puede correr en milisegundos o decenas de milisegundos en CPU, mientras que un LLM como juez suele ser bastante más pesado. Según la documentación oficial de scikit-learn, muchos modelos lineales y de árboles están pensados para flujos de entrenamiento y predicción eficientes en CPU, lo que encaja bien con este caso: scikit-learn.

También vale la pena revisar la documentación de XGBoost si quieres un clasificador fuerte para features tabulares: XGBoost. Y si vas a preparar texto en Python, spaCy sigue siendo una opción sólida para normalización y tokenización: spaCy.

Tabla resumen

Detectar texto generado por LLM sin usar otro LLM no es una idea de laboratorio; es una decisión de arquitectura. Si tu equipo necesita moderar contenido, reducir fraude o revisar calidad sin sumar costo y complejidad, este enfoque te da una base más simple de operar.

La clave está en no obsesionarte con una sola feature ni con un solo modelo. Empieza con un baseline, mide por dominio, guarda errores y ajusta umbrales. Si haces eso, vas a tener un detector útil, auditable y bastante más barato de mantener que una cadena de prompts sobre otro modelo grande.