CLI App para analizar sentimiento, entidades e idioma en texto usando Azure AI Language.
Estado: MVP, en evolución. Pensado como base para un proyecto web con casos de uso reales.
- Acerca de este proyecto
- Stack
- La CLI
- Requisitos e instalación
- Calidad de código
- Qué quiero hacer ahora con el proyecto
Comencé este proyecto como una simple prueba de Azure. En los commits iniciales se ve que era solo un código copiado del SDK que luego fui implementando, mejorando y probando hasta convertirlo en una aplicación de terminal con fines plenamente educativos y de aprendizaje.
Siempre he sido aficionado a las herramientas por terminal y he construido varias en los proyectos en los que he trabajado, pero que nunca puedo compartir. Supongo que esto es una muestra de cómo una prueba de concepto o un simple ejercicio pasa de algo básico a algo mucho más elaborado.
- Python 3.12
- Azure AI Language (Text Analytics) — análisis de sentimiento, entidades e idioma
- azure-ai-textanalytics — SDK oficial de Azure
- Pydantic — modelos y configuración
- Rich — salida en terminal (tablas, colores)
- python-dotenv — credenciales desde
.env - Stack de desarrollo: Ruff, Mypy y Pytest (Calidad de código)
La CLI cuenta con distintas funcionalidades. Al principio probé qué era lo mejor, qué era lo que me devolvía, cómo podía repetir localmente lo mismo que devolvía la consola de Azure. Fue un desafío corto en realidad. Fui experimentando, probando y arreglando sobre la marcha, porque todo fue naciendo de necesidades que iba encontrando, hasta terminar con esta versión. Lo más importante fue cómo resaltar el valor de lo que nos entregan estos insights.
- Consulta a la API de Azure cuando las credenciales están configuradas en un archivo
.env. - Lectura de archivos exportados (o guardados) de esos análisis, por si el usuario los necesita.
- Modo demo, presets para quien no quiera usar la API y quiera probarlo rápido o por si Azure cae (Guiño guiño).
La forma de presentar la información me pareció bastante deficiente al inicio. Así que iterando una y otra vez, con prueba y error y según mis gustos, fui alcanzando un ideal, de cómo hacer que bajo contextos tanto de uso, pruebas de concepto y funcionamiento del servicio se lograra algo extremadamente fácil de utilizar.
Había usado la librería Rich hace unos meses para construir herramientas similares a estas que realizaban pruebas end-to-end en arquitecturas basadas en eventos en AWS, así que ya traía algo de experiencia para lograr buenos resultados visuales y que la mayoría de personas pudiera entenderlo. Y viendo que muchos servicios en la nube son medio complicados de explicar o difíciles de encontrar porque cambian constantemente entre menús, esto es una solución para uno de ellos.
Insisto, es de carácter educativo y una manera sencilla de mostrar cómo funciona un servicio de este tipo.
- Python 3.10 o superior (el proyecto está desarrollado con 3.12).
Desde la raíz del repo:
1. Crear y activar el entorno virtual
python -m venv .venvEn Linux o macOS:
source .venv/bin/activateEn Windows (PowerShell):
.venv\Scripts\Activate.ps12. Instalar dependencias
pip install -r requirements_cli.txtPara usar la CLI con Azure necesitas un archivo .env en la raíz con las variables que espera la app (endpoint y clave del recurso de Language Service). Sin .env puedes usar el modo demo.
Para crear el .env desde la raíz del repo (funciona en Windows, macOS y Linux) esto teniendo Python previamente instalado:
python -c "open('.env','w').write(\"LANGUAGE_KEY = ''\nLANGUAGE_ENDPOINT = ''\n\")"Sustituye los valores vacíos por tu clave y la URL del recurso de Language Service en Azure.
Cuando el proyecto empezó a ganar muchas líneas de código traje algunas herramientas de Python para escalar en calidad. Había comenzado con type hints aquí y allá. El cambio de verdad se produjo cuando reorganicé todo en distintas estructuras y carpetas pero cuando ya me empezó a nacer la idea de escalar esto un poco más añadí Ruff y Mypy. A partir de ahí el código pasó a tener un estilo y unos tipos consistentes, y los tests y el linter comenzaron a formar parte del flujo formal.
Lo que use (todo instalado en el .venv del proyecto personal a modo de desarrollo, pero que aún no quiero mostrar hasta definir bien el propósito): Ruff (lint y formato), Mypy (chequeo de tipos estáticos), Pytest (tests, con pytest-mock para mocks). Ruff usa además reglas de Pylint y McCabe para complejidad. La config está en cli/pyproject.toml.
Todo esto pensando en el siguiente proyecto que nacerá de este y preparando el terreno para los siguientes pasos.
Me gustó mucho usar este tipo de herramientas, pero también siento que es importante mostrar casos de uso reales y de negocio. Estoy trabajando en eso ahora, una app web un poco más compleja que esto pero que le saque partido a este tipo de servicios.
Ver cómo el feedback y sus métricas pueden impactar en áreas de negocio, en la calidad de un servicio o en la fidelidad de un cliente es todo un proceso de storytelling donde se pueden sacar datos muy interesantes. Una app web que muestre todo eso ayudaría a enseñar la importancia de estas herramientas. Sobre todo ahora que está todo tan automatizado y la calidad de muchos de estos servicios automatizados deja mucho que desear.
Tengo algunas ideas en mente sobre sectores a considerar, quizá hostelería, banca o reviews de productos. Dado el carácter educativo de este proyecto y la manera en que me gusta mostrar las cosas, creo que puedo hacer algo divertido mientras aplico tecnologías que quiero utilizar, simplemente para ver cómo interactúa todo un ecosistema.
Fui preparando el terreno con Pydantic pensando en FastAPI y en reutilizar parte de la lógica aprendida en la CLI, así que no lo considero un desarrollo poco útil. De hecho aprendí bastante. Quiero unificar todos estos aprendizajes recientes de forma educativa y entretenida, y que se vea como un proyecto de portafolio en evolución hacia un caso de uso real, desde una simple prueba con un archivo del SDK hasta una app web con un caso de negocio.