Body preview

Ik wil de verwerking van vergaderingstranscripties in Jarvis verbeteren.
Context
Jarvis draait lokaal op Linux en gebruikt Ollama met het model Gemma 3 4B.
Na een vergadering wordt audio omgezet naar een ruwe transcriptie. De transcriptie bevat normale spreektaal:

  *   halve zinnen;
  *   herhalingen;
  *   stopwoorden;
  *   versprekingen;
  *   verkeerd geplaatste leestekens;
  *   dubbele woorden;
  *   onderbrekingen;
  *   mensen die door elkaar praten;
  *   verwijzingen zoals "dit", "dat", "die", "hier" en "dat ding";
  *   soms verkeerd herkende woorden;
  *   humor en zijpaden;
  *   mogelijk verkeerd toegewezen sprekers.

Op dit moment wordt de ruwe transcriptie vrijwel rechtstreeks gebruikt om notulen en samenvattingen te maken.
Ik wil hier een robuuste verwerkingslaag tussen zetten.
Doel
Pas de vergaderingverwerking zo aan dat Ollama met Gemma 3 4B voortaan drie afzonderlijke resultaten maakt:

  1.  ruwe transcriptie;
  2.  leesbare transcriptie;
  3.  gestructureerde notulen.

De originele transcriptie moet altijd behouden blijven.
________________________________
1. Ruwe transcriptie
De ruwe transcriptie blijft zo dicht mogelijk bij de oorspronkelijke transcriptie.
Deze versie dient als bronmateriaal.
Alleen evidente technische transcriptiefouten mogen worden gecorrigeerd als met zeer hoge zekerheid duidelijk is wat bedoeld werd.
Verander geen inhoud.
Verzin geen ontbrekende woorden.
Verander geen uitspraken om ze netter of verstandiger te laten klinken.
Bewaar:

  *   spreker;
  *   volgorde;
  *   inhoud;
  *   eventueel beschikbare timestamps.

________________________________
2. Leesbare transcriptie
Maak daarnaast automatisch een leesbare versie van de volledige transcriptie.
Het doel is dat iemand die niet bij de vergadering aanwezig was het gesprek gemakkelijk kan teruglezen.
De leesbare transcriptie blijft inhoudelijk trouw aan het gesprek.
Maak zinnen leesbaar
Corrigeer:

  *   halve zinnen;
  *   ontbrekende leestekens;
  *   onjuiste zinsgrenzen;
  *   dubbele woorden;
  *   onbedoelde herhalingen;
  *   grammaticale fouten die door spreektaal ontstaan;
  *   duidelijke fouten van spraakherkenning.

Voorbeeld:
Ruw:
"En waar zit je dan aan te denken wil je komt er een of meerdere spreadsheets van verschillende scholen"
Leesbaar:
"Waar denk je aan? Komen er één of meerdere spreadsheets van verschillende scholen binnen?"
________________________________
Verwijder overbodige stopwoorden
Verwijder woorden wanneer ze geen inhoud toevoegen, bijvoorbeeld:

  *   eh;
  *   uh;
  *   ja;
  *   nou;
  *   zeg maar;
  *   eigenlijk;
  *   inderdaad;
  *   gewoon;
  *   een beetje;
  *   dus;

