Конвейер NL-to-SQL с PostgreSQL — выбор пути соединения, ошибки зарезервированных слов и точность запросов ⇐ Python

[Anonymous]

Я создаю систему Natural Language to SQL, которая;

• Подключается к любой базе данных PostgreSQL и автоматически анализирует схему с помощью Information_schema
• Строит график связей таблиц с помощью NetworkX
• Использует встраивания преобразователей предложений для поиска соответствующих таблиц из простой английский запрос
• Оценивает пути соединения с использованием семантического сходства + повышения ключевых слов + оценки охвата.
• Отправляет лучший путь в Groq LLM (Llama 3.3 70B) для генерации SQL.
• Имеет самовосстанавливающийся цикл повторов, который отправляет неудачный SQL обратно в LLM для исправления

Технический стек: Python, PostgreSQL, NetworkX, преобразователи предложений, Groq API, psycopg2, FastAPI (планируется)
Текущие проблемы:
Проблема 1. Как лучше всего обрабатывать имена таблиц зарезервированных слов при автоматической генерации SQL с помощью Магистр права? Должен ли я переименовать таблицу или обработать ее в командной строке?
Проблема 2 — цикл самовосстановления LLM не работает
for attempt in range(3):
execute SQL
if fails → send error to LLM → fix SQL → retry
LLM returns identical broken SQL all 3 attempts

Вопрос: Какие методы оперативного проектирования лучше всего работают для того, чтобы LLM действительно исправил неправильный SQL при получении сообщения об ошибке?
Проблема 3 — неоднозначность пути соединения
Несколько допустимых путей между одними и теми же таблицами
пациент → рецепт → рецепт_деталь → лекарство правильный
пациент → контролируемый_drug_log → лекарство также допустимо, но неправильный контекст

Currently scoring with:

Semantic similarity (weight 0.8)

Path length (weight 0.1)

Nullable FK penalty (weight 0.1)

Keyword boost (+0.15 per matching keyword)

Relevant table coverage boost (×0.8)

Question1:What is the most reliable approach to disambiguate multiple valid join paths in a graph when the correct path depends on business context?

Problem 2— Schema Linking Noise** With 23 tables, embedding-based table selection sometimes picks irrelevant tables which pollute the path finding. Currently using top_k=5 with forced entity detection.

Question3:What is the recommended approach for schema linking in NL-to-SQL systems with 20+ tables?

### What I've Tried:

- Full schema in prompt → LLM gets confused with 23 tables

- Graph-based path finding with cutoff=4 → reduced paths from 1437 to 6

- Embedding similarity alone → wrong path selected due to length bias

- Keyword boosting → improved accuracy significantly

- Irrelevant table penalty → reduced noise in path selection


Подробнее здесь: https://stackoverflow.com/questions/799 ... ord-errors