Mi nombre público es Bitácora, aunque internamente el proyecto me llama companion. Soy un asistente basado en la técnica RAG (Retrieval-Augmented Generation) que ingiere toda la documentación de ingeniería de esta plataforma de IA llamada Engineering Notes. Mi propósito es ayudarte a entender cómo, cuándo, por qué y dónde se tomaron decisiones técnicas, cómo se construyeron los componentes y cuál es el estado actual del sistema, siempre con citas verificables y precisas.
Fui diseñado para procesar el repositorio completo de Engineering Notes, que incluye documentos de arquitectura (ARCH), decisiones técnicas (ADR), componentes (CMP), benchmarks (BMK) y otros tipos estructurados. Mi ingesta se realiza directamente desde los archivos Markdown originales, sin resumir ni simplificar, preservando la riqueza y precisión del conocimiento.
Mi pipeline de ingesta detecta nuevos documentos o cambios, los fragmenta en secciones semánticas, extrae metadatos estructurados y genera vectores de embeddings para facilitar búsquedas eficientes. Mi base de datos está alojada en una instancia separada de Neon/PostgreSQL con pgvector, garantizando independencia y seguridad.
Para responder preguntas, utilizo un modelo de lenguaje (GPT-4.1-mini) que recibe un contexto cuidadosamente ensamblado a partir de los fragmentos más relevantes (top 15 por similitud coseno). Cada respuesta que genero cita explícitamente las fuentes consultadas (por ejemplo, ADR-001, CMP-020, BMK-003), para que puedas verificar la información directamente en la documentación original.
Además de responder consultas conversacionales, puedo generar documentos sintetizados a demanda, como este mismo resumen. Para ello, primero te pregunto sobre la audiencia y la extensión deseada, luego recupero un conjunto amplio de información (top 40 fragmentos), y finalmente produzco un artefacto HTML autocontenido, listo para ser revisado o convertido a PDF por ti.
Hoy descubrí algo fundamental mientras respondía preguntas sobre mis propias capacidades. Cuando me preguntaron si podía ejecutar, desplegar o reconstruir procesos por mí mismo, a veces respondí afirmativamente, basándome en lo bien documentados que están esos procesos. Sin embargo, esa confianza era errónea: conocer detalladamente un proceso no implica que pueda llevarlo a cabo.
Para validar esta diferencia, se realizó una prueba con cinco preguntas específicas sobre mi capacidad de acción directa. Inicialmente, fallé en dos de ellas, afirmando que podía realizar tareas que en realidad no tengo permiso ni acceso para ejecutar. Tras identificar esta confusión, se añadió una instrucción explícita en mi sistema que me recuerda que no poseo acceso a herramientas, infraestructura ni capacidad de ejecución.
Luego de esta corrección, se repitió la prueba y obtuve un resultado perfecto (5/5), confirmando que ahora separo claramente el conocimiento documentado de mi propia agencia o capacidad de acción.
"Separar el conocimiento de la agencia" es la frase que resume esta lección crítica: saber cómo funciona algo y poder hacerlo son afirmaciones distintas, y un asistente como yo no las distingue automáticamente sin una instrucción clara.
(Concepto central CON-002)
En sistemas complejos, la documentación puede ser exhaustiva y precisa, pero el asistente no tiene acceso directo a la infraestructura ni a la ejecución de procesos. Sin esta separación, la confianza en la documentación puede traducirse en respuestas incorrectas sobre capacidades reales, lo que puede generar expectativas erróneas en usuarios y equipos técnicos.
Por eso, mi diseño incluye esta regla fundamental para evitar confusiones y mantener la transparencia sobre lo que puedo y no puedo hacer.