LLMs nutzen, ohne Geld zu verbrennen – verschiedene Datenbankabfragestrategien

Die anhaltende Konvergenz von KI-Technologien und Gesundheitssystemen hat viele überzeugende Fortschritte hervorgebracht. Lassen Sie uns die Bühne bereiten. Wenn Sie mit dynamischen Modellen wie ChatGPT interagiert haben, haben Sie möglicherweise, wie viele von uns, begonnen, sich deren Anwendung unter Verwendung Ihrer einzigartigen Datensätze vorzustellen. Angenommen, Sie möchten diese Technologie im Gesundheitswesen mit elektronischen Gesundheitsakten (EHR) oder elektronischen Krankenakten (EMR) verknüpfen oder streben eine verbesserte Interoperabilität mithilfe der Ressourcen von FHIR an.  Alles läuft darauf hinaus, wie wir Kontextdaten zu/von LLMs übertragen/empfangen, die auf dem Markt verfügbar sind.

Genauere Techniken umfassen die Feinabstimmung und das Training von LLMs ausschließlich mit den Kontextdatensätzen. Allerdings kostet es heute Millionen von Dollar, dies zu erreichen. Die andere Möglichkeit besteht darin, LLMs über einmalige oder wenige Abfragen mit Kontext zu versorgen und eine Antwort zu erhalten. Dies kann beispielsweise durch das Generieren von SQL-Abfragen, das Generieren von Code zum Abfragen/Parsen, das Durchführen von Aufrufen mit Informationen aus API-Spezifikationen usw. erreicht werden. Es besteht jedoch das Problem eines hohen Token-Verbrauchs und einige dieser Antworten sind möglicherweise nicht immer korrekt.

Hier gibt es keine einheitliche Lösung, aber das Verständnis der Vor- und Nachteile dieser Techniken kann bei der Entwicklung Ihrer eigenen Strategie hilfreich sein. Auch die Nutzung guter technischer Praktiken (wie Caches, Sekundärspeicher) und die Konzentration auf die Problemlösung können dabei helfen, ein Gleichgewicht zwischen den verfügbaren Methoden zu finden. Dieser Beitrag ist ein Versuch, einige Strategien zu teilen und sie anhand verschiedener Kennzahlen zu vergleichen.

SQL-Abfragen generieren

Erstens haben wir die konventionellere Methode – Laden und Analysieren der SQL-Datenbankstruktur und Beispielinhalte über LangChain und Ausführen von GPT-Abfragen. Diese Methode ermöglicht nachweislich eine effiziente und dynamische Kommunikation mit unseren Gesundheitssystemen und gilt als bewährte Technik in unserer Branche.

Es gibt Lösungen, die nur die Datenbankstruktur (z. B. Tabellenschema) weitergeben, und andere, die einige redigierte Daten weitergeben, um dem LLM bei der Generierung genauer Abfragen zu helfen. Die erstere Lösung hat den Vorteil einer festen Token-Nutzung und vorhersehbarer Kosten, leidet jedoch unter Genauigkeit, da sie nicht vollständig kontextbewusst ist. Die letztere Lösung ist möglicherweise tokenintensiver und erfordert besondere Sorgfalt bei Anonymisierungstechniken.  Diese Lösungen könnten für einige Anwendungsfälle perfekt sein, aber könnte es eine optimalere Strategie geben?

Verwendung von LLMs zum Generieren von Code zum Navigieren durch APIs und Datenbankabfragen

Eine weitere ausgefeilte Technik besteht darin, die LLMs Code generieren zu lassen, um eine Frage in mehrere Abfragen oder API-Aufrufe aufzuteilen. Dies ist eine sehr natürliche Methode zur Lösung komplizierter Fragen und setzt die Kraft der Kombination natürlicher Sprache und zugrunde liegenden Codes frei.

Diese Lösung erfordert ein gutes Prompt-Engineering und eine Feinabstimmung der Vorlagen-Prompts, um für alle Eckfälle gut zu funktionieren. Die Integration dieser Lösung in einen Unternehmenskontext kann aufgrund der Unsicherheiten bei der Token-Nutzung, der sicheren Codegenerierung und der Kontrolle der Grenzen dessen, was durch den generierten Code zugänglich ist und was nicht, eine Herausforderung darstellen. Aber in ihrer Gesamtheit ist die Fähigkeit dieser Technik, autonom zur Lösung komplexer Probleme zu agieren, faszinierend und wir können uns auf weitere Fortschritte in diesem Bereich freuen.

OpenAPI-Spezifikationen als Kontext für LLMs laden

Unser Team wollte einen anderen Ansatz zur Kontrolle der Token-Nutzung ausprobieren, aber auch den verfügbaren Kontext nutzen, um genaue Ergebnisse zu erhalten. Wie wäre es mit der Verwendung von LangChain zum Laden und Analysieren der OpenAPI-Spezifikationen von FHIR? OpenAPI stellt sich als wirkungsvolle Alternative dar, die mit adaptiven und standardisierten Verfahren ausgestattet ist und die Bedeutung der umfassenden API-Standards von FHIR bestätigt. Sein entscheidender Vorteil liegt in der Förderung des mühelosen Datenaustauschs zwischen verschiedenen Systemen. Die Kontrolle liegt hier darin, die Spezifikationen selbst ändern zu können und nicht die Eingabeaufforderungen oder generierten Ausgaben des LLM.

