Inglés para científicos de datos: términos que no se traducen

Gran parte del vocabulario de ciencia de datos —"overfitting", "feature engineering", "pipeline", "embedding"— no tiene una traducción natural al español que se use realmente en la industria; se dice en inglés incluso en equipos completamente hispanohablantes. Dominar ese inglés no es opcional para leer papers, documentar modelos con claridad o defender resultados frente a un equipo de negocio internacional.

Un fenómeno curioso de la ciencia de datos como profesión es que, aunque se practique todos los días en español, el vocabulario técnico central casi nunca se traduce. Un data scientist ecuatoriano hablando con un colega colombiano dirá "vamos a hacer feature engineering antes del split" en vez de "vamos a hacer ingeniería de características antes de la separación" — no por pretensión, sino porque la comunidad global adoptó los términos en inglés desde el origen del campo, y traducirlos suena forzado o directamente confunde. Esto crea una situación particular: el data scientist necesita un inglés técnico sólido incluso si nunca trabaja directamente con un equipo angloparlante, porque su propio idioma de trabajo diario ya está mezclado con inglés.

Por qué estos términos resisten traducción

Hay una razón estructural detrás de esto: casi toda la literatura fundacional del campo — papers académicos, documentación de librerías como scikit-learn, PyTorch o TensorFlow, cursos de referencia, foros como Stack Overflow — se publica y se discute en inglés primero. Cuando un término nuevo se populariza (piénsese en "attention mechanism" o "fine-tuning"), la comunidad hispanohablante lo adopta directamente porque ya está buscando ese término exacto en inglés para encontrar documentación, ejemplos de código y discusiones relevantes. Traducirlo rompería la búsqueda.

Vocabulario que aparece en cualquier conversación técnica de modelado

• "Overfitting" / "underfitting" — cuando un modelo memoriza el ruido de los datos de entrenamiento en vez de generalizar, o cuando es demasiado simple para capturar el patrón real.
• "Feature engineering" — el proceso de crear o transformar variables de entrada para mejorar el desempeño del modelo.
• "Train/validation/test split" — la división estándar de los datos para entrenar, ajustar hiperparámetros y evaluar de forma honesta.
• "Pipeline" — la secuencia automatizada de pasos desde datos crudos hasta predicción o entrenamiento.
• "Embedding" — una representación vectorial densa de datos (palabras, imágenes, usuarios) que captura relaciones semánticas.
• "Data leakage" — cuando información del conjunto de prueba se filtra al entrenamiento de forma no intencional, inflando artificialmente el desempeño reportado.
• "Ground truth" — la etiqueta o valor real contra el que se compara la predicción del modelo.

Leer papers: un tipo de inglés distinto al conversacional

Los papers académicos de machine learning tienen un registro muy particular: oraciones densas, voz pasiva frecuente ("the model was trained using...", "results were evaluated on..."), y una estructura fija (abstract, introduction, related work, methodology, experiments, results, discussion) que, una vez internalizada, hace que leer papers nuevos sea mucho más rápido. El error común de quien recién empieza a leer literatura técnica en inglés es intentar traducir cada oración mentalmente al español — eso multiplica el tiempo de lectura por tres o cuatro y hace perder el hilo del argumento técnico. La meta debería ser leer directamente en inglés sin pasar por el español, entendiendo la estructura del argumento (qué problema resuelven, qué método proponen, cómo lo evalúan, qué limita al método) más que cada palabra individual.

Documentar modelos: precisión que evita reprocesos

La documentación de un modelo en inglés —un README, un model card, comentarios de código— necesita ser precisa de una forma distinta a la escritura conversacional. Describir que un modelo "achieves 87% accuracy on the held-out test set" es una afirmación verificable y específica; decir que el modelo "works pretty well" no comunica nada útil a otro data scientist que tenga que retomar el proyecto meses después. La cultura de documentación técnica en inglés premia la precisión cuantificable sobre el lenguaje impresionista, algo que a veces choca con hábitos de escritura más informales en español.

• Especificar siempre la métrica exacta y el conjunto de datos sobre el que se calculó: "F1-score of 0.82 on the validation set", no solo "good performance".
• Documentar los supuestos y limitaciones explícitamente: "This model assumes stationarity in the input distribution and may degrade under concept drift."
• Usar el mismo nombre de variable/feature en el código, la documentación y las presentaciones — la inconsistencia de nombres es una de las causas más comunes de confusión al retomar un proyecto ajeno.

Presentar resultados a un equipo de negocio que no es técnico

Este es quizás el reto de inglés más subestimado del rol. Un data scientist puede dominar perfectamente el vocabulario técnico y aun así fallar al presentar resultados a un stakeholder de negocio internacional, porque ese público no quiere escuchar sobre "regularization" o "cross-validation" — quiere saber qué significa el resultado para la decisión que tiene que tomar. Traducir un hallazgo técnico a lenguaje de negocio en inglés, en tiempo real durante una reunión, exige un tipo de fluidez distinto al de leer papers: hay que poder simplificar sin perder precisión, y responder preguntas de seguimiento sin refugiarse en jerga técnica cuando no se tiene la respuesta clara.

• "This model would catch about 8 out of every 10 fraudulent transactions, but it would also flag some legitimate ones as suspicious." — traduce una matriz de confusión a lenguaje de impacto.
• "We're confident in this trend, but I'd want another two weeks of data before we act on it." — comunica incertidumbre sin sonar inseguro.
• "That's a great question — let me look into the breakdown by segment and follow up." — respuesta honesta cuando no se tiene el dato a mano, sin improvisar un número.

Code review en inglés: comentarios que no generan fricción

En equipos internacionales de ciencia de datos, el code review de notebooks y pipelines se hace en inglés escrito, y el tono de esos comentarios importa tanto como su precisión técnica. "This could leak information from the test set — worth double-checking" es constructivo; "this is wrong" sin más contexto genera fricción innecesaria en un equipo distribuido donde el tono escrito es la única señal disponible, sin el lenguaje corporal que suavizaría el mismo comentario dicho en persona.

Cómo priorizar el aprendizaje si el objetivo es un rol internacional

Para un data scientist que se está preparando para trabajar con equipos internacionales, el orden recomendado es: primero consolidar el vocabulario técnico central (que en gran parte ya se usa a diario, solo falta ordenarlo), después practicar lectura ágil de papers sin traducción mental, y por último — el que más tiempo toma desarrollar — la fluidez conversacional para presentar resultados y participar en discusiones técnicas en vivo, que es donde más se nota la diferencia entre quien "entiende" el inglés técnico y quien puede usarlo con la misma soltura que su idioma nativo.