Перейти к содержимому

2.3 · Обзор моделей и провайдеров

Неделя 2 · Основы LLM · ⏱ ~1,5 ч · Теория

Выбор модели — одно из первых архитектурных решений в любом LLM-проекте, и от него зависят цена, задержка, качество и даже юридические ограничения (где обрабатываются данные). На собеседовании типичный вопрос: «Почему вы взяли эту модель, а не другую? Что будете делать, если она подорожает или её снимут с поддержки?» Ответ «она лучшая по рейтингу» не принимается — нужен аргумент под задачу.

До сих пор мы работали с четырьмя провайдерами — DeepSeek, Ollama, Claude и OpenAI — и брали модель «по умолчанию». Чтобы выбирать осознанно, сначала посмотрим на весь рынок. Он делится на две части. Закрытые модели доступны только через API их лаборатории (или облака-партнёра): весов никто не видит. Open-weight модели публикуют вместе с весами — файлами с параметрами обученной сети; их можно скачать и запустить на своём железе (так работает Ollama) или арендовать у хостинга. Frontier-лаборатории — те, чьи модели задают верхнюю планку качества.

┌──────────── закрытые (только через API) ────────────┐
Frontier-лаборатории: Anthropic (Claude) · OpenAI (GPT, o-series) · Google (Gemini) · xAI (Grok)
└──────────────────────────────────────────────────────┘
┌──────────── open-weight (веса можно скачать) ───────┐
Meta (Llama) · Alibaba (Qwen) · Mistral · DeepSeek · Google (Gemma) ...
└──────────────────────────────────────────────────────┘
Где запускать open-weight: свой GPU / Mac (Ollama, LM Studio, llama.cpp, MLX),
облако (vLLM на арендованном GPU), хостинги-агрегаторы (Together, Fireworks, Groq, OpenRouter ...)
Где ещё доступны закрытые: облака — AWS Bedrock, Google Vertex AI, Azure/Microsoft Foundry

Внутри каждого семейства есть линейка по размеру: маленькая быстрая дешёвая модель, средняя «рабочая лошадка» и большая флагманская. У Anthropic это Haiku / Sonnet / Opus (плюс верхний уровень над Opus), у OpenAI — nano / mini / полноразмерная, у Google — Flash-Lite / Flash / Pro. Разница в цене между младшей и старшей моделью одного провайдера — десятки раз.

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

Ось Что это Где смотреть
Качество Насколько хорошо решает нашу задачу Бенчмарки, Arena, но главное — свои evals
Цена $ за 1M input / output токенов; есть скидки за кэш (повторяющееся начало промпта) и batch (пакетная обработка без спешки, глава 2.7) Страницы pricing провайдеров
Задержка TTFT (время до первого токена) и скорость (токенов/с) Artificial Analysis, свои замеры
Контекстное окно Сколько токенов влезает во вход (сейчас от ~128K до 1M+) Страница модели
Максимальный output Сколько модель может сгенерировать за ответ Страница модели
Модальности Текст, изображения, PDF, аудио, видео на входе; что на выходе Страница модели
Возможности API Tool calling, structured outputs, кэш, batch, стриминг Документация API
Данные и комплаенс Где обрабатываются, хранятся ли, ZDR (Zero Data Retention — провайдер ничего не сохраняет), регионы Политики провайдера, облака
Стабильность Как часто модель меняют/снимают (deprecation) Страницы deprecations

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

Reasoning-модель перед ответом генерирует внутреннее рассуждение (thinking/reasoning tokens) — то же, что «подумай по шагам», но обученное специально и часто скрытое от пользователя. Плюсы: заметно сильнее на математике, коде, многошаговом планировании, агентных задачах. Минусы: больше токенов (рассуждение оплачивается как output), выше задержка, сэмплирование (temperature и другие ручки из главы 1.7) настраивать нельзя.

Граница размывается: современные флагманы — гибриды, которые думают «по необходимости» (adaptive thinking у Claude), а глубину регулирует параметр вроде effort / reasoning.effort. Практическое правило: для извлечения, классификации и коротких ответов — низкий effort или маленькая модель; для кода, планирования и агентов — выше. И проверяем замером: на простых задачах высокий effort часто стоит дороже без прироста.

Контекстное окно: большое ≠ бесплатное и ≠ идеальное