Stellen Sie sich das Szenario vor: Eine POST-API führt alle erforderlichen Validierungsprüfungen durch, bevor Daten zur Datenbank hinzugefügt werden. Stellen Sie sich nun vor, dieselbe POST-API zu nutzen, jedoch eine Methode in natürlicher Sprache zu verwenden. Es führt immer noch die gleichen strengen Kontrollen durch, um Konsistenz und Zuverlässigkeit zu gewährleisten. Diese Art von OpenAPI vereinfacht nicht nur die Interaktion mit Gesundheitsdiensten und -anwendungen, sondern verbessert auch die Verständlichkeit der API, sodass sie leicht verständlich und vorhersehbar sind.

Wir sind uns darüber im Klaren, dass diese Lösung nicht die gleiche Leistung bietet wie die autonome Aufteilung von Aufgaben oder die Generierung von Code. Ziel ist es jedoch, zu einer praktischeren Lösung zu gelangen, die schnell an die meisten Anwendungsfälle angepasst werden kann.

Vergleich

Während alle diese Techniken einzigartige Vorteile und das Potenzial für unterschiedliche Zwecke aufweisen, lassen Sie uns ihre Leistung anhand einiger Kennzahlen bewerten.

1. Zuverlässigkeit – OpenAPI legt aufgrund unserer Allianz mit KI Wert auf Zuverlässigkeit und hat aufgrund der Nutzung standardisierter APIs einen Vorteil. Dies gewährleistet einen eingeschränkten unbefugten Zugriff und eine präzise Benutzerauthentifizierung für bestimmte Daten und bietet eine höhere Datensicherheit im Vergleich zur Weitergabe von KI-generiertem SQL für den Datenbankzugriff – eine Methode, die möglicherweise Bedenken hinsichtlich der Zuverlässigkeit aufwerfen könnte.

2. Kosten – Die Effizienz der von FHIR definierten Filterfunktionen der API spielt eine Rolle bei der Kostenreduzierung. Dies ermöglicht die Abwicklung nur notwendiger Daten, die durch intensives Prompt-Engineering optimiert werden, im Gegensatz zu herkömmlichen DBs, die möglicherweise mehr Datensätze als nötig zurückgeben, was zu unnötigen Kostensteigerungen führt.

3. Leistung – Die strukturierte und standardisierte Darstellung von Daten durch OpenAPI-Spezifikationen trägt oft zu besseren Ausgabeergebnissen von GPT-4-Modellen bei und steigert die Leistung. Allerdings können SQL-Datenbanken bei direkten Abfragen Ergebnisse schneller zurückgeben. Es ist wichtig, das Potenzial von Open API für eine Überinformierung aufgrund der Definition von mehr Parametern zu berücksichtigen, als für eine Abfrage erforderlich sein könnten.

4. Interoperabilität – OpenAPI-Spezifikationen glänzen, wenn es um Interoperabilität geht. Da sie plattformunabhängig sind, passen sie perfekt zur Mission von FHIR, die Interoperabilität im Gesundheitswesen zu fördern und eine kollaborative Umgebung für die nahtlose Synchronisierung mit anderen Systemen zu fördern.

5. Implementierung und Wartung – Obwohl es vergleichsweise einfacher sein kann, eine Datenbank auszugliedern und der KI den Kontext für die Abfrage bereitzustellen, scheint die SQL-Datenbanklademethode mit ihrer schlanken Kontrollschicht einfacher zu implementieren zu sein, die OpenAPI-Spezifikationen Sobald sie beherrscht werden, bieten sie Vorteile wie Standardisierung und einfachere Wartung, die den anfänglichen Lern- und Ausführungsaufwand überwiegen.

6. Skalierbarkeit und Flexibilität – SQL-Datenbanken erfordern ein starres Schema, das Skalierbarkeit und Flexibilität möglicherweise nicht problemlos zulässt. Im Gegensatz zu SQL bietet OpenAPI eine anpassungsfähigere und skalierbarere Lösung und ist damit eine zukunftsfreundliche Alternative.

7. Ethik und Bedenken – Ein wichtiger, aber komplexer Faktor, den es angesichts des schnellen Wachstums der KI zu berücksichtigen gilt. Wäre es für Sie kein Problem, Kunden direkten DB-Zugriff zu gewähren, auch mit Filtern und Authentifizierung? Denken Sie über die Bedeutung von Datende-Identifikatoren für die Gewährleistung der Privatsphäre im Gesundheitswesen nach. Obwohl sowohl OpenAPI- als auch SQL-Datenbanken über Mechanismen verfügen, um diese Bedenken auszuräumen, fügt die inhärente Standardisierung von OpenAPI eine zusätzliche Sicherheitsebene hinzu.

Während diese Diskussion Einblicke in einige der zu berücksichtigenden Schlüsselfaktoren bietet, ist es wichtig zu erkennen, dass die Wahl zwischen SQL, Codegenerierung und OpenAPI vielfältig ist und von den spezifischen Anforderungen Ihrer Projekte und Organisationen abhängt.

Bitte teilen Sie uns gerne Ihre Gedanken und Ansichten zu diesem Thema mit – vielleicht haben Sie weitere Anregungen oder möchten einige Beispiele nennen, die für Ihren Anwendungsfall am besten funktioniert haben.

Das obige ist der detaillierte Inhalt vonLLMs nutzen, ohne Geld zu verbrennen – verschiedene Datenbankabfragestrategien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!