Как настроить 4B Text2SQL модель для запросов к CSV: локальный аналог DeepSeek-V3 с Ollama

Зачем мучить 685-миллиардного монстра, если справится 4-миллиардный карлик?

DeepSeek-V3 с её 685 миллиардами параметров - это как привезти коллайдер, чтобы расколоть орех. Да, она гениальна в Text2SQL. Но она пожирает память, требует клауд, а ваши данные улетают в неведомые дата-центры. Есть другой путь.

Маленькая 4B модель, заточенная под одну задачу - переводить ваш вопрос на русском в SQL запрос для CSV файла. Запускается на ноутбуке. Не требует API ключей. Не отправляет ваши финансовые отчёты или клиентские базы в облако. Звучит утопично? Это уже работает.

Что за зверь такой - 4B Text2SQL модель?

Это нейросеть с 4 миллиардами параметров (в 170 раз меньше DeepSeek-V3), которую специально дообучили на тысячах примеров «вопрос на естественном языке - SQL запрос для CSV». Она не умеет писать стихи, не поддерживает философские диалоги. Её единственная цель - понимать ваши вопросы про данные и превращать их в рабочий код.

Ключевое слово - специально дообучили. Базовые модели Llama 3.2 или Qwen2.5 в 4B варианте с Text2SQL справляются плохо. Но после тонкой настройки (fine-tuning) на правильном датасете - выстреливают с точностью выше 90% для типовых бизнес-запросов. Как в той статье про Text-to-SQL агента для бизнеса, только без 70B модели и сложной архитектуры.

DeepSeek-V3 против нашего 4B карлика: неочевидная правда

Давайте сравним не на бумаге, а в реальных условиях. Когда вы выбираете модель для запросов к своим CSV файлам.

Разница в 3-7% точности - это плата за приватность, скорость и независимость. Для 95% бизнес-аналитиков это приемлемо. DeepSeek-V3, конечно, мощнее в сложных логических цепочках. Но если вам нужно просто «отфильтруй заказы по дате и посчитай выручку по категориям» - 4B модели хватит с головой.

Собираем пазл: от голой модели до работающего Text2SQL движка

Теория - это хорошо, но давайте перейдём к практике. Что нужно сделать, чтобы из обычной 4B модели получить специалиста по CSV запросам?

1Выбор базовой модели и установка Ollama

Не все 4B модели одинаково полезны. Лучшие кандидаты - Qwen2.5-4B-Instruct или Llama 3.2-3B-Instruct (да, там 3B, но близко). Они лучше следуют инструкциям. Устанавливаем Ollama - это проще, чем кажется.

# На Linux/macOS
curl -fsSL https://ollama.ai/install.sh | sh

# Проверяем установку
ollama --version
# Скачиваем базовую модель (пока без fine-tuning)
ollama pull qwen2.5:4b-instruct

Ollama превращает работу с моделями в команды типа ollama run. Если вы раньше мучились с llama.cpp или трансформерами - это как перейти с самодельного велосипеда на электровелосипед. Кстати, если интересны детали локального запуска больших моделей, посмотрите как запустить DeepSeek V3.2 в llama.cpp - там обратная ситуация, когда приходится бороться с железом.

2Подготовка датасета для fine-tuning

Вот где начинается магия. Вам нужны пары «вопрос - SQL». 1000-5000 примеров хватит. Где взять?

• Сгенерировать с помощью GPT-4 или Claude (дорого, но качественно).
• Взять открытые датасеты типа Spider или BIRD и адаптировать под CSV-синтаксис.
• Самый честный способ - записать реальные вопросы, которые задают ваши аналитики, и вручную написать к ним SQL.

Формат датасета - JSONL. Каждая строка:

{
  "instruction": "Таблица sales: id, date, product, category, amount, region. Вопрос: Какие три региона показали наибольшую выручку в январе 2024?";
  "output": "SELECT region, SUM(amount) as total_revenue FROM sales WHERE strftime('%Y-%m', date) = '2024-01' GROUP BY region ORDER BY total_revenue DESC LIMIT 3;"
}

Обратите внимание - в инструкции явно описана структура таблицы. Модель должна её видеть, иначе будет работать как RAG, который начинает врать при неполном контексте.

3Fine-tuning на своём железе (да, это реально)

Вам не нужен A100. Достаточно GPU с 8-16 ГБ памяти (RTX 3070/4070). Используем библиотеку Unsloth (ускоряет обучение в 2-5 раз) или PEFT (Parameter-Efficient Fine-Tuning).

# Упрощённый пример с Unsloth
from unsloth import FastLanguageModel
import torch

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/qwen2-5-4b",
    max_seq_length = 2048,
    dtype = torch.float16,
    load_in_4bit = True,  # 4-битное квантование для экономии памяти
)

# Конфигурация LoRA (добавляем всего 0.1% новых параметров)
model = FastLanguageModel.get_peft_model(
    model,
    r = 16,  # Rank
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha = 16,
    lora_dropout = 0,
    bias = "none",
    use_gradient_checkpointing = True,
    random_state = 42,
)