Заголовок раздела «Контекстное окно: большое ≠ бесплатное и ≠ идеальное»

1M токенов — это несколько тысяч страниц. Но:

  • каждый input-токен оплачивается в каждом запросе (кэш помогает, глава 2.7);
  • задержка растёт с длиной входа;
  • качество поиска «иголки» в длинном контексте у моделей разное и обычно хуже на середине очень длинного входа;
  • у некоторых моделей цена за токен выше, если промпт длиннее порога.

Поэтому RAG (найти нужные куски и дать только их) не умер с появлением больших окон — это вопрос цены, скорости и точности.

  • Академические бенчмарки (MMLU-подобные знания, GPQA, SWE-bench для кода, AIME для математики, бенчмарки агентов и tool use). Полезны для грубого сравнения, но страдают от contamination (тестовые задачи попали в обучающие данные) и от того, что лаборатории оптимизируются под известные бенчмарки.
  • LMArena — люди сравнивают два анонимных ответа и выбирают лучший; из голосов строится рейтинг (Elo-подобный). Хорошо отражает «нравится людям в чате». Плохо отражает точность извлечения, следование формату, работу в агентах. Длинные, красиво оформленные ответы получают бонус.
  • Artificial Analysis — независимые замеры: сводный индекс качества, цена (смешанная цена за токен), скорость и TTFT по разным провайдерам одной модели. Удобно для графика «качество vs цена».

Итог: рейтинги — для шорт-листа из 2–4 кандидатов. Окончательный выбор — свои evals на своих данных: набор своих примеров с правильными ответами, на котором каждую модель-кандидата прогоняют и считают долю верных. Прототип такого eval был в главе 2.1, первый настоящий соберём в главе 2.5, а целый этап курса (недели 6–8) посвящён evals.

Рейтинги сравнивают модели независимо от того, кто их выпустил. Но есть ещё одно деление, которое влияет не на качество, а на цену, контроль и данные, — закрытая модель или open-weight.

Закрытые API Open-weight
Качество на верхнем уровне Обычно лучше Догоняют с отставанием, лучшие близки
Старт Ключ — и работает Нужен хостинг или агрегатор
Цена За токен, без инфраструктуры За токен у хостинга или за GPU-часы у себя
Данные Уходят провайдеру (с договорными гарантиями) Можно держать полностью у себя
Контроль Модель могут изменить/снять Версия навсегда наша; можно дообучать
Сэмплинг, шаблоны Ограничены API Полный контроль (temperature, prefill, logprobs)

Типичная продуктовая стратегия: прототип на сильной закрытой модели → evals → попытка заменить на более дешёвую (младшую закрытую или open-weight) с проверкой качества.

Соберём оси, рейтинги и это деление в один порядок действий.

  1. Формулируем требования: какие входы (текст/картинки/PDF), нужен ли tool calling и строгий JSON, допустимая задержка (чат ≤ 2 с до первого токена? фоновая задача — без разницы), объём (запросов в день), бюджет, требования к данным.
  2. Шорт-лист по рейтингам и функциям API: 2–4 модели разных ценовых уровней.
  3. Начинаем с сильной модели, добиваемся качества промптом.
  4. Прогоняем evals на всех кандидатах; считаем цену за успешно решённую задачу (не за токен) и задержку p50/p95.
  5. Выбираем самую дешёвую, которая проходит планку. Для разных шагов пайплайна модели могут быть разными (классификатор — маленькая, генерация ответа — средняя).
  6. Закладываем замену: модель — конфиг, а не константа по коду; evals позволяют сменить её за час, когда выйдет новая или старую снимут.

Чтобы шаг 5 («самая дешёвая, которая проходит планку») ощущался в деньгах, посмотрим на одну линейку целиком. Только как иллюстрация масштабов (цены за 1M токенов input / output на 3 ноября 2026; перед использованием стоит проверить на странице pricing):

Модель ID Контекст Input / Output, $ Для чего
Claude Haiku 5.5 claude-haiku-5-5 1M 0.10 / 0.50 (для промптов до 100K токенов, дальше дороже) Массовые простые задачи: классификация, извлечение, роутинг
Claude Sonnet 5.5 claude-sonnet-5-5 1M 2 / 10 Повседневная рабочая модель: код, агенты, анализ
Claude Opus 5.5 claude-opus-5-5 1M 4 / 20 Сложные рассуждения, длинные агентные задачи
Claude Fable 5.2 claude-fable-5-2 1M 8 / 40 Самые тяжёлые задачи, где цена вторична

