LLM ordnet Abfragewerte falschen Spalten in der Text-to-SQL-Pipeline zu (DuckDB + Qwen 2.5) ⇐ Python

[Anonymous]

Ich baue einen Chatbot-Assistenten für türkische Studenten mit DuckDB und Qwen 2.5 7B (Coder). Mein Arbeitsablauf ist: Benutzerfrage (TR) -> LLM -> SQL-Abfrage -> DuckDB -> Endgültige Antwort (TR).
Das Problem: Aufgrund der Einschränkungen des Kontextfensters kann ich nicht das vollständige Schema (600 Spalten) in das 7B-Modell einspeisen. Selbst wenn ich ein zusammengefasstes Schema bereitstelle, hat das Modell Probleme mit der Schemaverknüpfung. Es identifiziert den Wert, nach dem Benutzer fragen, korrekt, ordnet ihn jedoch der falschen Spalte zu.
Minimales Beispiel: Nehmen wir an, ich habe eine vereinfachte Schemastruktur wie diese:

• Code: Select all

  university_name

  (z. B. Stanford, MIT)

  Code: Select all

  program_name

  (z. B. Informatik, Biologie)

• Code: Select all

  city

  (z. B. Boston, Kalifornien)
• Benutzerfrage: „Welche Universität hat die beste Informatik-Abteilung?
• Erwartetes SQL:
  SQL

  Code: Select all

  SELECT * FROM view_one WHERE program_name ILIKE '%Computer Science%'
  
  

• Tatsächlich generiertes SQL (Der Fehler):
  SQL

  Code: Select all

  SELECT * FROM view_one WHERE university_name ILIKE '%Computer Science%'
  
  

Dinge, die ich ausprobiert habe:
1.RAG-Kontext: Ich rufe relevante Werte mithilfe einer Vektordatenbank (ChromaDB) ab, was die Entitätserkennung verbessert, aber die Zuordnung dieser Entitäten zur richtigen SQL-Spalte bleibt ein Problem.

• Spaltenbeschreibungen: Ich habe in der Systemeingabeaufforderung Beschreibungen für
  Schlüsselspalten hinzugefügt.
• Schema-Gruppierung: Ich habe versucht, das Schema in logische Gruppen aufzuteilen
  (z. B. „Grundlegende Informationen“, „Statistiken“), aber die dynamische Auswahl mit einem 7B-Modell
  war inkonsistent.
• Fuzzy-Matching: Ich habe Fuzzy-Matching implementiert, um Tippfehler zu behandeln, was
  bei der Werteabfrage hilft, aber die Logik der Spaltenauswahl
  nicht löst.

Meine Frage: Was ist bei großen Tabellen (mehr als 600 Spalten) der branchenübliche Ansatz für ein kleineres LLM (7B), um Werte zuverlässig den richtigen Spalten zuzuordnen? Sollte ich einen mehrstufigen Agenten verwenden (Router -> Schema Pruning -> SQL Generation) oder gibt es eine bessere Aufforderungstechnik?