Rozumienie i wstrzykiwanie schematu
Wyodrębnianie i formatowanie schematu bazy danych na potrzeby kontekstu LLM: tabel, kolumn i relacji.
Rozumienie i wstrzykiwanie schematu to bezpłatna lekcja AI Agents na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI Agents, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Agents zawiera 4 lekcji w sumie.
Dlaczego kontekst schematu ma znaczenie
LLM zna składnię SQL, ale nie wie nic o Państwa bazie danych. Bez kontekstu schematu będzie halucynować nazwy tabel i kolumn.
Wstrzykiwanie schematu oznacza programistyczne wyodrębnianie struktury bazy danych i dołączanie jej do każdego promptu — dzięki temu LLM zna dokładne tabele, kolumny i typy.
Odpytywanie INFORMATION_SCHEMA
Wszystkie główne relacyjne bazy danych udostępniają metadane za pośrednictwem INFORMATION_SCHEMA. Można je odpytywać, aby uzyskać informacje o każdej tabeli, nazwie kolumny i typie danych bez modyfikowania kodu aplikacji.
Rozwiązanie działa w PostgreSQL, MySQL, SQL Server i SQLite, z niewielkimi różnicami.
import psycopg2
def get_schema(conn):
query = '''
SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'public'
ORDER BY table_name, ordinal_position
'''
with conn.cursor() as cur:
cur.execute(query)
return cur.fetchall()Grupowanie kolumn według tabel
Surowy wynik INFORMATION_SCHEMA to płaska lista wierszy. Należy pogrupować je według nazwy tabeli, aby utworzyć uporządkowaną reprezentację, którą łatwiej sformatować na potrzeby promptu.
from collections import defaultdict
def build_schema_dict(conn):
rows = get_schema(conn)
schema = defaultdict(list)
for table_name, column_name, data_type in rows:
schema[table_name].append({
'name': column_name,
'type': data_type
})
return dict(schema)
# Result:
# {
# 'users': [{'name': 'id', 'type': 'integer'}, {'name': 'email', 'type': 'character varying'}],
# 'orders': [{'name': 'id', 'type': 'integer'}, {'name': 'user_id', 'type': 'integer'}]
# }Formatowanie schematu na potrzeby promptów LLM
LLM odczytuje schemat jako zwykły tekst. Należy używać zwięzłego i czytelnego formatu: jedna tabela w wierszu, z nazwami kolumn i typami w nawiasach.
Uwzględnienie kluczy głównych (PK) i obcych (FK) pomaga LLM-owi tworzyć poprawne instrukcje JOIN.
def format_schema_for_prompt(schema_dict, pk_info=None, fk_info=None):
lines = []
for table, columns in schema_dict.items():
col_parts = []
for col in columns:
label = col['name']
if pk_info and (table, col['name']) in pk_info:
label += ' PK'
if fk_info and (table, col['name']) in fk_info:
label += f' FK->{fk_info[(table, col["name"])]}'
col_parts.append(f"{label} ({col['type']})")
lines.append(f"Table {table}: {', '.join(col_parts)}")
return '\n'.join(lines)
# Output:
# Table users: id PK (integer), email (varchar), created_at (timestamp)
# Table orders: id PK (integer), user_id FK->users.id (integer), total (float)
if __name__ == '__main__':
demo_schema = {'users': [{'name': 'id', 'type': 'integer'}, {'name': 'email', 'type': 'varchar'}]}
demo_pk = {('users', 'id')}
print(format_schema_for_prompt(demo_schema, pk_info=demo_pk))
Uwzględnianie kluczy głównych i obcych
Relacje kluczy obcych są najważniejszą częścią kontekstu schematu — informują LLM, jak tworzyć zapytania JOIN. Należy odpytać information_schema.table_constraints i key_column_usage, aby je wyodrębnić.
def get_foreign_keys(conn):
query = '''
SELECT
kcu.table_name,
kcu.column_name,
ccu.table_name AS foreign_table,
ccu.column_name AS foreign_column
FROM information_schema.table_constraints AS tc
JOIN information_schema.key_column_usage AS kcu
ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage AS ccu
ON ccu.constraint_name = tc.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY'
'''
with conn.cursor() as cur:
cur.execute(query)
return {
(row[0], row[1]): f'{row[2]}.{row[3]}'
for row in cur.fetchall()
}
if __name__ == '__main__':
class FakeCursor:
def __enter__(self): return self
def __exit__(self, *a): return False
def execute(self, query): pass
def fetchall(self):
return [('orders', 'user_id', 'users', 'id')]
class FakeConn:
def cursor(self): return FakeCursor()
fks = get_foreign_keys(FakeConn())
print('Foreign keys found:')
for (table, col), ref in fks.items():
print(f' {table}.{col} -> {ref}')
Kompresja schematu: problem
Rzeczywista firmowa baza danych może zawierać ponad 200 tabel. Wstrzyknięcie całego schematu przekroczy okno kontekstu GPT-4 i spowoduje niepotrzebne wydatki na tokeny.
Schemat obejmujący 200 tabel po 20 kolumn każda to około ponad 40 000 tokenów — zbyt dużo, aby wysyłać go przy każdym zapytaniu.
def estimate_schema_tokens(schema_dict):
text = format_schema_for_prompt(schema_dict)
# Rough estimate: 1 token per 4 characters
estimated_tokens = len(text) // 4
print(f'Tables: {len(schema_dict)}')
print(f'Estimated schema tokens: {estimated_tokens}')
return estimated_tokens
# 200 tables * 15 columns * 25 chars/col = 75,000 chars = ~18,750 tokens
# Plus user question + system prompt = easily over context limitKompresja schematu: selektywne wstrzykiwanie
Najskuteczniejsza strategia kompresji to wstrzykiwanie wyłącznie tabel związanych z pytaniem. Należy zastosować podejście dwuetapowe — najpierw zapytać LLM, których tabel potrzebuje, a następnie wstrzyknąć tylko schematy tych tabel.
def select_relevant_tables(question, all_table_names, n=5):
table_list = ', '.join(all_table_names)
prompt = f'''Database tables: {table_list}
Question: {question}
List the {n} most relevant table names as a JSON array.
Example: ["users", "orders", "products"]'''
response = llm_call(prompt)
import json
return json.loads(response)
def compressed_schema(question, conn):
all_tables = list(build_schema_dict(conn).keys())
relevant = select_relevant_tables(question, all_tables)
full_schema = build_schema_dict(conn)
return {t: full_schema[t] for t in relevant if t in full_schema}Kompresja schematu: wykluczanie zbędnych kolumn
Wiele tabel zawiera kolumny audytowe, takie jak created_at, updated_at, deleted_at, version i created_by, które rzadko mają znaczenie w zapytaniach biznesowych. Należy je pominąć, aby zmniejszyć liczbę tokenów.
AUDIT_COLUMNS = {
'created_at', 'updated_at', 'deleted_at', 'created_by',
'updated_by', 'version', 'is_deleted', 'modified_at'
}
def compress_schema(schema_dict, exclude_audit=True):
compressed = {}
for table, columns in schema_dict.items():
# Skip internal/system tables
if table.startswith('_') or table.startswith('pg_'):
continue
if exclude_audit:
columns = [c for c in columns if c['name'] not in AUDIT_COLUMNS]
if columns: # only include if columns remain
compressed[table] = columns
return compressed
if __name__ == '__main__':
demo_schema = {
'users': [{'name': 'id', 'type': 'INT'}, {'name': 'email', 'type': 'VARCHAR'}, {'name': 'created_at', 'type': 'TIMESTAMP'}],
'pg_stat': [{'name': 'x', 'type': 'INT'}],
}
compressed = compress_schema(demo_schema)
print('Tables kept:', list(compressed.keys()))
print('users columns after compression:', [c['name'] for c in compressed['users']])
Dodawanie opisów tabel
Same nazwy kolumn nie zawsze są wystarczająco jasne. Dodanie opisów w języku naturalnym wyjaśniających znaczenie każdej tabeli znacznie poprawia jakość generowania SQL.
Opisy można przechowywać w pliku konfiguracji lub jako komentarze do tabel PostgreSQL.
TABLE_DESCRIPTIONS = {
'users': 'Registered app users with authentication info',
'orders': 'Customer purchase orders',
'order_items': 'Individual line items within an order',
'products': 'Product catalog with pricing',
'payments': 'Payment transactions linked to orders'
}
def format_schema_with_descriptions(schema_dict):
lines = []
for table, columns in schema_dict.items():
desc = TABLE_DESCRIPTIONS.get(table, '')
col_str = ', '.join(f"{c['name']} ({c['type']})" for c in columns)
if desc:
lines.append(f"Table {table} ({desc}): {col_str}")
else:
lines.append(f"Table {table}: {col_str}")
return '\n'.join(lines)
if __name__ == '__main__':
demo_schema = {'users': [{'name': 'id', 'type': 'INT'}], 'orders': [{'name': 'id', 'type': 'INT'}]}
print(format_schema_with_descriptions(demo_schema))
Buforowanie schematu
Schematy baz danych rzadko się zmieniają. Pobieranie INFORMATION_SCHEMA przy każdym zapytaniu zwiększa opóźnienie i obciążenie. Należy buforować sformatowany ciąg znaków schematu i unieważniać go po zdarzeniach zmiany schematu lub po upływie określonego czasu TTL.
import time
class SchemaCache:
def __init__(self, ttl_seconds=300):
self._cache = None
self._timestamp = 0
self.ttl = ttl_seconds
def get(self, conn):
now = time.time()
if self._cache is None or (now - self._timestamp) > self.ttl:
print('Refreshing schema cache...')
schema_dict = build_schema_dict(conn)
fk_info = get_foreign_keys(conn)
self._cache = format_schema_for_prompt(schema_dict, fk_info=fk_info)
self._timestamp = now
return self._cache
schema_cache = SchemaCache(ttl_seconds=300)Pełny proces wstrzykiwania schematu
Połączenie wszystkich technik: buforowanie skompresowanego schematu, wstrzykiwanie go do promptu systemowego oraz selektywne filtrowanie tabel w przypadku dużych baz danych.
def build_sql_agent_prompt(question, conn, large_db=False):
if large_db:
schema = compressed_schema(question, conn)
schema_text = format_schema_with_descriptions(schema)
else:
schema_text = schema_cache.get(conn)
system = f'''You are a PostgreSQL expert.
Return ONLY a valid SELECT query based on this schema:
{schema_text}
Rules:
- Use only SELECT statements
- Use table aliases for clarity
- Limit results to 100 rows unless asked for all
'''
return systemSprawdzenie wiedzy
Kiedy należy stosować selektywne wstrzykiwanie tabel zamiast wstrzykiwania pełnego schematu?
Podsumowanie: rozumienie i wstrzykiwanie schematu
Skuteczne wstrzykiwanie schematu jest podstawą niezawodnych agentów NL-to-SQL. Należy wyodrębnić strukturę z INFORMATION_SCHEMA, uwzględnić relacje kluczy głównych i obcych oraz sformatować ją jako zwięzły tekst dla LLM.
W przypadku dużych baz danych należy buforować schemat, usuwać kolumny audytowe i stosować selektywne wstrzykiwanie, aby przesyłać tylko tabele istotne dla danego pytania. Opisy tabel w języku naturalnym dodatkowo poprawiają jakość zapytań.
Często zadawane pytania
Czy lekcja „Rozumienie i wstrzykiwanie schematu” jest bezpłatna?
Tak — pełny tekst „Rozumienie i wstrzykiwanie schematu” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI Agents, przejdź na CoddyKit PRO. Kurs AI Agents zawiera 4 lekcji w sumie.
Co nauczysz się w „Rozumienie i wstrzykiwanie schematu”?
Wyodrębnianie i formatowanie schematu bazy danych na potrzeby kontekstu LLM: tabel, kolumn i relacji. Ćwiczysz AI Agents z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć AI Agents?
Nie wymagamy żadnego doświadczenia. AI Agents w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.
Ile czasu zajmuje lekcja „Rozumienie i wstrzykiwanie schematu”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji AI Agents?
Tak. Każda lekcja AI Agents zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Jak działają agenci NL-to-SQL
- Rozumienie i wstrzykiwanie schematu
- Generowanie i walidowanie zapytań SQL
- Obsługa niejednoznacznych pytań dotyczących baz danych