Видно главное: разница между младшей и старшей моделью одного провайдера — до ~80 раз по цене. Аналогичную таблицу для GPT, Gemini и open-weight соберём сами.

Учебный стек курса — это два полюса той же карты рынка: DeepSeek — дешёвый облачный API китайской лаборатории, Ollama — open-weight модели на нашем собственном железе. Полезно разложить их по тем же осям, что и Claude.

Как и в главе 1.7, input у DeepSeek стоит по-разному: «промах» — обычная цена, «попадание» — цена той части промпта, которая совпала с недавним запросом и взята из кэша. «Конкурентность» — сколько запросов аккаунт может держать одновременно (подробнее — глава 2.7).

Модель Версия за именем Контекст / max output Input промах / попадание, $ Output, $ Особенности
deepseek-flash DeepSeek-V4.1-Flash-1017 1M / 384K 0.30 / 0.006 1.20 гибрид (размышление по умолчанию), vision, конкурентность 2500
deepseek-v4-pro DeepSeek-V4-Pro-0813 1M / 384K 1.32 / 0.044 3.96 гибрид, без vision, конкурентность 500

Цены — пиковые за 1M токенов; вне пика вдвое дешевле (глава 1.7). Сравним с таблицей Claude выше: deepseek-flash по output дороже Haiku 5.5 из примера, но input с кэшем почти бесплатен — для задач «длинный повторяющийся контекст + короткий ответ» это сильный аргумент. Именно так и надо сравнивать: по цене нашей задачи, а не по строке прайса.

Важно для «стабильности»: deepseek-flash — это алиас. DeepSeek уже переводил старые имена (deepseek-v4-flash) на новую версию модели без смены имени у клиента. Для учёбы это удобно, для продукта — тот самый «latest», про который предупреждает «На что обратить внимание»: поведение может поменяться незаметно, и только evals это заметят. Поэтому записываем в лог model из ответа и дату.

Данные: серверы в КНР, юрисдикция — материковый Китай; использование входных данных для обучения в документах сформулировано неоднозначно. Для работы в компании это часто стоп-фактор сам по себе. Правило курса шире и касается любого облачного провайдера: персональные данные покупателей, рабочий код и всё, что нельзя показывать посторонним, в облачные модели не уходит — это обрабатывает локальная модель; в облако — только публичные тексты и демо-база.

DeepSeek исторически публикует веса своих моделей на Hugging Face (организация deepseek-ai), но флагманские версии слишком велики для обычного ноутбука — локально их не запустить; стоит проверить, какие веса доступны сейчас.

Модель в Ollama — это квантованные веса (обычно 4 бита на параметр) + шаблон чата. Грубая прикидка памяти: размер файла модели + запас на контекст (KV-кэш — промежуточные вычисления по каждому токену контекста — растёт с num_ctx, размером окна, и с числом параллельных запросов). По каталогу ollama.com/library на 13.11.2026:

Модель Размер Что умеет Кому
qwen3:4b 2.5 ГБ tools, thinking, контекст до 256K основная учебная модель курса
qwen3:1.7b 1.4 ГБ tools, thinking если нужна скорость или память занята
qwen3:8b 5.2 ГБ tools, thinking, контекст 40K от 16 ГБ RAM; на 8 ГБ — только при закрытом всём остальном
gpt-oss:20b 14 ГБ tools, thinking, structured outputs от 32 ГБ RAM; на 8–16 ГБ не ставим
bge-m3 1.2 ГБ эмбеддинги, многоязычная (в том числе русский) этап RAG, модель по умолчанию в курсе (глава 4.1 · Эмбеддинги руками на numpy)

Ориентир по памяти: 8 ГБ RAM — модели класса 3–4B; 16 ГБ — 7–8B; 32 ГБ и больше — 14B и крупнее. Память делят с браузером, IDE и остальными программами, поэтому модель на границе доступной памяти уйдёт в swap и замедлит всё. По умолчанию в курсе — qwen3:4b, она запускается почти везде. Качество локальной модели такого размера заметно ниже облачной — для задач на закрытых данных компенсируем это более простыми задачами (классификация, извлечение по схеме), строгим format и проверкой кодом, а не «умом» модели.

