Excel в LLM — это $2 за вопрос. Postgres + MD-схема — $0.01

1. Сколько токенов жрёт Excel

Когда я говорю «Excel в Claude» — на практике речь о CSV или JSON-сериализации листа: Claude не парсит бинарный .xlsx напрямую, файл сначала превращается в текст. И вот тут начинается математика. По токенайзеру одна типовая ячейка с числом или строкой — это ~2-4 токена, плюс разделители (запятая или табуляция — по 1 токену каждый). У tiktoken и Anthropic counting API цифры близкие.

Берём типовую CRM-выгрузку: 20 колонок, 4 токена на ячейку в среднем, плюс 20 запятых между ячейками. Получается ~100 токенов на строку. Дальше арифметика:

По официальным тарифам Anthropic: Claude Sonnet — $3 за 1M input-токенов и $15 за 1M output. То есть один вопрос с прицепленным Excel в 800 тысяч токенов стоит $2.40 только на input. Следующий вопрос — снова $2.40, потому что у LLM нет «состояния» между сессиями: весь файл нужно перезагрузить.

2. Сценарий 1: Excel в Claude напрямую

Вот как выглядит «плохой путь» — та конфигурация, в которой я сам сидел до того, как сообразил, что делаю. Поток данных — слева направо, токен-метр заполняется почти полностью, деньги горят:

3. Lost in the Middle: атака на качество

Допустим, вы оптимист и используете Claude Sonnet 4.6 с полным 1M контекстом. Excel влез — ура. Но вот незадача: исследование Lost in the Middle (Liu et al., TACL 2024) показало, что у LLM есть U-образная кривая внимания: они запоминают начало и конец промпта, но проседают по точности на информации, расположенной в середине. Это особенно болезненно для табличных данных, где «нужная строка» с равной вероятностью может оказаться где угодно.

То же самое в более свежих работах: RULER (NVIDIA, 2024) и LongICLBench подтверждают: эффективная длина контекста, на которой модель реально работает на полную силу, обычно сильно меньше формального окна. Anthropic и сама признаёт это в блоге про prompting на длинном контексте — там прямым текстом: «помещайте ключевую информацию в начало или конец промпта».

4. Сценарий 2: Postgres + MD-схема + SQL

Тот же набор данных, но теперь правильно. Сырые таблицы в Postgres (или ClickHouse — кому что нравится), рядом — Markdown-файл с описанием. Claude Code через Postgres MCP сервер читает schema, генерирует SQL, исполняет, получает агрегат — 12 строк вместо миллиона:

5. Пример: AmoCRM в 4 таблицах

Покажу на конкретике. Берём AmoCRM API — там есть стандартные сущности: сделки (deals), лиды (leads), контакты (contacts), активности (activities). Я выгружаю их регулярно и складываю в Postgres вот такой нормализованной схемой:

CREATE TABLE contacts (
  id            BIGINT PRIMARY KEY,
  name          TEXT NOT NULL,
  phone         TEXT,
  email         TEXT,
  created_at    TIMESTAMPTZ NOT NULL,
  responsible_user_id BIGINT
);

CREATE TABLE leads (
  id            BIGINT PRIMARY KEY,
  contact_id    BIGINT REFERENCES contacts(id),
  source        TEXT,           -- utm_source / канал
  status_id     INT NOT NULL,   -- этап воронки
  created_at    TIMESTAMPTZ NOT NULL
);

CREATE TABLE deals (
  id            BIGINT PRIMARY KEY,
  lead_id       BIGINT REFERENCES leads(id),
  amount        NUMERIC(12,2) NOT NULL,  -- сумма сделки в KZT
  pipeline_id   INT NOT NULL,
  status_id     INT NOT NULL,            -- 142 = выиграна, 143 = слита
  responsible_user_id BIGINT,
  closed_at     TIMESTAMPTZ
);

CREATE TABLE activities (
  id            BIGINT PRIMARY KEY,
  entity_type   TEXT,           -- 'lead' | 'deal' | 'contact'
  entity_id     BIGINT,
  type          TEXT,           -- 'call' | 'task' | 'note'
  created_at    TIMESTAMPTZ NOT NULL,
  user_id       BIGINT
);

А вот schema.md — то, что Claude видит в начале каждой сессии. Это не просто DDL: это бизнес-описание. Подход известен как dbt-style documentation и semantic layer:

# AmoCRM Schema

## deals — сделки
- amount — сумма сделки в KZT (тенге)
- status_id — 142 = выиграна, 143 = слита,
  остальное = в работе
- pipeline_id — id воронки продаж
- closed_at — дата закрытия (NULL для открытых)

## leads — лиды (заявки до оформления сделки)
- source — utm_source / название канала
  (instagram, google_ads, organic, ...)
- status_id — этап в воронке лидов

## Типичные join'ы
- deals.lead_id → leads.id
- leads.contact_id → contacts.id
- activities.entity_id → deals.id
  (когда entity_type='deal')

## Бизнес-правила
- "выигранная сделка" = deals.status_id = 142
- "конверсия" = COUNT(won)/COUNT(*) на leads
- "средний чек" = AVG(amount) WHERE status=142
- "Q1 2026" = closed_at >= '2026-01-01'
                AND closed_at < '2026-04-01'