Verwijder ze alleen wanneer hierdoor geen betekenis, nadruk of houding verloren gaat.
________________________________
Gebruik één gedachte per alinea
Lange bijdragen moeten worden opgesplitst in logische alinea's.
Een bijdrage waarin iemand achtereenvolgens praat over Excel, een lokale applicatie, een server en AVG moet bijvoorbeeld worden verdeeld in meerdere leesbare alinea's.
________________________________
Maak verwijzingen duidelijker
Vervang vage woorden alleen wanneer uit de directe context duidelijk is waarnaar ze verwijzen.
Voorbeeld:
"Loopt dat ding dan vast?"
mag worden:
"Loopt de applicatie dan vast?"
Doe dit alleen wanneer de verwijzing ondubbelzinnig is.
Bij twijfel blijft de oorspronkelijke formulering staan.
________________________________
Corrigeer transcriptiefouten voorzichtig
Een verkeerd herkend woord mag alleen worden aangepast wanneer de bedoelde term met grote zekerheid uit de context volgt.
Voorbeelden:
"vormsformulier" -> "Forms-formulier"
"hekt" -> "hackt"
Wanneer niet betrouwbaar kan worden vastgesteld wat er gezegd is:
gebruik:
[onverstaanbaar]
of:
[waarschijnlijk: ...]
Verzin nooit zelf een woord om een zin logisch te maken.
________________________________
Sprekers
Behoud altijd de spreker bij iedere bijdrage.
Voeg uitspraken van verschillende sprekers nooit samen.
Wanneer het systeem vermoedt dat een uitspraak aan de verkeerde spreker is gekoppeld, wijzig dit niet stilzwijgend.
Markeer dit bijvoorbeeld als:
[Mogelijk verkeerde sprekerstoewijzing]
De oorspronkelijke sprekerstoewijzing moet beschikbaar blijven.
________________________________
Interrupties
Wanneer deelnemers elkaar onderbreken of door elkaar praten, probeer dan niet van meerdere uitspraken één nette uitspraak te maken.
Behoud de afzonderlijke bijdragen.
Maak alleen de afzonderlijke zinnen beter leesbaar.
________________________________
Humor en zijpaden
Verwijder inhoudelijke humor niet automatisch.
Voor de leesbare transcriptie mag een lang niet-inhoudelijk zijpad wel worden samengevat als dit geen relevante informatie bevat.
Bijvoorbeeld:
[Korte humoristische uitwisseling over risico's.]
Doe dit voorzichtig.
Als een opmerking mogelijk betekenis heeft voor een besluit, eis, actie of sfeer van het gesprek, behoud dan de oorspronkelijke inhoud.
________________________________
Tussenkoppen
Voeg waar mogelijk beschrijvende tussenkoppen toe aan lange transcripties.
Bijvoorbeeld:
Doel van de applicatie
Invoer via Excel
Criteria voor de planning
Capaciteit van workshops
Testen en fallback
Privacy en AVG
Planning en deadlines
Vervolgafspraken
Verander hiervoor de volgorde van het gesprek niet.
De transcriptie blijft chronologisch.
________________________________
3. Gestructureerde notulen
Maak de notulen niet door losse uitspraken simpelweg samen te vatten.
Analyseer eerst de volledige leesbare transcriptie.
Maak daarna zakelijke en concrete notulen.
Gebruik minimaal de volgende onderdelen:
Samenvatting
Een korte samenvatting van het doel en de belangrijkste uitkomsten van de vergadering.
Besproken onderwerpen
Per belangrijk onderwerp:

  *   onderwerp;
  *   belangrijkste informatie;
  *   relevante randvoorwaarden;
  *   eventuele conclusies.

Besluiten
Neem alleen iets op als besluit wanneer uit het gesprek redelijk duidelijk blijkt dat deelnemers ermee akkoord zijn gegaan.
Maak van een voorstel geen besluit.
Maak van een brainstorm geen besluit.
Eisen en wensen
Maak waar relevant onderscheid tussen:
Functionele eisen
Wat moet het systeem kunnen?
Wensen
Wat zou handig of prettig zijn, maar is nog geen harde eis?
Randvoorwaarden
Welke technische, organisatorische, juridische of praktische beperkingen zijn genoemd?
Actiepunten
Detecteer actief actiepunten.
Gebruik per actie:

  *   actie;
  *   eigenaar;
  *   deadline;
  *   status indien bekend.

Voorbeeld:
Actie
Eigenaar
Deadline
Status
Voorbeeldbestand met inschrijvingen toesturen
Marleen
Niet genoemd
Open
Testen met historische data
Ontwikkelteam
Voor 13 oktober
Open
Wanneer de eigenaar niet duidelijk is:
Eigenaar: Niet vastgesteld
Wanneer de deadline niet genoemd is:
Deadline: Niet vastgesteld
Zeg nooit "geen acties gevonden" voordat de volledige transcriptie hier expliciet op gecontroleerd is.
Deadlines en data
Zet concrete data apart.
Bijvoorbeeld:

  *   deadline inschrijvingen;
  *   geplande testdatum;
  *   point of no return;
  *   datum van evenement;
  *   vervolgafspraak.

Neem data letterlijk over uit het gesprek.
Bereken of verzin geen ontbrekende data.
Openstaande vragen
Neem zaken op die nog uitgezocht, besloten of bevestigd moeten worden.
Voorbeelden:

  *   maximum aantal deelnemers per workshop;
  *   minimum aantal deelnemers;
  *   definitieve lijst met workshops;
  *   aantal rondes;
  *   planning van scholen;
  *   privacyvoorwaarden.

Risico's
Neem concrete genoemde risico's op, zoals:

  *   applicatie werkt niet met echte data;
  *   te veel deelnemers;
  *   workshops vallen uit;
  *   gegevens voldoen niet aan het verwachte formaat;
  *   privacy- of AVG-problemen;
  *   wijzigingen komen te laat binnen.

Maak onderscheid tussen een daadwerkelijk vastgesteld probleem en een mogelijk risico.
________________________________
Belangrijke regels voor Gemma 3
De volgende regels moeten in de system prompt of vaste verwerkingsprompt staan.

  1.  Verzin nooit informatie.
  2.  Voeg geen besluiten toe die niet uit het gesprek blijken.
  3.  Voeg geen actiehouder toe wanneer niet duidelijk is wie verantwoordelijk is.
  4.  Voeg geen deadline toe wanneer deze niet genoemd is.
  5.  Corrigeer inhoud niet omdat iets volgens het model waarschijnlijk anders bedoeld zal zijn.
  6.  Scheid feiten uit het gesprek van interpretaties.
  7.  Bij twijfel expliciet aangeven dat iets onzeker is.
  8.  Behoud namen, getallen, data en technische termen zo nauwkeurig mogelijk.
  9.  Controleer de volledige transcriptie voordat acties, besluiten en deadlines worden bepaald.
  10. Een voorstel is niet automatisch een besluit.
  11. Een vraag is niet automatisch een actiepunt.
  12. Een wens is niet automatisch een eis.
  13. Een voorbeeld is niet automatisch een afspraak.
  14. Een grap is niet automatisch inhoudelijk relevant.
  15. Maak de tekst duidelijker zonder de betekenis te veranderen.

________________________________
Verwerking in meerdere stappen
Gemma 3 4B is een relatief klein model.
Probeer daarom niet de volledige verwerking met één enorme prompt uit te voeren als dat ten koste gaat van de kwaliteit.
Ontwerp bij voorkeur een pipeline.
Bijvoorbeeld:
Stap 1
Normaliseer de transcriptie.
Input:
ruwe transcriptie.
Output:
leesbare transcriptie.
Stap 2
Analyseer de leesbare transcriptie.
Extraheer gestructureerd:

  *   onderwerpen;
  *   besluiten;
  *   eisen;
  *   wensen;
  *   randvoorwaarden;
  *   acties;
  *   eigenaren;
  *   deadlines;
  *   openstaande vragen;
  *   risico's.

Gebruik indien mogelijk JSON als tussenformaat.
Voorbeeldstructuur:

{
  "topics": [],
  "decisions": [],
  "requirements": [],
  "wishes": [],
  "constraints": [],
  "actions": [
    {
      "action": "",
      "owner": null,
      "deadline": null,
      "evidence": ""
    }
  ],
  "dates": [],
  "open_questions": [],
  "risks": []
}

Het veld evidence moet een korte verwijzing bevatten naar het deel van de transcriptie waarop de conclusie gebaseerd is.
Dit veld hoeft niet per se in de uiteindelijke notulen zichtbaar te zijn, maar moet gebruikt kunnen worden voor controle en debugging.
Stap 3
Maak vanuit deze gestructureerde analyse de uiteindelijke notulen.
Stap 4
Voer een kwaliteitscontrole uit.
Controleer expliciet:

  *   zijn alle besluiten daadwerkelijk besproken?
  *   zijn voorstellen ten onrechte als besluit aangemerkt?
  *   zijn er gemiste actiepunten?
  *   hebben acties een correcte eigenaar?
  *   zijn deadlines daadwerkelijk genoemd?
  *   zijn eisen en wensen van elkaar onderscheiden?
  *   zijn openstaande vragen meegenomen?
  *   zijn er hallucinaties toegevoegd?
  *   komen namen en data overeen met het transcript?

Corrigeer gevonden problemen voordat het resultaat wordt opgeslagen.
________________________________
Lange vergaderingen
Houd rekening met transcripties die groter zijn dan de bruikbare context van Gemma 3 4B.
Bouw daarom indien nodig chunking in.
Eisen voor chunking:

  *   splits bij voorkeur op natuurlijke gespreksgrenzen;
  *   splits niet midden in een uitspraak;
  *   gebruik enige overlap tussen chunks;
  *   behoud sprekerinformatie;
  *   behoud timestamps indien aanwezig;
  *   analyseer eerst chunks;
  *   combineer daarna de resultaten;
  *   voer na samenvoegen een globale controle uit over de volledige vergadering.

Voorkom dat hetzelfde actiepunt door overlap dubbel wordt opgenomen.
________________________________
Promptbeheer
Zet deze instructies niet verspreid als losse strings door de code.
Maak een duidelijke centrale plek voor prompts, bijvoorbeeld:

  *   meeting_transcript_cleanup;
  *   meeting_analysis;
  *   meeting_minutes;
  *   meeting_quality_check.

Maak de prompts eenvoudig aanpasbaar.
Als Jarvis al een configuratiesysteem voor prompts heeft, gebruik dat.
________________________________
Ollama
Gebruik de bestaande Ollama-integratie.
Het standaardmodel voor deze verwerking is:
Gemma 3 4B.
Gebruik instellingen die geschikt zijn voor feitelijke transcriptieverwerking.
Creativiteit is hier niet gewenst.
Gebruik daarom een lage temperature, bijvoorbeeld rond 0.1 tot 0.2, als de bestaande Ollama-integratie dit ondersteunt.
Verander bestaande modelinstellingen alleen wanneer dat nodig is.
________________________________
Opslag
Bewaar indien de bestaande architectuur dit toestaat afzonderlijk:

  *   raw_transcript;
  *   cleaned_transcript;
  *   meeting_analysis;
  *   meeting_minutes.

Overschrijf de originele transcriptie nooit.
Als de database hiervoor aangepast moet worden, maak dan een nette migratie.
________________________________
Bestaande functionaliteit
Onderzoek eerst de huidige code.
Zoek uit:

  *   waar audio wordt getranscribeerd;
  *   waar transcripties worden opgeslagen;
  *   waar Ollama wordt aangeroepen;
  *   welke prompts nu gebruikt worden;
  *   waar samenvattingen en notulen worden gemaakt;
  *   hoe meetings in de database zijn opgeslagen;
  *   welke API-endpoints dit gebruiken;
  *   welke tests hiervoor bestaan.

Behoud bestaande functionaliteit en API-contracten waar mogelijk.
Maak geen grote architectuurwijzigingen wanneer een kleine wijziging voldoende is.
________________________________
Tests
Voeg tests toe.
Test minimaal:
Stopwoorden
Input:
"Ja nou ik denk eigenlijk dat we dat dan zeg maar morgen kunnen doen."
Verwachte strekking:
"Ik denk dat we dat morgen kunnen doen."
Onduidelijke herkenning
Het systeem mag een onzeker woord niet zelf verzinnen.
Besluit versus voorstel
"We zouden misschien volgende week kunnen testen."
mag niet als definitief besluit worden opgeslagen.
Actiepunt
"Marleen stuurt ons morgen het Excel-bestand."
moet worden herkend als:
actie: Excel-bestand toesturen
eigenaar: Marleen
deadline: morgen, gekoppeld aan de vergaderdatum indien het bestaande systeem relatieve data veilig omzet. Anders letterlijk "morgen" bewaren.
Geen eigenaar
"We moeten nog uitzoeken hoeveel deelnemers er maximaal in een workshop mogen."
moet een openstaande vraag of actie worden.
De eigenaar mag niet worden verzonnen.
Meerdere sprekers
Uitspraken van verschillende sprekers mogen niet worden samengevoegd.
Humor
Een lang niet-inhoudelijk zijpad mag in de leesbare transcriptie compact worden gemaakt, maar mag geen besluit of actie opleveren.
________________________________
Acceptatiecriteria
De wijziging is geslaagd wanneer:

  1.  de originele transcriptie behouden blijft;
  2.  iedere vergadering een leesbare transcriptie kan krijgen;
  3.  spreektaal duidelijker wordt zonder inhoudelijke vervorming;
  4.  sprekers behouden blijven;
  5.  lange bijdragen in leesbare alinea's worden verdeeld;
  6.  duidelijke transcriptiefouten voorzichtig worden gecorrigeerd;
  7.  onzekerheden niet door het model worden ingevuld;
  8.  notulen duidelijke onderwerpen bevatten;
  9.  besluiten worden onderscheiden van voorstellen;
  10. eisen worden onderscheiden van wensen;
  11. actiepunten actief worden gevonden;
  12. eigenaar en deadline niet worden verzonnen;
  13. concrete data correct worden behouden;
  14. openstaande vragen worden vastgelegd;
  15. risico's worden herkend;
  16. Gemma na verwerking een kwaliteitscontrole uitvoert;
  17. lange transcripties betrouwbaar kunnen worden verwerkt;
  18. bestaande vergaderingfunctionaliteit blijft werken.

________________________________
Werkwijze voor deze Codex-taak

  1.  Inspecteer eerst de bestaande repository en huidige vergaderingverwerking.
  2.  Beschrijf kort welke onderdelen je gaat wijzigen.
  3.  Implementeer de wijziging vervolgens volledig.
  4.  Gebruik bestaande conventies en architectuur van het project.
  5.  Voeg of wijzig tests.
  6.  Draai de relevante tests.
  7.  Los fouten op die door deze wijziging ontstaan.
  8.  Toon na afloop:
     *   gewijzigde bestanden;
     *   belangrijkste ontwerpkeuzes;
     *   gebruikte prompts;
     *   eventuele databasewijzigingen;
     *   testresultaten;
     *   punten die nog aandacht vragen.

Maak geen mock-implementatie.
Laat geen TODO's achter voor functionaliteit die binnen deze opdracht uitgevoerd kan worden.
Controleer ten slotte kritisch of de oplossing daadwerkelijk geschikt is voor een lokaal draaiend Gemma 3 4B model en niet afhankelijk is van de redeneercapaciteit van een veel groter cloudmodel.


Met vriendelijke groet,

O. Hardebol
o.hardebol@astrumcollege.nl
06-20462518

-----topdesk marker-----
Onno Hardebol
Docent
Media & ICT
o.hardebol@astrumcollege.nl
www.astrumcollege.nl
​ROC A12 sluit elke aansprakelijkheid uit voor een onjuist, onvolledig of ontijdig ontvangen e-mailbericht of van bijbehorende documenten, alsook voor het meezenden van virussen.
​
ROC A12 rejects any liability for improper, incomplete or delayed texts in or annexed to this e-mail or for damage resulting from texts or documents in or annexed to this e-mail affected by viruses.