В каталоге есть и более новые семейства — выбираем по меткам tools / thinking и размеру, а не по названию. Осторожно с моделями с меткой cloud (в том числе там встречается deepseek-v4.1-flash): они выполняются на серверах Ollama, а не у нас. По FAQ Ollama промпты облачных моделей не хранятся и не используются для обучения — но они покидают компьютер, а для данных покупателей правило курса — только локально.

Тег (qwen3:4b) может указывать на обновлённые веса после нового ollama pull — записываем ID из ollama list рядом с результатами evals.

Теперь можно положить все четыре провайдера курса на оси из теории — это и есть короткий ответ на вопрос «почему у нас такой стек».

Ось Claude OpenAI DeepSeek Ollama (локально)
Качество верхний уровень верхний уровень близко к верхнему за свою цену — проверяем своими evals заметно ниже у моделей, влезающих в память ноутбука
Цена за токен, кэш и batch со скидкой за токен, кэш и batch очень дёшево, кэш автоматический, скидка вне пика, batch нет $0 за токен; платим железом и временем
Задержка облако облако облако; под нагрузкой бывают паузы (keep-alive) зависит от железа, первый запрос — загрузка модели
Контекст до 1M зависит от модели 1M у модели свой предел; по умолчанию Ollama даёт 4096
Tools / strict JSON да / да да / да да / только strict tools (бета), JSON mode да / схема в format
Эмбеддинги нет своего API есть нет эндпоинта есть (/api/embed)
Где данные провайдер в США провайдер в США КНР наш компьютер
Стабильность фиксированные ID, страница deprecations фиксированные ID + алиасы имена-алиасы, версии меняются версия у нас, пока не сделаем pull
  • Общая облачная работа (промпты, извлечение из публичных текстов, tool calling на учебных инструментах) — DeepSeek deepseek-flash; deepseek-v4-pro — где flash не тянет и как «судья» в evals: судья должен быть сильнее проверяемой модели.
  • Всё, что касается заказов и покупателей магазина, журнала событий, копий базы, Telegram-отчётов — только Ollama, локальные модели. Данные магазина выдуманы, но обращаемся с ними как с настоящими — эта привычка понадобится на работе.
  • Эмбеддинги — Ollama (bge-m3, альтернативы — embeddinggemma и аналоги) или sentence-transformers локально: у DeepSeek эмбеддингов нет.
  • Claude / OpenAI — эталон для сравнения и для понимания индустрии; в вакансиях и чужом коде встречаются именно они.
  • Сравнить много моделей быстро — через OpenRouter, следующая глава.
  1. Artificial Analysis (≈25 мин). Открываем сводные графики «Intelligence vs Price» и «Output speed». Находим 3 модели на «границе эффективности» (лучшее качество за свою цену). Смотрим страницу одной open-weight модели: как сильно отличаются скорость и цена у разных хостинг-провайдеров одной и той же модели.
  2. LMArena (≈15 мин). Общий рейтинг и отдельные категории (код, длинные запросы, разные языки — если есть русский, стоит заглянуть). Играем 2–3 раунда «battle» сами: чтобы почувствовать, за что люди голосуют.
  3. Официальные страницы моделей и цен (≈30 мин) — отсюда берутся цифры для таблицы:
    • Anthropic: Models overview и Pricing;
    • OpenAI: Models и API Pricing;
    • Google: Gemini models и Gemini pricing;
    • open-weight: OpenRouter models — каталог с ценами разных хостингов и контекстом (удобно для Llama, Qwen, Mistral, DeepSeek). Обращаем внимание: какие модели reasoning, у каких есть vision, где цена ступенчатая по длине промпта.
  4. DeepSeek: Models & Pricing и Rate Limit & Isolation (≈15 мин). Выписываем: какие версии стоят за deepseek-flash и deepseek-v4-pro, цены с кэшем и вне пика, лимиты конкурентности. Заглядываем в раздел News/Change Log — как часто меняются модели за именами.
  5. Ollama: каталог моделей с фильтрами tools / thinking / embedding и страница macOS (или аналогичная для своей ОС) (≈15 мин). Находим 2–3 модели, которые влезут в память нашего компьютера рядом с остальными программами (для 8 ГБ — до ~3 ГБ), и отмечаем, какие из них cloud (не локальные).
  6. Таблица ниже, в практике (≈30 мин).
  • Имена моделей и цены устаревают за месяцы. Таблица в notes/models.md — с датой и ссылками на источник. Ценам из статей и из памяти LLM (в том числе этого учебника) верить нельзя.
  • Алиасы vs фиксированные версии. Алиас вида «latest» может незаметно поменять модель — и поведение продукта. Для продакшена фиксируем конкретный ID и меняем осознанно, с evals.
  • Deprecation. Модели снимают с поддержки; у провайдеров есть страницы с датами. Код, где модель зашита в двадцати местах, — технический долг.
  • Смешанная цена в рейтингах (blended price) считается при условном соотношении input:output. В конкретной задаче оно может быть другим: RAG — много input, генерация текстов — много output.
  • Скорость одной open-weight модели различается у хостингов в разы, а квантованные версии (меньше бит на вес) могут быть заметно хуже по качеству.
  • «Лучшая модель на Arena» ≠ лучшая для извлечения JSON или для агента с инструментами.
  • Данные: для учебных задач всё равно, но в работе первым делом спрашивают, куда уходят данные и хранит ли их провайдер. Для приложения магазина правило то же: во внешнюю модель — только то, что не жалко показать.
  • 1. Таблица моделей. notes/models.md, 10–12 моделей: обе модели DeepSeek, 2 локальные модели Ollama, которые реально запускаются на нашем компьютере, минимум по 2 от Anthropic, OpenAI, Google для сравнения и 1–2 open-weight из других семейств (Llama, Qwen, Mistral). Колонки:

    | модель (точный ID) | провайдер | тип (reasoning/гибрид/обычная) | open-weight? | контекст | input $/1M (промах/кэш) | output $/1M | модальности | где данные | сильные стороны | источник, дата |

    Для Ollama вместо цены — размер, память и токенов/с на нашем железе (замеряем как в главе 1.7). Цены и контекст — только с официальных страниц или OpenRouter для open-weight; рядом дата.

  • 2. Позиция на графике. Для 5 моделей из таблицы находим сводный индекс качества и скорость на Artificial Analysis; добавляем колонки.

  • 3. Цена нашей задачи. Берём классификатор отзывов из главы 2.1 (средние input/output токены на запрос из своих логов). Считаем стоимость 10 000 классификаций в день × 30 дней для каждой модели таблицы через estimate_cost из главы 1.7 (цены новых моделей добавляем в PRICES). Добавляем колонку «$/месяц для классификатора».

  • 4. Обоснования. Под таблицей — выбор модели с обоснованием в 2–3 предложения для четырёх задач:

    1. классификация 10 000 публичных отзывов о товарах в день;
    2. Telegram-бот, отвечающий на вопросы по базе знаний магазина (правила доставки, возврата, гарантии) с цитатами;
    3. агент, который пишет и правит Python-скрипты анализа заказов (на копии БД);
    4. извлечение данных из скриншотов/PDF-счетов поставщиков и служб доставки.

    Для каждой задачи отдельно отвечаем на вопрос «куда уходят данные»: задачи 3 и 4 с копией базы магазина (там персональные данные покупателей) и настоящими счетами — только локальная модель (и честно записываем, хватит ли её качества и что придётся упростить); облако — только на демо-данных.

  • 5. Алиас под капотом. Делаем один запрос к deepseek-flash и записываем поле model из ответа. Сравниваем с версией на странице цен. Записываем в заметку, как будем замечать подмену модели за алиасом (лог model + дата + evals).

  • notes/models.md содержит таблицу из 10–12 моделей с ценами, контекстом, типом, местом обработки данных и датой/источником, включая DeepSeek и 2 локальные модели, проверенные на своём компьютере.
  • Для четырёх задач записан выбор модели с аргументами по качеству, цене, задержке и функциям API.
  • Можем за 2 минуты устно обосновать выбор модели под задачу и сказать, как проверим его evals.

