Crea tu propio Granola con modelos abiertos

Las decisiones, las objeciones de un cliente, el motivo por el que se descartó una idea, lo que has prometido entregar a final de semana. Una cantidad absurda de la información de una empresa pasa por conversaciones y desaparece en cuanto termina un Meet o un Teams.

Por eso usamos Granola, Fathom o cualquier otra herramienta que graba una reunión, la transcribe y genera unas notas.

Pero, si te gusta el software abierto y crear tus propias herramientas tal y como tú las quieres, también puedes construir un producto de grabación y transcripción con modelos de IA abiertos.

Y lo interesante es que, una vez tienes las transcripciones, puedes ir bastante más allá de generar un resumen de cada reunión.

Vamos a construirlo en tres capas:

Notas → Memoria → Inteligencia

Primero, un notetaker que graba tus reuniones y genera notas. Después, una memoria sobre todas las reuniones que has tenido. Y, finalmente, veremos cómo ese mismo pipeline se puede llevar a las conversaciones de toda una empresa.

Esta es la receta que he utilizado.

Lo que vamos a construir

La primera versión es sencilla:

Grabas una reunión. Whisper la convierte en texto. Un modelo transforma ese texto en resumen, decisiones, tareas y preguntas abiertas. Un modelo de embeddings convierte los fragmentos de la conversación en vectores y los guarda en un índice.

A partir de ahí puedes preguntar cosas como:

¿Qué prometí entregar a Carlos a final de semana?

¿Por qué decidimos no lanzar el plan gratuito?

Eso ya es bastante más útil que una carpeta llena de resúmenes de llamadas que nadie vuelve a abrir.

La receta

Necesitamos cuatro modelos.

Luego, otras cosas importantes:

PortAudio captura el audio. ffmpeg lo prepara. SQLite guarda el índice y FTS5 añade búsqueda por palabras clave.

En nuestra implementación lo hemos empaquetado todo en helmcode-whisper. Tres comandos son los que hacen casi todo el trabajo real:

hcw record -t "sprint review"
hcw process
hcw search "qué dijimos del tier enterprise"

El primero graba. El segundo transcribe, separa voces, genera las notas e indexa la reunión. El tercero busca sobre todas las reuniones que hayas procesado.

Qué sale de tu máquina y qué no

Un audio de reunión contiene precios, salarios, nombres de clientes, problemas internos y la voz de todos los participantes, así que muchas veces no quieres que esos datos pasen a un tercero:

La funcionalidad de record no necesita hacer ninguna petición de red y la diarización (distinguir las voces de la llamada) con pyannote se ejecuta localmente. Si la activas, Hugging Face aparece durante la instalación para aceptar los términos y descargar los pesos de los modelos, pero el contenido de la reunión no se envía allí.

El truco está en grabar dos pistas y no mezclarlas nunca

Aquí hay una decisión que simplifica muchísimo el problema de la diarización (la separación de voces): tu micrófono eres tú y el audio del sistema es todo el mundo menos tú.

Así que grabamos ambos en archivos diferentes:

audio-mic.wav       → tú
audio-system.wav    → los demás

Eso resuelve media diarización gratis. En lugar de darle una grabación mezclada a un modelo y pedirle que averigüe quién es quién, ya sabemos de entrada que todo lo que aparece en la primera pista eres tú. Así, pyannote solo tiene que separar las voces que aparecen al otro lado.

En una llamada de dos personas la salida puede ser literalmente:

Me
SPEAKER_00

Si eso es suficiente para tu caso de uso, incluso puedes desactivar la diarización y quedarte con Me y Others, sin instalar torch.

En una llamada puede aparecer un problema: el eco. Si no llevas auriculares, tu micrófono puede volver a capturar lo que sale por los altavoces y una fusión de ruidos u otras voces acaba transcribiendo algunas cosas dos veces o mal.

La solución que usamos compara cada segmento del micrófono contra lo que estaba diciendo la otra pista durante esa misma ventana temporal. Comparar segmento contra segmento cazaba el 41% del eco en nuestras pruebas. Compararlo contra toda la ventana temporal subió al 79%, sin borrar habla real. Los segmentos descartados siguen apareciendo en transcript.json con el motivo para que el proceso siga siendo auditable.

Aunque la mejor solución a esto es ponerte auriculares.

