Ich war erfreut, nachdem ich während des Hacktoberfests zu verschiedenen Repositories beigetragen hatte, aber sobald das Hacktoberfest stattfand, verspürte ich eine neue tiefe Begeisterung, zu mehr Open-Source-Projekten beizutragen. Ich hatte an vielen Projekten mitgewirkt, die über einen Tech-Stack verfügten, der sowohl Backend als auch Fronted umfasste, aber dieses Mal wollte ich zu einem KI-basierten Projekt beitragen, insbesondere zu etwas, das mit RAG (Retrieval Augmented Generation) zu tun hat, wo ich mich vertiefen wollte hinein
Auf der Suche nach vielen Repos, die auf RAG basieren, bin ich auf ein perfektes Open-Source-RAG-Tool gestoßen, ORAssistant, bei dem es sich wiederum um einen Chatbot handelt, der auf häufige Fragen oder Anfragen für ein größeres Projekt antwortet.
Die Architektur dieses Tools ist ziemlich komplex. Ich versuche immer noch herauszufinden, wie die Hauptabfragearchitektur funktioniert, aber das ist der spannende Teil, ich lerne, während ich dazu beitrage.
Bei meiner ersten Ausgabe habe ich eines der Probleme aufgegriffen, bei dem die Aufgabe darin bestand, die Feedbackschleife zu automatisieren. In Leyman-Begriffen bedeutet dies, dass eine RAG-App normalerweise auf das Feedback des Benutzers angewiesen ist, um sie weiter zu verfeinern Als Antwort bestand die Aufgabe darin, dieses Feedback vom Benutzer einzuholen, es in einer Datenbank zu speichern und es an das Modell selbst zurückzugeben
Die Architektur würde in etwa so aussehen
Derzeit speichert das System das Feedback in Google Sheets, was wiederum kein optimierter Ansatz ist
Dieses Problem allein würde etwa 4–5 PRs erfordern, um gelöst zu werden, aber für den Fokus dieses Blogs werde ich es auf die erste PR beschränken, die ich erstellt habe.
Für die erste Pull-Anfrage bestand meine Aufgabe, wie aus den Diskussionen zu diesem Problem hervorgeht, zunächst darin, das Datenbankdesign einzurichten und zum Laufen zu bringen. Dabei bin ich auf viele Probleme gestoßen
Die Lösung, die ich für diese PR vorgeschlagen hatte, drehte sich um die Diskussion über die Auswahl der richtigen Datenbank. Nach einer ausführlichen Diskussion mit dem Betreuer entschieden wir, dass es am besten sei, MongoDB für das Projekt zu verwenden, und dachten dabei über Skalierbarkeit und Flexibilität nach die Felder aufgrund der schemalosen Natur von MongoDB.
Nachdem ich das erste Design erstellt hatte, eröffnete ich eine PR, die sich auf die anfängliche Designeinrichtung für das Frontend bezog
Eines der Probleme bei der Zusammenführung bestand darin, dass es einen Test in der CI-Pipeline nicht bestanden hat, was nicht mit einem Fehler in meinem Code zusammenhing, sondern damit, dass einige Repository-Geheimnisse nicht weitergegeben wurden zum Fork des Repositorys, an dem ich gearbeitet habe, also musste der Betreuer mir Schreibzugriff auf das Repo gewähren, um meine PR zusammenzuführen
Diese PR würde nun als Grundlage für weitere PRs dienen, die letztendlich das gesamte Problem lösen würden. Um ehrlich zu sein, ist dies eines der besten Projekte, an denen ich seit langem gearbeitet habe. Ich brauche etwa 6-7 PRs, um nur ein Problem zu lösen. Das zeigt, wie komplex und entwickelt das Projekt ist.
Ich genieße es wirklich, wie sich meine Open-Source-Reise entwickelt.
Das obige ist der detaillierte Inhalt vonMitwirken bei ORAssistant. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!