Вопрос 1

Чем reasoning-модель отличается от обычной и за что приходится платить при её использовании?

Reasoning-модель генерирует внутреннее рассуждение перед ответом; сильнее на сложных задачах. Рассуждение оплачивается как output-токены и увеличивает задержку.

Вопрос 2

Что лучше всего измеряет LMArena?

  • a) точность извлечения JSON
  • b) предпочтения людей в диалоге
  • c) скорость генерации
  • d) стоимость

b. Arena — рейтинг по попарным голосам людей.

Вопрос 3

Какие две причины делают RAG нужным даже при контекстном окне в 1M токенов?

Цена (каждый input-токен оплачивается в каждом запросе) и задержка растут с длиной; качество поиска нужного факта в очень длинном контексте хуже, чем в коротком релевантном.

Вопрос 4

Что такое contamination бенчмарка?

Ситуация, когда задачи теста попали в обучающие данные модели, и результат отражает запоминание, а не умение.

Вопрос 5

Что не так в этом решении?

MODEL = "some-model-latest" # best on the leaderboard this week
# used directly in 14 files

Алиас «latest» может поменять модель незаметно для команды; выбор по рейтингу, а не по evals; ID размазан по коду, а должен быть в одном конфиге.

Вопрос 6

Нужно выбрать модель для классификации 10 000 отзывов в день. Почему начинать с самой дорогой модели — нормально, а оставаться на ней — скорее нет?

