Tres meses después: Sigo programando, sigo aprendiendo, sigo atascado (a veces)
Después de 10 meses programando con asistentes de IA, he aprendido que son como becarios — poderosos pero que necesitan instrucciones específicas, lo que significa que debo entender profundamente los frameworks para resolver problemas reales como hacer que mi chatbot lento sea rápido.
Actualización (2026): El proyecto del chatbot financiero S&P 500 fue finalmente retirado. Sydney está de vuelta y ahora se centra en el contenido del blog y los productos. Prueba Sydney →
He estado dudando si escribir esta actualización sobre mi viaje de programación. El progreso no ha sido llamativo ni externamente visible — ¿entonces para qué molestarse?
Bueno, quizás esta publicación sirva como un buen recordatorio para mi yo futuro de que el progreso puede ralentizarse a veces y el crecimiento a menudo ocurre en ráfagas.
Desde mi última publicación sobre la construcción de un chatbot auto-evaluable a mediados de abril, me he sumergido en algunos cursos:
- React Basics de Meta en Coursera
- React Advanced de Meta en Coursera
- Framework web Django
- El Full Stack
¿Por qué estos cursos?
Quiero compartir mis experiencias personales y el proceso de pensamiento detrás de la elección de estos cursos. Mi esperanza es que pueda ayudar a aquellos de vosotros que estéis (o estaréis) en un viaje similar.
Convertirse en mejor para instruir a la máquina
Han pasado unos 10 meses desde que empecé a incursionar en la programación, mientras tenía un trabajo a tiempo completo. (Puedes leer más sobre Cómo construí mi propio chatbot sin experiencia en programación: Lecciones aprendidas publicado en octubre de 2023 aquí.)
Definitivamente NO habría podido hacerlo sin la ayuda de la IA Generativa (ya sea chatGPT, Anthropic Claude o Microsoft CoPilot en Visual Studio Code). Sin embargo, cuanto más programo, más me doy cuenta de que si bien estos modelos fundamentales son poderosos, siguen siendo como becarios. Todavía no son buenos en la planificación o en la resolución de tareas ambiguas. Cuanto más específicas sean nuestras instrucciones, mejor será el resultado.
Eso significa que necesito ser cada vez más específico con mis instrucciones de programación. Pero, ¿cómo? Hasta ahora, he estado describiendo lo que quiero en lenguaje natural. Si bien esto funciona a un nivel básico, es inadecuado para tareas más complejas.
Entonces la siguiente pregunta lógica es ¿qué aprender?
Enfocarse en los problemas de negocio/usuario que estoy intentando resolver
Mi chatbot (nombre en código Sydney) para este sitio era (quizás "es") lento. La lentitud ocurre tanto en:
- El tiempo de inicio
- Y durante la conversación
El streaming no está habilitado, por lo que los usuarios tienen que esperar un tiempo relativamente largo para ver la respuesta completa.
Así que mi objetivo era (es) simple: hacerlo rápido y responsivo.
Mi objetivo es simple: hacerlo rápido y responsivo. Pero sin más conocimiento fundamental, es difícil desglosarlo en problemas manejables para resolver. Por eso decidí aprender más sobre frameworks de frontend escalables, seguros y rápidos, frameworks de backend y el stack completo (incluyendo bases de datos).
Mis experiencias con React y Django hasta ahora
- React: React es relativamente más fácil de aprender y desplegar en comparación con Django. (¡Por supuesto!) El frontend actual del chatbot usa React, y he encontrado que Claude y ChatGPT pueden manejar la mayoría de las tareas de programación sin problemas. El despliegue en un entorno de producción con React también fue bastante simple, y la página del chatbot parece más receptiva durante las conversaciones.
- Django: Django y Django Rest Framework (DRF) tuvieron una curva de aprendizaje más pronunciada, particularmente con el despliegue que involucra una base de datos Cloud SQL y la garantía de seguridad. La naturaleza integral de Django significa que el despliegue con el nivel correcto de seguridad llevó algo de tiempo. Sin embargo, ¡todavía NO PUEDO hacer que las respuestas HTML en streaming funcionen con DRF en un entorno de producción! Si bien podría hacerlo funcionar usando WebSockets, ese enfoque se desvía significativamente de DRF, así que aún no lo he adoptado.
¡Así que si conoces un framework o una respuesta sobre cómo hacer que el streaming de LangGraph funcione con un frontend simple, dímelo!
¿Qué hay del Chatbot Financiero que mencioné en abril?
La buena noticia es que este proyecto ha despertado el interés de muchos de vosotros — he recibido numerosas preguntas y comentarios. ¿La mala noticia? Estoy muy lejos de completarlo T.T Aquí está el porqué:
1. Equilibrar la calidad de recuperación, el coste mensual del vector store y el coste de embedding
Como se mencionó en la publicación de abril, estoy evaluando el Weaviate Serverless Cloud Vector Store. Sin embargo, sí cuesta dinero real. Para este proyecto, probablemente esté viendo:
- Volumen de datos: Más de 10 millones, posiblemente 12,5 - 15 millones de objetos de datos.
- Estimación de costes: Con una dimensión vectorial de 512, el coste mensual podría oscilar entre $600 y $750.
Esta cantidad es manejable para una empresa en un entorno de producción, pero puede ser demasiado elevada para un proyecto paralelo como este. Así que necesito encontrar formas de reducir el coste.
Según cómo funciona el precio de Weaviate, las dos palancas son: reducir el número de objetos de datos o reducir la dimensión vectorial. Ambas vienen con diferentes compromisos.
Formas de reducir objetos de datos
- Limpieza agresiva de texto: Reducir el tamaño total del texto en los archivos 10K y 10Q podría ayudar, considerando que estamos tratando con 500 empresas en el S&P 500, cada una con múltiples archivos durante los últimos 10 años. Creo que he agotado esta opción.
- Aumentar el tamaño del chunk: Al aumentar el tamaño del chunk de 256 a 512, a 1.000, a 2.000 o 3.000, puedo reducir el número de objetos de datos en 2x, 4x o 10x. Sin embargo, esto puede reducir la calidad de recuperación, ya que los chunks más grandes tienden a ser menos precisos.
Formas de reducir la dimensión vectorial
Reducir la dimensión vectorial parece estar directamente correlacionado con la calidad de recuperación — cuanto menor sea la dimensión, peor será la calidad de recuperación. Todavía estoy experimentando con diferentes modelos de embedding como el "text-embedding-3-small" y "text-embedding-3-large" de OpenAI con varias dimensiones. ¡Si tienes buenas recomendaciones, por favor compártelas!
Usar el modelo "text-embedding-3-large" de OpenAI también añade al coste durante la fase de embedding. Por ejemplo, me costó $4.5 generar embeddings para los archivos 10K/10Q de 23 empresas durante los últimos 10 años con una dimensión vectorial de 1024. Esto significa que podría costar alrededor de $100+ para todo el S&P 500. (Sí, soy un poco tacaño. ¿No lo sabías ya? :P)
2. Latencia durante la traducción de consultas, la estructuración y la recuperación
Cuanto más elaborada sea la traducción y estructuración de consultas, mejores términos de búsqueda / términos de búsqueda de contenido podemos generar, lo que lleva a una recuperación de mayor calidad. Sin embargo, esto también aumenta la latencia.
- La traducción de consultas es el paso en el que le pedimos al modelo que traduzca la pregunta inicial del usuario en sub-preguntas que son mejores para la recuperación. Por ejemplo, con la pregunta original "¿Cómo cambió el margen operativo de Airbnb de 2020 a 2022?" el modelo puede generar sub-preguntas como:
[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]
- La estructuración de consultas es el paso en el que le pedimos al modelo que convierta estas preguntas en consultas de búsqueda o consultas de búsqueda de contenido para la recuperación, junto con los filtros relevantes. Usando el ejemplo anterior, para la pregunta 1, el modelo puede devolver
\{
"content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"company_conformed_name": "Airbnb, Inc.",
"form_type": "10-K",
"conformed_period_of_report": "2021-12-31"
\}
Para la recuperación, cuantos más resultados devolvamos, más tardará el modelo en procesarlos. Devolver menos resultados significa tiempos de respuesta más rápidos, pero potencialmente respuestas de menor calidad debido a la falta de contexto.
Para concluir
Hay más en lo que estoy trabajando, pero como esta publicación ya es más larga de lo esperado, lo dejaré aquí.
¿También estás aprendiendo a programar mientras trabajas a tiempo completo? ¿Cómo decides qué aprender a continuación cuando todo parece igualmente importante?
Un abrazo,
Chandler





