patrick
9a24ea29e1
Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.
2.3 KiB
2.3 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| project-ollama-integration-plan | Plan für lokale Ollama-Anbindung (Metadaten-Vorschläge + OCR-Textkorrektur) in archivdms, Stand 2026-07-16 |
|
Plan verabschiedet für Ollama-Integration (kein Code, nur Architektur), Ziel: lokales LLM für (1) Metadaten-Vorschläge als dritter Provider neben heuristic/anthropic, (2) nachträgliche OCR-Textkorrektur.
Kernentscheidungen:
- Modell:
qwen2.5:1.5b-instruct-q4_K_M(~1-1.2GB RAM), Eskalation auf 3B nur falls Qualität nicht reicht. Server hat nur 4GB RAM/4 Kerne/keine GPU. - systemd-Hardening: MemoryMax=2200M, CPUQuota=250%, OOMScoreAdjust=500, bindet nur an 127.0.0.1:11434.
- OCR-Korrektur läuft NICHT automatisch im Upload-Pipeline (Ressourcenrisiko), sondern über manuellen Endpoint
POST /api/documents/{id}/correct-ocr-text, analog zu bestehendem/reprocess-Muster. - GoBD: Original-OCR-Text (
ocr_text) wird nie überschrieben, Korrektur landet in neuem Feldocr_text_corrected, Audit-Log-Pflicht pro Korrekturlauf. - Provider-Fehlerverhalten: bei Ollama nicht erreichbar → Fehler an Frontend, KEIN stiller Fallback auf heuristic (Nachvollziehbarkeit, welcher Provider geantwortet hat).
- Config-Pattern:
llm.ollama.enabled/base_url/model/timeout_secondsin config.yml, no-op wenn disabled — exakt wieindex.manticore_dsn-Pattern. - Pro-Tenant-Schalter bewusst NICHT gebaut (Tag 1) — Ollama läuft als ein Prozess pro Server, kein echtes Isolationsmodell dahinter, wäre nur Schein-Kontrolle. Erst bei echter Mandantentrennung mit unterschiedlichen Compliance-Anforderungen nachrüsten.
- Reihenfolge: 1) Ollama-Server-Setup (devops-deploy), 2) Metadaten-Provider (backend-dev), 3) OCR-Korrektur-Endpoint (baut auf Client aus Schritt 2 auf, plus Migration für ocr_text_corrected-Spalte).
Why: User hat sich bewusst für kleines lokales Modell trotz 4GB-RAM-Warnung entschieden (GoBD/Datenschutz — Belege dürfen Server nicht verlassen), Provider-Abstraktion (metadata_suggestions.provider-Spalte) existierte schon konzeptionell aus früherer Session, nur heuristic war je gebaut.
How to apply: Wenn Umsetzung (backend-dev/devops-deploy) ansteht, diesen Plan als Grundlage nehmen, nicht neu verhandeln, außer der User ändert explizit etwas. Verwandt: project_archivdms_status, project_nil_slice_json_pattern.