Сильная модель показывает потолок качества и помогает отладить промпт; на объёме 10 000/день разница в цене огромна, и после evals обычно находится более дешёвая модель, которая проходит планку.

Вопрос 7

Почему «смешанная цена» на Artificial Analysis может ввести в заблуждение?

Она считается при фиксированном соотношении input:output, а у конкретной задачи соотношение может быть совсем другим.

Вопрос 8

Две модели: A — $1/$5, B — $0.2/$1 за MTok. На своих evals A — 95%, B — 80%. Что ещё нужно знать, чтобы выбрать?

Цену ошибки и можно ли её обнаружить (повтор, ручная проверка); требуемую планку качества; объём запросов, задержку, токены на запрос. Тогда сравнить цену за правильно решённую задачу.

Вопрос 9

Какие два преимущества есть у open-weight моделей перед закрытыми API?

Например: данные не покидают свою инфраструктуру; версия не меняется без ведома команды; полный контроль над сэмплированием и возможность дообучения.

Вопрос 10

Что такое TTFT и для какой задачи из практики он критичнее всего?

Time To First Token — время до первого токена ответа. Критичнее всего для интерактивного Telegram-бота (задача 2).

Вопрос 11

Почему deepseek-flash с точки зрения стабильности похож на алиас «latest», и как с этим жить?

За именем стоит конкретная версия, которую DeepSeek меняет без смены имени (так уже было с deepseek-v4-flash). Логировать поле model из ответа и дату, держать имя модели в конфиге и перепроверять качество evals после замены.

Вопрос 12

Нужны эмбеддинги для RAG по базе знаний магазина. Можно ли взять их у DeepSeek? Что взять вместо?

  • a) да, эндпоинт /embeddings
  • b) нет, у DeepSeek эмбеддингов нет — Ollama (/api/embed) или sentence-transformers локально
  • c) только у Anthropic
  • d) эмбеддинги не нужны при контексте 1M

b. В API DeepSeek эндпоинта эмбеддингов нет (на ноябрь 2026); эмбеддинги делают локально — это заодно решает вопрос приватности.

Вопрос 13

Почему модель из каталога Ollama с меткой cloud не подходит для данных покупателей магазина, а qwen3:8b на ноутбуке с 8 ГБ RAM подходит только с оговорками?

Cloud-модель выполняется на серверах Ollama — данные покидают компьютер, хоть Ollama и обещает их не хранить. qwen3:8b локальна, но занимает ~5 ГБ: на 8 ГБ RAM рядом с браузером и IDE — только при закрытом остальном, иначе swap; по умолчанию для 8 ГБ — 4B-класс, а 7–8B — нормальный выбор от 16 ГБ.

Сначала [2.4 · OpenRouter: один API ко многим моделям (гл. 2.4)](/week-02/2-4/) — там прогоним один промпт через несколько моделей из своей таблицы за один ключ. Таблица пригодится и в [2.5 · Упражнение: JSON из 20 текстов (гл. 2.5)](/week-02/2-5/): там прогоним извлечение и впервые увидим качество модели в цифрах, а на этапе evals — сравним несколько моделей из таблицы на одном наборе данных.