Vorschlag: Lokale KI-Schnittstelle für SoftMaker Office

[mxk]

Viele Nutzer – insbesondere in sensiblen Bereichen wie Behörden oder KMUs – möchten von KI profitieren, ohne dabei Daten in externe Cloud-Dienste hochladen zu müssen. Die Idee wäre, dass SoftMaker lediglich das Frontend und die Anbindung bereitstellt. Das eigentliche Modell und die Rechenleistung würden vom Nutzer bereitgestellt – lokal oder innerhalb der eigenen Infrastruktur.

SoftMaker Office (auch Standard, nicht nur NX) könnte eine lokale KI-Integration unterstützen, beispielsweise über:
- Ollama (lokale LLMs auf dem eigenen Rechner oder im LAN)
- OpenAI-kompatible Backends (lokale Server, Docker-Container, On-Premise-Lösungen)

Eine lokale KI-Option hätte folgende Vorteile:
- Datensicherheit: Dokumente und Daten bleiben vollständig in der eigenen Infrastruktur.
- Flexibilität: KI-Funktionen wie Textvorschläge, Übersetzungen oder Zusammenfassungen wären dennoch nutzbar.
- Abgrenzung vom Wettbewerb: Viele Anbieter setzen bisher auf Cloud-Modelle. Eine lokale KI-Schnittstelle würde SoftMaker klar als innovative Alternative positionieren.
- Keine zusätzlichen API-Kosten für SoftMaker: Die Rechenlast und Infrastruktur wird vom Nutzer bereitgestellt (z.B. eigener PC, Server, NAS, Docker). SoftMaker spart die Kosten für KI-Server oder Token-Nutzung bei externen Cloud-Anbietern.
- Auch wenn ein solches Feature vor allem Power-User und technisch versierte Nutzer anspricht, könnte es dennoch einen großen Einfluss auf die Wahrnehmung der gesamten Produktlinie haben, wenn diese User eine große Öffentlichkeitswirkung haben (Multiplikatoren in Unternehmen und Behörden, Aktiv in Foren, sozialen Medien, Blogs oder Plattformen wie Reddit, Personen, die häufig Empfehlungen aussprechen: „Probiert mal SoftMaker aus, die können KI auch lokal.“)

Konkret könnte Softmaker-Office die Einrichtung einer konfigurierbare KI-Schnittstelle mit einem eigenen KI-Endpunkt unterstützen:
- Eingabe einer URL für den KI-Server (z.B. http://localhost:11434/v1/chat/completions oder eine LAN-Adresse).
- Auswahl des API-Typs (z.B. OpenAI-kompatibel).
- Optionale Authentifizierung (API-Key oder Token).
- Einstellbare Basisparameter (Modellname, maximale Tokens, Temperatur etc.).
Die bestehenden Cloud-basierten KI-Funktionen in SoftMaker Office NX könnten natürlich parallel bestehen bleiben. Die lokale KI-Option wäre einfach eine zusätzliche Möglichkeit. In der Standard-Version (ohne NX) wäre dies dann eben die einzige Möglichkeit, KI-Funktionen zu nutzen.

[makeitsoft]

Finde ich eine gute Idee. Angesichts der Tatsache, dass SoftMaker mit DSGVO-Konformität wirbt, ist ChatGPT vielleicht nicht die beste Wahl.

Vielleicht könnte man die KI-Funktionen auch in Plugins auslagern, die auf unterschiedliche Anbieter zugeschnitten sind, z.B. ChatGPT (aktuelle Funktion), Claude, Lumo, lokaler Anbieter. Ich könnte mir vorstellen, dass je nach Anbieter / Modell unterschiedliche Anwendungslogiken sinnvoll sind, und diese kann man dann in den Plugins abbilden.

[SuperTech]

Vielen Dank für den Vorschlag. Leider scheint dies technisch nicht machbar zu sein, sodass eine Umsetzung sehr unwahrscheinlich ist. Ich habe Ihren Verbesserungsvorschlag dennoch weitergeleitet…

[mxk]

Ich verstehe das so: SoftMaker Office NX verschickt KI-Anfragen bereits heute im OpenAI-Format: ein JSON-Objekt mit Nutzertext, Modellname und Parametern, per HTTP-POST an eine feste Gegenstelle. Die Antwort kommt im gleichen Format zurück und wird ausgelesen.
Die Adresse dieser Gegenstelle ist eine URL, die derzeit fest im Programm hinterlegt ist: https://api.openai.com/v1

Die Adresse für ein lokales Ollama oder LM Studio lautet z.B.: http://localhost:11434/v1. Der Rest ist identisch. Request-Format, Antwortstruktur, Authentifizierungsweg – alles unverändert. Es unterscheidet sich ausschließlich der Host-Teil der Adresse. Daher ist mein Vorschlag, die URL nicht als Konstante im Code zu führen, sondern aus den Programmeinstellungen zu lesen.

Dazu werden in den Optionen drei Eingabefelder benötigt – Basis-URL, Modellname, optionaler API-Key – vorbelegt mit den bisherigen Werten. Wer nichts ändert, merkt keinen Unterschied. Der bestehende HTTP-Client, der JSON-Serializer, der Response-Parser und die Fehlerbehandlung bleiben vollständig erhalten. Keine neue Protokollimplementierung, kein eigenes Modell, keine Rechenleistung seitens SoftMaker. Gewünscht ist allein, dass die Zieladresse konfigurierbar statt fest verdrahtet ist. Ein geringfügig aufwändigere Stufe wäre, mehrere Endpunkte hinterlegbar und auswählbar zu machen.

Mir ist bewusst dass lokale Modelle oft vergleichsweise "schwach" ausfallen. Aber gerade im Textbereich können Sie am ehesten ihre Stärken ausspielen. Und gerade dort ist auch der Datenschutz ein größeres Problem. Ich könnte mir vorstellen, dass größere Firmen aus Datenschutzgründen in Zukunft solche einfachen Aufgaben über eigene interne KI-Server (mit auf Deutsch spezialisierten Modellen) abdecken wollen werden. Ich würde mich freuen, wenn die Einschätzung noch einmal überprüft werden könnte. Es ist klar, dass SoftMaker die Verantwortung an der API-Schnittstelle abgeben würde und die Auswahl und Installation der lokalen Modelle und Frameworks und die Sicherstellung der Antwortqualität nicht unterstützen kann.