Aime/docs/09-suche-und-verwaltung.md

09 — Inhaltssuche, Papierkorb, Titel umbenennen

Drei Funktionen, die am 2026-07-31 dazukamen. Die Suche ist der große Teil, die anderen beiden sind kleine Ergänzungen an derselben Datenschicht.

Titel nachträglich umbenennen

PATCH /api/recordings/:id/title. Der Stift steht in der Aufnahmeliste und im Detailkopf.

Der eigentliche Punkt ist die Spalte recordings.title_locked: sobald ein Titel von Hand gesetzt wurde, darf die nächste KI-Analyse ihn nicht mehr überschreiben. Ohne diese Sperre hätte ein „↻ Analyse neu" den selbst vergebenen Namen still wieder gegen einen LLM-Vorschlag getauscht.

-- db.js/updateAnalysis
UPDATE recordings SET title = CASE WHEN title_locked=1 THEN title ELSE COALESCE(?,title) END, ...

Ein leeres Feld löscht den Titel und die Sperre — danach darf die KI wieder benennen.

Papierkorb (30 Tage)

Löschen setzt nur noch recordings.deleted_at. Nichts wird angefasst: Wörter, Marker, Passagen und die WAV/MP3-Dateien bleiben liegen, damit eine Wiederherstellung vollständig ist und nicht halb.

flowchart LR
  A[Aufnahme sichtbar<br/>deleted_at IS NULL] -->|"🗑 Löschen"| B[Papierkorb<br/>deleted_at = jetzt]
  B -->|"↩︎ Wiederherstellen"| A
  B -->|"✕ Endgültig (manuell)"| C[purgeRecording]
  B -->|"Aufräumlauf: älter als 30 Tage"| C
  C --> D["DELETE markers + words + passages<br/>DELETE recordings<br/>unlink wav + mp3"]

Der Aufräumlauf (sweepTrash in server.js) startet beim Boot und danach täglich. Der Boot-Lauf ist nötig, weil das Board oft tagelang aus ist — ein reiner 24-Stunden-Timer würde das Fenster immer wieder verpassen.

Altfehler mitbehoben: das frühere deleteRecording löschte nur markers und die recordings-Zeile. Die words-Zeilen blieben verwaist in der Datenbank zurück und die Audiodateien für immer auf der Karte. purgeRecording räumt jetzt beides mit ab.

Retention über AIME_TRASH_DAYS einstellbar (Vorgabe 30).

Inhaltssuche

Aufbau

flowchart TD
  Q["Frage:<br/>„Welches Projekt hat X letzte Woche vorgestellt?“"] --> DR[parseDateRange<br/>deterministisch, kein LLM]
  Q --> CT[contentTerms<br/>Stoppwörter raus]
  DR -->|"Filter: 20.–27.07."| SEL
  CT -->|"Projekt, X, vorgestellt"| SEL

  subgraph SEL["Kandidaten + Bewertung (SQL, Millisekunden)"]
    FT["Volltext<br/>BOOLEAN = Auswahl<br/>NATURAL LANGUAGE = Wertung (IDF)"]
    VP["Passage-Embedding<br/>Kosinus, min-max"]
    VD["Dokument-Embedding<br/>Titel + Zusammenfassung"]
  end

  SEL --> SC["score = 0,45·ft + 0,25·vec + 0,30·doc<br/>+ Sprecher + Wortgruppe + Aktualität"]
  SC --> HITS["Trefferliste sofort<br/>Meeting · Sprecher · mm:ss"]
  HITS --> LLM["Qwen3-4B über die Top-8<br/>~140 s, wird nachgereicht"]
  LLM --> ANS["Antwort mit Belegen [1] [2]"]

Die Zweiteilung ist Absicht: die Trefferliste kommt aus SQL und steht sofort, die formulierte Antwort braucht auf dieser NPU ~140 s. Erst antworten und dann anzeigen hieße eine Minute Leerlauf.

Passagen

Eine Passage ist die Sucheinheit: 2–4 Sätze eines Sprechers, ~420 Zeichen, harte Grenze 700. Sie wird aus den words-Zeilen geschnitten, nicht aus transcript_clean — nur die Wörter tragen Zeitstempel, und der Zeitstempel ist der ganze Zweck eines Treffers. Ein Sprecherwechsel beendet eine Passage immer.

Stand 2026-07-31: 22 Aufnahmen → 1689 Passagen (Neuaufbau in ~1 s ohne, ~9 min mit Embeddings).

Warum hybrid — mit Messwerten

Keine der beiden Ebenen genügt allein, und beide Grenzen sind an diesem Korpus gemessen:

Frage	Volltext	Semantisch
Steueroptimierung	0 Treffer — im Transkript steht eine andere Wortform	findet #71, vec=0,92
Wie können wir Steuern sparen	trifft über „Steuern"	bestätigt #71
OneDrive	21 Treffer, exakt	Eigennamen verwischen im Embedding

Bekannte Grenze der semantischen Ebene

multilingual-e5-small trennt auf verrauschtem ASR-Text schwach. Gemessen für „Wie werden unsere Daten gesichert" über alle 1689 Passagen:

