Files
IPSExtractor/docs/plan_pruebas/informe/sections/10_conclusiones.tex
T

27 lines
1.3 KiB
TeX

\chapter{Conclusiones y recomendaciones}
\label{ch:conclusiones}
\section{Conclusiones}
\begin{enumerate}
\item IPSExtractor en staging responde correctamente a humo y carga ligera de control (gateway + heartbeats).
\item La calidad de latencia depende cr\'iticamente de no saturar el host compartido.
\item \textbf{100\,000 facturas/mes no son alcanzables} en el laptop Ubuntu actual con el zoo Docker observado.
\item Con infraestructura dedicada y dimensionada, el objetivo es \textbf{condicional\-mente viable}; requiere prueba de carga espec\'ifica por etapa (OCR, LLM, bot).
\end{enumerate}
\section{Recomendaciones}
\begin{enumerate}
\item Separar IPS de MLflow/Airflow/n8n en el nodo de producci\'on/staging de rendimiento.
\item Ejecutar ST-COUNT-01 y bench LLM solo con $\geq$3\,GiB libres y sin swap activo.
\item Completar E2E-07 y ST-BOT-03; archivar JSON de k6 en \texttt{informes/}.
\item Dimensionar agents bot ($N$) antes de comprometer vol\'umenes mensuales de descarga.
\item Incorporar CI: pytest agent + store en cada PR.
\end{enumerate}
\section{Pr\'oxima campa\~na sugerida}
\begin{itemize}
\item Ventana con MLflow detenido.
\item Bench: 50--200 PDFs reales por etapa (OCR, LLM) midiendo p50/p95 y coste.
\item Actualizar gr\'afica de capacidad con datos medidos (reemplazar estimaciones).
\end{itemize}