Cómo pasar de audio a datos

Una transcripción por sí sola tampoco es especialmente útil. Lo que queremos es transformar una conversación como esta:

12:41 Ana:
Entonces dejamos el lanzamiento para octubre.

12:47 Carlos:
Sí. Pero antes tenemos que resolver el onboarding.

12:53 Ana:
Me encargo yo. Intento tenerlo el viernes.

En algo parecido a esto:

{
  "decisions": [
    {
      "decision": "Mover el lanzamiento a octubre"
    }
  ],
  "action_items": [
    {
      "owner": "Ana",
      "task": "Resolver el onboarding",
      "due_date": "viernes"
    }
  ]
}

Ahí cambia la utilidad de la reunión porque pasas de tener texto, a tener datos. A mí me parece la parte más importante porque es la que permite luego crear una capa de conocimiento de la compañía real.

En nuestro caso DeepSeek V4 Flash genera mediante json_schema cinco secciones: resumen, decisiones, tareas con responsable y fecha, preguntas abiertas y citas.

Lo que hay que entender es que pasamos de tener unas notas bonitas a tener información indexable. Con un json_schema queremos que todas las reuniones produzcan exactamente la misma estructura.

Por eso cada reunión acaba generando:

audio-mic.wav
audio-system.wav
transcript.json
notes.json
notes.md
notes.html
meta.json

notes.md es para humanos, notes.html para compartir y notes.json para construir cosas encima.

El prompt tampoco debería estar enterrado en el código

Esta es otra de las ventajas de montártelo tú: el prompt que decide cómo son tus notas debería ser tuyo. Y lo puedes modificar como quieras y cuando quieras.

En nuestra implementación vive en:

templates/notes.md

Puedes decidir qué añades como una decisión, cambiar el idioma, pedir otro formato o añadir una sección de riesgos. O lo que se te ocurra.

Una empresa de ventas, por ejemplo, podría añadir:

## Objeciones

Extrae las objeciones planteadas por el cliente.
Para cada una incluye:

- objeción
- respuesta del comercial
- si quedó resuelta
- producto o competidor mencionado

Mientras que un equipo de producto podría pedir:

## Product feedback

Extrae:

- funcionalidades solicitadas
- problemas actuales
- workarounds mencionados
- nivel de urgencia

Mismo audio, mismo pipeline, distintos datos.

El modelo también es intercambiable:

HCW_NOTES_MODEL=qwen3.6 hcw process --force

Ese es precisamente el punto de construirlo con modelos abiertos. Y es bastante chulo.

Cómo convertir notas a memoria

Ahora tenemos una carpeta llena de reuniones perfectamente estructuradas, pero nadie va a abrir 300 notes.md para encontrar nada.

Así que necesitamos búsqueda.

Nosotros combinamos búsqueda vectorial con SQLite FTS5. La primera encuentra fragmentos conceptualmente similares; la segunda funciona especialmente bien con nombres concretos, productos, clientes o términos exactos. Después, un reranker ordena la unión de ambos resultados.

Por ejemplo, si preguntas:

¿Qué número dijimos que íbamos a cobrar?

La búsqueda vectorial puede encontrar una conversación sobre pricing aunque no aparezca exactamente la palabra "precio". Si buscas el nombre exacto de un producto o cliente, FTS5 puede hacerlo mejor.

Puedes probarlo directamente:

hcw search "por qué descartamos aquella idea del onboarding"

Y buscar sobre todas las conversaciones que hayas procesado.

Aquí ya no solo tienes una aplicación de notas. Tienes memoria.

Hasta aquí llega nuestro repo. Ahora vamos a llevar la idea más lejos

Todo lo anterior existe hoy en helmcode-whisper: captura, transcripción, diarización, notas estructuradas, embeddings, búsqueda híbrida y reranking.

Lo siguiente no está implementado en el repo, pero te dejamos la idea y la estructura por si quieres implementarlo tú.

Es la arquitectura que construiríamos encima si quisiéramos pasar de una herramienta personal a una capa de inteligencia para toda una empresa.

El pipeline fundamental no tendría que cambiar. Seguirías grabando, transcribiendo, separando voces, extrayendo información e indexándola. Lo que cambia es dónde termina el resultado.