## Примеры запросов
1) Средний чек по менеджеру за Q1:
   SELECT responsible_user_id, AVG(amount)
   FROM deals
   WHERE status_id = 142
     AND closed_at >= '2026-01-01'
     AND closed_at < '2026-04-01'
   GROUP BY responsible_user_id;

Теперь представим, что я задаю вопрос: «Какая средняя сумма выигранной сделки в Q1 2026 у менеджера с id = 7382?» Вот что генерит Claude — буквально один SELECT, который выполнится за миллисекунды:

SELECT
  AVG(amount)        AS avg_deal,
  COUNT(*)           AS deals_count,
  SUM(amount)        AS total_revenue
FROM deals
WHERE status_id = 142
  AND responsible_user_id = 7382
  AND closed_at >= '2026-01-01'
  AND closed_at <  '2026-04-01';

Postgres возвращает одну строку: avg_deal = 1 240 000 KZT, deals_count = 47, total_revenue = 58 280 000. Claude интерпретирует это человеческим языком — и контекст почти не расходуется. На следующий вопрос («а у менеджера 7383?») schema.md уже в кэше промпта (Anthropic поддерживает prompt caching), и стоимость падает ещё в 10 раз.

6. Точность Text-to-SQL в 2025-2026

Главный вопрос скептика: «А LLM-то правильный SQL пишет?». На это есть индустриальные бенчмарки. BIRD-bench — сейчас стандарт-де-факто. Это 12 751 вопрос на 95 базах данных из 37 предметных областей, метрика — execution accuracy (выполнили SQL → совпал результат с эталонным). Аналог попроще — Spider от Yale.

Подход с пайплайнами вокруг LLM (DIN-SQL, DAIL-SQL, CHASE-SQL) даёт 73-82% точности — близко к человеческому baseline 92.96%. На простом Spider топовые модели уверенно держат 85-90%+. Это рабочая зона: для ad-hoc аналитики такая точность сильно лучше, чем «LLM смотрит в Excel и выдумывает цифры». Тем более что SQL — проверяемый: можно прочитать, прогнать на тестовом датасете, сохранить, повторить.

7. Excel vs Postgres: сводная таблица

Сводная картина по семи метрикам, которые на практике действительно решают:

8. Графики: токены и деньги

Визуально: при Excel-подходе токены растут линейно по числу строк и быстро упираются в потолок контекстного окна. При SQL-подходе — линия плоская, потому что LLM видит только schema.md, а не сами данные.

9. Как это сделать у себя

Никакого космоса не нужно. Шаги конкретные:

1. 1Развернуть Postgres. Самый дешёвый путь — Hetzner CAX21 с Coolify (€6.49/мес). Подробно расписал в статье Railway vs Hetzner. Альтернатива «бесплатно для старта» — Supabase Free Tier (managed Postgres, 500 MB) или Neon Free.
2. 2Загрузить данные. Из Excel — через COPY FROM CSV, из API — через простой Python скрипт с psycopg или DuckDB → Postgres. Если данных совсем много — Airbyte или Fivetran автоматизируют выгрузку из CRM.
3. 3Описать схему в schema.md. Не ленитесь добавить бизнес-смысл к каждой колонке: «status_id 142 = выиграна» — это то, чего нет в DDL, но критично для модели. Подход хорошо описан у Саймона Уиллисона и в посте MotherDuck про semantic layer.
4. 4Подключить Postgres MCP к Claude Code. Anthropic поддерживает Model Context Protocol — открытый стандарт для подключения внешних систем. Готовые серверы: modelcontextprotocol/servers, Supabase MCP, pgEdge Postgres MCP. Прописываете в .mcp.json — и Claude Code умеет ходить в БД.
5. 5Безопасность. Дайте MCP-серверу read-only учётку (CREATE ROLE ... WITH LOGIN; GRANT SELECT ON ALL TABLES). Это защитит от случаев SQL-инъекций через MCP — Datadog Security Labs описывал такой кейс. Если совсем параноик — подключайте через PgBouncer + ограничения по IP.
6. 6Если вы новичок в дев-сетапе — у меня есть отдельный гайд: Dev Setup Guide для новичков — там про terminal, git, Docker, Postgres локально, всё с нуля.

10. Главный вывод

LLM — это переводчик с русского на SQL, а не аналитический движок. Когда вы суёте Excel в Claude напрямую, вы платите токенами за работу, которую Postgres делает бесплатно и в миллион раз быстрее. Когда вы даёте Claude schema.md — вы используете его по назначению: модель пишет запрос, БД считает, модель интерпретирует результат. Контекст почти не расходуется. Чек уменьшается в сотни раз. Точность — растёт, потому что вычисление детерминированное.

Главное правило по итогам всего, что я понял за последний год работы с агентами:

И да: если у вас CRM на AmoCRM, Bitrix24 или Salesforce — у них всех есть API. Один Python-скрипт на 50 строк превращает их в нормализованные таблицы. Дальше всё, что описано выше — уже работает.