# Загрузка датасета и обучение...
# Полный код опущен для краткости, но он стандартен

Обучение 1000 примеров на RTX 4070 займёт 1-2 часа. После этого у вас есть файл с весами (adapter_model.bin), который весит 50-100 МБ. Это и есть ваша Text2SQL модель.

4Упаковка в Ollama и запуск

Ollama умеет загружать кастомные модели через Modelfile. Создаём файл:

FROM qwen2.5:4b-instruct
# Копируем наши дообученные веса
ADAPTER ./adapter_model.bin

PARAMETER temperature 0.1  # Низкая температура для детерминированных SQL
PARAMETER num_ctx 4096

SYSTEM """
Ты - эксперт по SQL запросам к CSV таблицам.
Тебе будет предоставлена схема таблицы и вопрос на естественном языке.
Ты должен сгенерировать только SQL запрос, без пояснений.
Используй SQLite синтаксис, так как CSV часто загружаются в SQLite виртуальные таблицы.
"""

Собираем и запускаем:

ollama create my-text2sql -f ./Modelfile
ollama run my-text2sql

Всё. Теперь у вас есть локальная модель, которая понимает запросы типа «покажи средний чек по месяцам для категории Электроника».

Живой пример: от вопроса к данным за 0.3 секунды

Допустим, у вас есть CSV с продажами (sales.csv). Вы хотите получить ответ на вопрос. Пишем простой Python скрипт:

import subprocess
import json
import pandas as pd
import sqlite3

# Шаг 1: Загружаем CSV в SQLite (виртуальную таблицу)
df = pd.read_csv('sales.csv')
conn = sqlite3.connect(':memory:')
df.to_sql('sales', conn, index=False)

# Получаем схему таблицы для промпта
schema = []
for row in conn.execute("PRAGMA table_info(sales);"):
    schema.append(f"{row[1]} ({row[2]})")
schema_str = ', '.join(schema)

# Шаг 2: Формируем промпт с вопросом
question = "Какие 5 товаров принесли наибольшую выручку в Москве в 2024 году?"
prompt = f"""Таблица sales: {schema_str}
Вопрос: {question}
SQL запрос:"""

# Шаг 3: Запрос к локальной модели через Ollama
request = {
    "model": "my-text2sql",
    "prompt": prompt,
    "stream": False
}

result = subprocess.run(
    ['ollama', 'run', 'my-text2sql', prompt],
    capture_output=True,
    text=True
)

# Извлекаем SQL из ответа (модель может добавить пояснения)
sql_query = result.stdout.strip().split('```sql')[-1].split('```')[0].strip()
print(f"Сгенерированный SQL: {sql_query}")

# Шаг 4: Выполняем SQL и получаем результат
try:
    result_df = pd.read_sql_query(sql_query, conn)
    print(result_df)
except Exception as e:
    print(f"Ошибка в SQL: {e}")

И это всё. Никаких API ключей, никаких ограничений по количеству запросов. Вы можете поставить этот скрипт на крон и запускать каждые 5 минут. Или подключить к веб-интерфейсу для аналитиков. Как в том проекте про Eva-4B для финансовой аналитики, только для SQL.

Кому стоит заморачиваться с этим 4B карликом?

Ответ прост: тем, у кого есть хотя бы один из этих пунктов:

• Данные, которые нельзя отправлять в облако. Персональные данные, финансовая отчётность, врачебные тайны. Даже если провайдер LLM клянётся в конфиденциальности, юристы вашей компании могут запретить.
• Нужна мгновенная скорость. 100-500 мс против 2-10 секунд через API. Когда аналитик жмёт кнопку - он хочет видеть результат сейчас, а не после кофе.
• Бюджет стремится к нулю. DeepSeek-V3 за $0.8 за миллион токенов кажется дёшево, пока вы не посчитаете 1000 запросов в день от 50 аналитиков.
• Стабильность важнее максимальной точности. Большие модели иногда «глючат» - выдают SQL с несуществующими столбцами. Маленькая заточенная модель предсказуемее.

Если же у вас нет GPU для fine-tuning, а данные не секретны - возможно, проще использовать API большой модели. Или комбинировать подходы: простые запросы - к локальной 4B модели, сложные аналитические - к DeepSeek-V3 через API. Как в гибридных системах из статьи про локальные LLM против традиционного перевода.

Что будет дальше? (Спойлер: всё лучше)

Через год 4B модели будут справляться с задачами, которые сегодня под силу только 70B. Архитектуры улучшаются, методы fine-tuning становятся эффективнее. Уже сейчас появляются специализированные модели для медицинских данных, финансовых отчётов, логистики.

Но главный тренд - не рост параметров, а специализация. Одна маленькая модель для SQL, другая - для классификации текстов, третья - для извлечения сущностей. Как швейцарский нож, где каждое лезвие идеально для своей задачи. И все они работают на вашем ноутбуке, не спрашивая разрешения отправить данные в облако.

Попробуйте. Скачайте Ollama, возьмите Qwen2.5-4B, настройте на своих CSV. Первые результаты увидите через пару часов. А потом уже не захотите возвращаться к облачным API с их задержками, лимитами и счетами.