LLM сопоставляет значения запроса неправильным столбцам в конвейере преобразования текста в SQL (DuckDB + Qwen 2.5) ⇐ Python

[Anonymous]

Я создаю чат-бота-помощника для турецких студентов, используя DuckDB и Qwen 2.5 7B (Coder). Мой рабочий процесс: Вопрос пользователя (TR) -> LLM -> SQL-запрос -> DuckDB -> Окончательный ответ (TR).
Проблема: Из-за ограничений контекстного окна я не могу передать полную схему (600 столбцов) в модель 7B. Даже когда я предоставляю обобщенную схему, в модели возникают проблемы с связыванием схем. Он правильно определяет значение, которое запрашивают пользователи, но сопоставляет его с неправильным столбцом.
Минимальный пример: Допустим, у меня есть такая упрощенная структура схемы:

• Код: Выделить всё

  university_name

  (например, Стэнфорд, Массачусетский технологический институт)

  Код: Выделить всё

  program_name

  (например, информатика, биология)

• Код: Выделить всё

  city

  (например, Бостон, Калифорния)
• Вопрос пользователя: «В каком университете лучший факультет компьютерных наук?»
• Ожидаемый SQL:
  SQL

  Код: Выделить всё

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

• Фактический сгенерированный SQL (ошибка):
  SQL

  Код: Выделить всё

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

Что я пробовал:
1.RAG Контекст: я получаю соответствующие значения с помощью векторной базы данных (ChromaDB), что улучшает распознавание объектов, но сопоставление этих объектов с правильным столбцом SQL остается проблемой.

• Описания столбцов: я добавил описания в системную подсказку для
  ключевых столбцов.
• Группировка схемы: я пробовал разбить схему на логические группы
  (например, «Основная информация», «Статистика»), но динамический выбор с помощью модели 7B
  оказался непоследовательным.
• Нечеткое сопоставление: я реализовал нечеткое сопоставление для обработки опечаток, что
  помогает при поиске значений, но не решает проблему выбора столбца
  логика.

Мой вопрос: каков отраслевой стандартный подход для больших таблиц (более 600 столбцов) для меньшего LLM (7B) для надежного сопоставления значений с правильными столбцами? Должен ли я использовать многошаговый агент (Маршрутизатор -> Сокращение схемы -> Генерация SQL) или есть лучший метод подсказки?

Подробнее здесь: https://stackoverflow.com/questions/798 ... kdb-qwen-2