En lugar de guardar cada reunión únicamente en ~/helmcode-whisper/, necesitarías almacenamiento central, usuarios, una organización asociada a cada reunión, equipos, permisos y un índice compartido.

Conceptualmente:

Esta arquitectura te permite empezar a hacer preguntas que una herramienta personal no puede responder:

¿Cuáles son las cinco objeciones más repetidas este mes?

¿Qué competidores aparecen más en las oportunidades que perdemos?

¿Qué funcionalidades han pedido al menos tres clientes diferentes?

¿Qué problemas aparecen repetidamente en las llamadas de onboarding?

Y podrías ir un paso más allá: en vez de esperar a que alguien haga una pregunta, ejecutar procesos periódicos sobre esas conversaciones para agrupar objeciones, detectar peticiones recurrentes o generar informes.

Pero esa es ya la siguiente capa que tienes que construir encima del repo y es tu decisión cómo usarlo.

Cómo ponerlo en marcha

Si simplemente quieres probar nuestra implementación:

uv tool install git+https://github.com/helmcode/helmcode-whisper

mkdir -p ~/helmcode-whisper
echo "HELMCODE_API_KEY=sk-tu-clave" > ~/helmcode-whisper/.env

hcw doctor

La clave la sacas en cloud.helmcode.com y con ella tienes acceso a todos los modelos de la receta excepto pyannote, que puedes descargar con pesos abiertos desde Hugging Face.

hcw doctor comprueba dispositivos de audio, ffmpeg, acceso a los modelos y si torch está viendo correctamente tu GPU. Es lo primero que hay que ejecutar porque te dice exactamente si falta algo.

Después:

hcw record -t "sprint review"

Termina la reunión con Ctrl+C y ejecuta:

hcw process

Y prueba:

hcw search "qué decisiones tomamos sobre pricing"

Todo esto lo ejecutas desde la terminal. Pero puedes agregar una interfaz encima, como hemos hecho nosotros. Es muy útil para todos los usuarios que no son técnicos. Tienes nuestra UI si quieres utilizarla también en abierto en este repo: helmcode-whisper-ui

Haz fork y construye tu propio Granola

No hace falta empezar desde un repositorio vacío. Hemos publicado helmcode-whisper como proyecto open source y con licencia Apache-2.0 precisamente para que puedas desmontarlo, cambiarlo o construir encima.

Haz fork de helmcode-whisper , ábrelo con Claude Code, Codex, OpenCode o el agente que uses y dale algo parecido a esto:

Este repositorio es una implementación de referencia de un sistema de
meeting intelligence construido con modelos abiertos.

Quiero convertirlo en mi propio Granola personal.

Antes de escribir código:

1. Lee README.md.
2. Lee docs/DATA.md.
3. Revisa templates/notes.md.
4. Revisa examples/.
5. Identifica el pipeline completo desde record hasta search.
6. Ejecuta los tests existentes.
7. Explícame brevemente la arquitectura y qué interfaces podemos reutilizar.

No reescribas el pipeline existente.

Mantén:

- grabación separada de micrófono y audio del sistema
- Whisper para transcripción
- diarización local
- notas estructuradas mediante JSON schema
- embeddings + FTS5 + reranking
- cache por etapas
- transcript.json y notes.json como interfaces de datos

Quiero construir encima una interfaz web personal desde la que pueda:

- iniciar y detener una grabación
- ver mis reuniones anteriores
- abrir una reunión
- leer la transcripción
- ver resumen, decisiones y action items
- buscar sobre todas mis reuniones
- preguntar en lenguaje natural sobre reuniones anteriores

Usa notes.json, transcript.json y el stream de progreso existente como
contratos con la UI siempre que sea posible.

No añadas todavía organizaciones, multi-tenancy, permisos ni inteligencia
agregada. Esa será una segunda fase.

Primero dame un plan corto de implementación basado en el código que realmente
existe en el repositorio. Después empieza a implementarlo por fases, manteniendo
los tests existentes verdes.

Eso te ahorra construir la parte difícil desde cero. La captura de audio, la separación de pistas, el chunking, la diarización, la supresión de eco, el almacenamiento estructurado, el caching y la búsqueda ya están ahí.

El repo está en github.com/helmcode/helmcode-whisper con licencia Apache-2.0. Los cuatro modelos de la receta corren en Helmcode: infraestructura en la UE, sin logs y con tarifa plana.