En todas las empresas pasa lo mismo. Ante cualquier pregunta, la respuesta existe, está escrita, alguien dedicó una tarde a documentarla. Pero vive en un PDF que nadie encuentra o en un repo que solo conoce el equipo que lo creó. Así que al final la pregunta acaba donde siempre: en el Slack o el Teams de alguien.
Knowledge es nuestra respuesta a ese agujero. Subes tu documentación una vez, o conectas un repositorio de Git y te olvidas, y cualquiera de tu organización puede preguntarle desde el chat. Las respuestas salen de tus documentos y llevan cita a la fuente, así que puedes verificar de dónde viene cada cosa.
Si eres técnico, este detalle te va a interesar: esto es RAG sin montar un RAG. Ni bases de datos vectoriales, ni pipeline de embeddings, ni chunking que ajustar. Todo eso ocurre por debajo; tú subes documentos y preguntas. Ya está. Lo puede hacer alguien técnico, alguien de contabilidad, de HR, de legal, de operaciones o de cualquier equipo de la compañía.
Qué es una knowledge base
Una fuente RAG privada a nivel de organización. La crea una persona y está disponible para todo el equipo. Cada base agrupa los documentos de un tema (el manual de empleados, la documentación de un servicio, las políticas de compliance) y se activa desde el propio chat, con el mismo selector con el que eliges modelo.
Un ejemplo real, de principio a fin
Vamos a hacer el recorrido completo con el caso más universal que existe: el manual del empleado. El documento que todo el mundo tiene y que, por desgracia, nadie se lee.
- Creamos la base. En Knowledge, New base, le ponemos nombre ("HR Handbook") y una descripción. Cinco segundos.
- Subimos el manual. Arrastramos el PDF al área de subida. Cada documento muestra su estado de indexado; cuando pasa a Ready, está listo para preguntar. Soporta PDF, TXT y MD de hasta 25 MiB, y también puedes escribir páginas directamente desde el dashboard con New page.
- Preguntamos. En el chat, abrimos el selector de knowledge base (por defecto está en "No knowledge base"), elegimos HR Handbook y escribimos como le escribiríamos a alguien de RRHH:
¿Cuántos días de vacaciones tenemos?
Y la respuesta:
23 días laborables el primer año, más el día de tu cumpleaños. Los días no disfrutados se acumulan hasta el 31 de marzo.
Fuente: employee-handbook.pdf
Fíjate en la cita. Cita la fuente de la que bebe. Y es lo que separa un RAG de un chatbot. Si la respuesta te genera alguna duda, un clic y estás en el documento original.
Eso es todo el flujo. Tres pasos, sin tocar una línea de código. La documentación de referencia tiene el detalle de cada pantalla.
El modo pro: conecta un repositorio y olvídate
Subir ficheros a mano está bien para documentos que cambian poco. Para documentación viva hay algo mejor: apuntar la base a un repositorio de GitHub o GitLab y dejar que se sincronice sola.
Funciona así: conectas el proveedor con un personal access token de solo lectura (se guarda cifrado y no vuelve a mostrarse), añades el repositorio como owner/repo, eliges rama, una ruta opcional si solo quieres un subdirectorio, y la frecuencia de sincronización. A partir de ahí, cada cambio que se mergea en el repo acaba en la knowledge base sin que nadie haga nada.
Esto convierte el "docs as code" en "docs que responden". Un ejemplo de nuestro propio uso: el repositorio de un servicio con su documentación en markdown, sincronizado cada hora. Pregunta en el chat: "explícame el flujo de autenticación". La respuesta sale de la doc que el propio equipo mantiene en el repo, siempre en su última versión. La wiki desactualizada deja de existir porque la wiki es el repo.
Dos notas prácticas: funciona también con instancias self-hosted de GitHub Enterprise y GitLab (basta con indicar la Base URL), y las bases sincronizadas desde Git son de solo lectura desde la página Knowledge: la fuente de verdad es el repo, y ahí es donde se edita.
Nosotros estamos creando un repo de "contexto" de toda la empresa que actúa como cerebro y nos ayuda a entender qué pasa en cada equipo ahora mismo.
Cómo conseguir buenas respuestas
El sistema hace el trabajo pesado, pero la calidad de las respuestas depende de la calidad de lo que subes. Tres costumbres que marcan la diferencia:
- Documentos con estructura. Un markdown limpio con títulos descriptivos funciona mejor que un PDF escaneado o un documento sin títulos. El sistema trocea los documentos para buscar en ellos y los títulos son las anclas que usa para cada tema.
- Un tema por documento, mejor que una Biblia. Diez documentos de diez páginas dan mejores respuestas que uno de cien. Si tu manual lo mezcla todo, trocéalo antes de subirlo.
- Nombres de fichero descriptivos. La cita muestra el nombre del documento. "politica-vacaciones-2026.md" le dice al que pregunta dónde está mirando; "docfinalv3.pdf" no.
Y sobre qué preguntar: funciona mejor con preguntas concretas ("¿cuál es el plazo para presentar gastos?") que con encargos abiertos ("resúmeme todas las políticas"). Es un sistema de recuperación, no un analista: encuentra y cita lo que está escrito.
Para qué lo están usando los equipos
- Onboarding. La persona pregunta a la base en vez de interrumpir al senior o, peor, quedarse con las dudas.
- Soporte. El manual del producto como base; el equipo responde tickets consultándolo en segundos.
- Ingeniería. Runbooks y postmortems sincronizados desde el repo. No hay que buscar nada si algo se cae a las 3 de la mañana.
- Legal y compliance. Políticas internas consultables por toda la organización, sin depender de que alguien recuerde en qué carpeta estaba el PDF.
- El cerebro de cada área. Un repo por departamento con su contexto: estrategia, decisiones, vocabulario, aprendizajes. El conocimiento deja de irse cuando alguien se va.
- Ventas y propuestas. Las últimas propuestas y casos de éxito como base. "¿Qué le ofrecimos a un cliente parecido?" para tomar como referencia.
- Contratos y proveedores. Los contratos vigentes consultables: "¿cuándo renueva X?", "¿qué SLA firmamos con Y?". Sin navegar la carpeta en la que cuesta tanto buscar.
- Research de clientes y mercado. Notas de llamadas, análisis de competencia y research acumulado. Antes de cada decisión: "¿qué nos han dicho los clientes de esto?".
- Tu propio proyecto. Sincroniza el repo con su README y sus docs, y tienes un asistente que conoce tu código base. Para colaboradores nuevos o para ti dentro de tres meses.
La pregunta: ¿dónde acaban mis documentos?
Es la primera pregunta que hay que responder cuando lo que subes es documentación interna de tu empresa, y la respuesta es la de siempre: los documentos que subes solo están almacenados y accesibles en tu plataforma. Puedes eliminar una knowledge base en cualquier momento y los documentos dejan de existir también en Helmcode.
Todo se procesa en infraestructura europea, con cero logs de tus conversaciones, y las respuestas las generan los mismos modelos abiertos de tu plan. Nada sale hacia APIs de terceros.
Monta tu knowledge base en cinco minutos
El flujo completo: crea una base en cloud.helmcode.com/knowledge, sube tres documentos o conecta un repo, y hazle la pregunta que más veces has respondido este mes. La documentación de referencia tiene cada pantalla en detalle.
Y cuando la tengas montada, cuéntanos qué le preguntas. Las mejores ideas de producto nos llegan así.
