Ich habe gerade für meinen Adapter eine ganz rudimentäres RAG (Retrieval-Augmented Generation [1] ) implementiert. Ich bin da jetzt kein Fachmann, aber das Potenzial ist enorm denke ich.

Man könnte damit ein LLM mit spezifischen und aktuellen Informationen aus den Dokus "füttern" und dann ein Helper Bot bereitstellen, der Fragen zum System, Adapter usw. beantworten kann.
Da es multilinguale Embedding Modelle gibt, ist der Bot automatisch mehrsprachig, auch wenn die Doku nur in englisch oder deutsch vorliegt.

Wenn da Grundsätzlich ein Interesse besteht könnte ich mal einen kleinen Prototypen schreiben.

Was ist der beste Weg programmatisch auf alle Doku Texte zuzugreifen?

[1] Ein RAG-System (Retrieval-Augmented Generation) ist ein KI-Framework, das die Vorteile von Informationsabruf (z.B. Suchmaschinen) mit der Fähigkeit von Large Language Models (LLMs) zur Textgenerierung kombiniert. Es ermöglicht LLMs, präzisere und kontextbezogenere Antworten zu geben, indem sie auf externe Wissensquellen zugreifen, anstatt sich nur auf ihre Trainingsdaten zu verlassen.

@iob69 ja, funktioniert einwandfrei!

@jey-cee du hast absolut recht. ich werde in der nächsten version die abhängigkeit von google entfernen!

Ich habe jetzt ein bisschen rumprobiert und habe nun folgendes Problem: Kleine und schnelle Embedding-Modelle sind ein- oder zweisprachig (meist Englisch + X). Ich müsste also eine Liste an Modellen pro Sprache bereitstellen. Es gibt auch mehrsprachige, freie Embedding-Modelle, die aber hohe Systemvoraussetzungen haben. Der Nutzer könnte nun zwischen kostenpflichtigen Diensten (Google, OpenAI...) oder freien, offenen Modellen (Hugging Face) wählen und dann noch zwischen kleinen, aber sprachspezifischen oder großen, mehrsprachigen Modellen, die aber hohe Systemanforderungen haben. Ich fürchte, dass das zu komplex für Nutzer wird. Außerdem wird natürlich beim Umstellen der Modelle jeweils ein kompletter Reindex fällig. Daher die Frage: Reicht erst mal Deutsch/Englisch? Oder welche Sprachen sind besonders wichtig?

@iob69 ja, funktioniert einwandfrei!

@longbow was heißt denn nie geklappt?

@ika bei mir macht der go-e charger das von alleine. ich übergebe einfach produktion, einspeisung und akkuladung (wobei pAkku optional ist)

let info = {"pGrid": -ex,"pPv":prod,"pAkku":bp} 
    //pGrid < 0 ==> Einspeisen, pAkku < 0 ==> Batterie laden, pPv > 0 ==> PV Produktion, pPv < 0 ==> Standby. 
    sendTo('mqtt.0', 'sendMessage2Client', {
        topic:"go-eCharger/262801/ids/set", 
        message: JSON.stringify(info)
    });

die ganze logik und anpassung der ladegeschwindigkeit kann der von Haus aus. In der go-e App laden auf eco stellen und PV-Überschuss auf an

@jey-cee du hast absolut recht. ich werde in der nächsten version die abhängigkeit von google entfernen!

@bloop so ein ähnliches Projekt mach ich auch gerade: https://github.com/Holger-Will/ioBroker.kiwi
vielleicht kann man da ja zusammen arbeiten.

@oliverio das geht schon, wenn man das als MCP-Server implementiert. dann kann das jeder in die KI seines vertrauens integrieren ob lokal oder als service ob google, athropic oder openai, egal. Das wäre auch ne gute ergänzung zu meinem MCP Server adpater. Müssten man nur mal schauen mit den embedding modellen, aber das kann man wie @Jey-Cee schon sagt dann auch lokal machen.
Wie wird denn die Doku erstellt bisher? da werden doch bereits alle Daten zusammengetragen, oder?

@oliverio ach super wenn das so klappt. ich lese mich da mal rein.

Und ja unit test ist vielleicht der falsche Begriff. Integration Test wäre wohl richtiger gewesen

@jey-cee ja, es wäre halt gut das automatisiert zu machen irgendwie.

@wcag22 Du hast recht, dass so ein Sytem nicht oder nicht immer den persönlichen Support ersetzt/ersetzen kann. Das heißt aber auch nicht das man das möchte. Ich sehe es als zusätzliches Werkzeug. Ob es den Aufwand wert ist, weiß ich auch nicht.
ich wollte das nur mal ausprobieren...