Casos de uso•Caso real: brain

Un chatbot con IA para la documentación de tu proyecto: lo que aprendimos con brain

Cómo brain, un servidor MCP open source, puso un chatbot de documentación en su sitio en una tarde: un solo markdown, un prompt estricto y las preguntas de prueba que importan. Guía práctica para cualquier proyecto técnico.

Por Lautaro, DokBot2026-09-276 min de lectura

brain es un servidor MCP open source que corre en tu Mac y le da a Claude, ChatGPT, Cursor y otros agentes una memoria compartida. Es una herramienta útil, pero tiene muchas piezas: Ollama para los embeddings locales, Chroma para la búsqueda, un dashboard, conexiones a otros servidores MCP y una configuración distinta por cada agente que quieras enchufar.

Ese es justo el tipo de proyecto donde las mismas preguntas aparecen una y otra vez. Así que brain sumó un widget de DokBot a su sitio, entrenado solo con su propia documentación. En este post contamos cómo se armó, qué funcionó y qué le diríamos a cualquiera que quiera un chatbot para la documentación de su proyecto.

1. El problema: los issues de GitHub usados como mesa de ayuda

Si mantenés un proyecto técnico, conocés la lista. En brain era más o menos esta: cómo lo instalo, cómo conecto Claude Desktop, si algo sale de mi computadora, por qué no arranca Ollama y cuál es la diferencia entre brain como servidor MCP y como cliente MCP.

Todas esas respuestas ya estaban en el README. El tema es que un README es largo, la gente llega primero al sitio web y nadie quiere leer 400 líneas para encontrar un párrafo. Entonces las dudas terminan como issues en GitHub o mensajes directos, y el que mantiene el proyecto responde lo mismo por décima vez.

Un chatbot de documentación no reemplaza a una buena documentación. Es una forma más rápida de llegar a la documentación que ya tenés.

2. Un solo markdown le ganó a doce páginas sueltas

La primera decisión fue qué subir. brain tenía contenido repartido entre el README, un changelog, un documento de diseño y el sitio web. En lugar de subir todo, lo útil para un usuario se juntó en un solo archivo: brain-knowledge-base.md, de unos 21 KB. Las notas internas de diseño quedaron afuera.

¿Por qué un solo archivo? Porque RAG trabaja con fragmentos. DokBot divide tus documentos en partes y, ante cada pregunta, trae las más relevantes al prompt. Si un fragmento dice "ver la sección de arriba", el modelo nunca ve la sección de arriba. Escribir cada sección para que se entienda sola fue la mejora de calidad más grande, más que cualquier ajuste al prompt.

Otras dos cosas ayudaron: títulos escritos como pregunta el usuario ("¿Cómo conecto ChatGPT?" en vez de "Integración de clientes") y repetir el nombre del producto en lugar de "esto" al principio de cada sección, para que cada fragmento lleve su propio contexto.

3. La configuración: prompt estricto, temperatura baja y sin API key

La configuración del bot es aburrida a propósito. El system prompt le dice al modelo que responda estrictamente con el contexto que recibe y que, si no sabe, invite al visitante a dejar su email. La temperatura está en 0,3, porque para documentación querés la misma respuesta siempre, no creatividad.

Para el modelo, brain usa créditos IA de DokBot en lugar de su propia key, con un modelo rápido y barato (deepseek-v4-flash). Para un bot de documentación que responde preguntas cortas, un modelo insignia es exagerado. Si preferís pagarle directo al proveedor, podés conectar tu propia key de OpenAI, Anthropic, Gemini, Groq u OpenRouter.

Desde crear el bot hasta tenerlo publicado pasó más o menos media hora, y la mayor parte fue probar respuestas, no configurar.

4. Las preguntas que hay que probar antes de publicar

Todo bot arranca como borrador, y el Live Preview es donde descubrís si tu documentación alcanza. Recomendamos tres tipos de preguntas de prueba. Primero, las obvias, hechas como las haría alguien que no conoce el proyecto: "hola, ¿qué es brain?" recibió una respuesta correcta que lo describe como servidor y cliente MCP local con un dashboard para Ollama y Chroma.

Segundo, preguntas cuya respuesta es "no". Por ejemplo, "¿brain funciona en Windows?". La documentación dice que es solo para macOS, y querés que el bot lo diga claro en vez de improvisar pasos de instalación para otro sistema.

Tercero, preguntas que directamente no están en la documentación. Ahí entra el fallback: el bot dice que no tiene esa información y ofrece tomar el email del visitante. Si el bot responde algo que no está en tu archivo, tu prompt está demasiado suelto.

5. Mantenerlo actualizado es el trabajo de verdad

Un chatbot de documentación está tan al día como el archivo que tiene detrás. La regla simple en brain: cuando el changelog suma algo que afecta al usuario, el archivo de la base de conocimiento también se actualiza. Subir la versión nueva y borrar la vieja lleva un minuto, y el bot usa el contenido nuevo al instante.

El otro hábito que vale la pena es leer las conversaciones que terminaron en fallback. Cada pregunta que el bot no pudo responder es un hueco en tu documentación, reportado gratis por un usuario real. Es mejor hoja de ruta para tus docs que adivinar.

6. Cuándo no vale la pena un chatbot de documentación

Para ser honestos: si toda tu documentación entra en una pantalla, alcanza con una buena sección de preguntas frecuentes. Y si las consultas que recibís dependen de la cuenta del usuario (su pedido, su factura, sus datos), un bot que solo lee tu documentación no las va a poder responder.

Donde brilla es justo en el caso de brain: un producto técnico con documentación real, varios caminos de instalación y usuarios que prefieren preguntar antes que leer. Si eso se parece a tu proyecto, podés probarlo en el plan gratuito con tu propio README.

El Veredicto: ¿Por qué elegir DokBot?

  • Juntá la documentación para usuarios en un solo archivo bien estructurado en vez de subir todo lo que tengas.
  • Escribí cada sección para que se entienda sola: RAG solo ve fragmentos.
  • Usá un prompt estricto, temperatura baja y un modelo rápido y barato; un bot de documentación no necesita un modelo insignia.
  • Probá preguntas obvias, preguntas con respuesta "no" y preguntas fuera de alcance antes de publicar.
  • Leé las conversaciones con fallback: son una lista gratis de huecos en tu documentación.

Poné un chatbot en tu documentación esta misma tarde

Subí tu README o tu documentación, probá las respuestas en el Live Preview y embebé el widget con una sola línea de script. El plan gratuito incluye créditos de bienvenida, así que no necesitás API key para empezar.