Kosinus-Spanne der Kandidaten:  0,8085 .. 0,8560   (Breite nur 0,047)

cos=0,8560  #77  „Vielleicht packen wir nochmal eine Agenda zusammen…“   ← irrelevant, Rang 1
cos=0,8419  #85  „…jeden Abend um 11 Uhr der Backup-Job startet.“        ← die Antwort, Rang 5

Das Embedding selbst rankt also falsch; keine Normalisierung repariert eine falsche Reihenfolge. Grund ist vermutlich, dass die ASR Komposita zerbricht („Backup -Job", „KI -Binnenstrich") — genau das, womit ein Embedding am schlechtesten umgeht.

Zwei Gegenmaßnahmen sind drin und messbar wirksam, lösen den Fall aber nicht ganz:

1. Dokument-Ebene (recordings.doc_vec): Titel + Zusammenfassung sind saubere LLM-Prosa statt ASR-Rauschen. Sagt „diese Aufnahme passt zur Frage", auch wenn keine einzelne Passage gut einbettet.
2. IDF-Wertung: Kandidaten per BOOLEAN MODE auswählen, aber mit NATURAL LANGUAGE MODE bewerten. Boolean gewichtet nicht nach Seltenheit, weshalb eine Passage, die „Daten" mehrfach wiederholt, die Passage schlug, die „gesichert" tatsächlich beschreibt.

Ergebnis für den schwierigen Fall: die richtige Passage steht auf Rang 11 von 296 statt gar nicht — sie ist auffindbar, erreicht aber die Top-8 nicht, die das LLM zu sehen bekommt. Nächster Hebel wäre multilingual-e5-base (~1,1 GB statt 470 MB, Neuindexierung ~25–30 min).

Relative Datumsangaben

„letzte Woche" wird deterministisch aufgelöst, nicht vom LLM: ein falsches Kalenderfenster ist schlimmer als gar kein Filter, und Datumsarithmetik ist genau das, was ein 4B-Modell subtil falsch macht. Wochen laufen Montag–Sonntag. Der erkannte Datumsausdruck wird aus den Suchbegriffen entfernt — sonst sucht die Anfrage nach dem Wort „Woche".

Wenn nur ein Zeitraum und kein Suchbegriff übrig bleibt („Was lief letzte Woche?"), zeigt die Suche die Aufnahmen dieses Zeitraums ab ihren Eröffnungspassagen statt einer leeren Seite.

Embedding-Modell

/opt/aime-models/e5-small/ — model.onnx (470 MB, fp32), tokenizer.json, config.json, geladen von intfloat/multilingual-e5-small. Läuft über inference/embed_text.py als Daemon auf onnxruntime/CPU, taskset -c 0-3 (A55), damit die A76-Kerne für whisper und sherpa frei bleiben.

Bewusst ohne sentence-transformers: das zöge torch + transformers (~2 GB) auf eine Karte, auf der bereits whisper, sherpa und ein 5-GB-LLM liegen. tokenizers und onnxruntime waren für den NPU-Pfad ohnehin schon im venv.

Die e5-Präfixe query: und passage: sind Pflicht — ohne sie verliert das Modell deutlich an Genauigkeit, weil genau dieses asymmetrische Paar kurze Fragen auf lange Passagen abbildet.

Ohne das Modell degradiert die Suche sauber auf reinen Volltext (emb.available() ist dann false), sie fällt nicht aus. Das war die Voraussetzung dafür, die Suche vor dem Download in Betrieb zu nehmen.

Wann neu indexiert wird

Auslöser	Umfang
Analyse einer Aufnahme fertig	diese Aufnahme (nach relabelAnalysis, damit die Sprechernamen stehen)
Sprecher umbenannt	diese Aufnahme (speaker_name liegt denormalisiert in passages)
Dienststart	alle Aufnahmen ohne Passagen (Nachzügler)
POST /api/search/reindex {"force":true}	alles

API

Route	Zweck
PATCH /api/recordings/:id/title	Titel setzen/löschen
DELETE /api/recordings/:id	in den Papierkorb
GET /api/trash	Inhalt + Resttage
POST /api/trash/:id/restore	wiederherstellen
DELETE /api/trash/:id	endgültig löschen (inkl. Dateien)
GET /api/search?q=	Trefferliste, sofort
POST /api/search/answer	formulierte Antwort mit Belegen (NPU-Warteschlange)
GET /api/search/status	Passagen, davon eingebettet, Modell da?
POST /api/search/reindex	Index neu bauen ({"force":true} = alles)

Stellschrauben

Variable	Vorgabe	Wirkung
AIME_TRASH_DAYS	30	Aufbewahrung im Papierkorb
AIME_PASSAGE_CHARS	420	Ziellänge einer Passage
AIME_SEARCH_TOPK	20	Treffer je Suche
AIME_ANSWER_PASSAGES	8	Passagen für die LLM-Antwort (5 ≈ 90 s statt 140 s)
AIME_EMB_DIR	/opt/aime-models/e5-small	Embedding-Modell

Dateien

app/search.js (neu), app/emb.js (neu), app/inference/embed_text.py (neu), app/db.js, app/server.js, app/web/src/main.js, app/web/src/style.css. Backups auf dem Board: .bak-search.