Малая языковая модель для извлечения данных: описываете схему — получаете поля из текста и метки классов. Вендор заявляет около 95% экономии и менее 50 мс на вызов, но независимых замеров пока нет — разбираем честно.
ScaleDown Extract — узкая модель, а не чат-бот. Вы передаёте текст и схему полей: «номер заказа», «срок», «тональность». В ответ — готовая запись: значения, выбранные метки и позиции найденного в тексте.
Идея вендора: для однотипных потоков писем, тикетов и договоров не нужна дорогая универсальная LLM. Слабые места — нет независимых замеров, параметры не раскрыты, а рассуждать и отвечать модель не умеет: это делает ваша LLM.
scaledown/extract (LiteLLM, Bifrost)/extract на api.scaledown.xyzfields и entities (text, type, confidence, start, end)labelsДанные — документация LiteLLM, каталог Bifrost, README интеграции с LangChain и блог ScaleDown. Состав каталога в Strelka AI — в приложении.
Выберите пример и включайте или выключайте поля схемы: маркер, схема и запись справа меняются вместе. Поле без значения возвращается как null — это важный случай.
Иллюстрация формата ответа по README интеграции ScaleDown, а не вызов модели: значения подобраны вручную, смещения start/end посчитаны по тексту слева, confidence не показываем. Поле без значения — null.
Всё, что известно из открытых описаний интеграции: схема, вход, запись, ответ вашей LLM.
Словарь полей: поле-описание — значение берётся из текста; поле с labels — классификация.
В примере интеграции уходят только реплики пользователя, ответы агента исключены.
fields — значение с наибольшей уверенностью или null; entities — text, type, confidence, start, end.
Extract только извлекает. Если сервис недоступен, middleware работает «открыто» (fail-open) и пишет предупреждение.
labels: строки или объекты name и rubric. Модель выбирает метку по всему тексту.null — не как догадка. Это стоит проверить на ваших данных.ScaledownExtractionMiddleware({
"order_id": "Order number the customer mentions",
"sentiment": {"labels": ["frustrated", "neutral", "satisfied"]},
})
# результат: result["scaledown_extraction"]
# {"fields": {"order_id": "A-1042", "sentiment": "frustrated"}}
Код — из README репозитория scaledown-team/langchain-integration; импорты, версии и ключ API смотрите там. Нужны Python 3.10+ и langchain 1.3+.
Три темы: стоимость, скорость, точность. У каждой — кто измерял и чего мы не нашли. Цифры не проверены независимо.
В README интеграции с LangChain сказано, что Extract «заменяет вызовы извлечения сущностей фронтирной LLM» и обходится примерно на 95% дешевле. В совместном посте ScaleDown и Arthur — «в 10–15 раз дешевле» крупных моделей (базовые модели и условия не раскрыты).
Кто измерял: сам вендор и его партнёр. Независимой проверки нет.
Шкала условная: 100 — расходы на извлечение сущностей «большой» LLM. Абсолютные цены мы не приводим.
Вендор указывает менее 50 мс на вызов Extract против около 300 мс у извлечения «большой» LLM (в плохой день — около секунды). В посте с Arthur — «в 2–20 раз быстрее».
Кто измерял: сам вендор. Железо, нагрузка и модели сравнения не раскрыты.
Задержка одного вызова извлечения, а не всего ответа чата.
Для Extract числовых результатов мы не нашли. Вендор пишет, что точность «не хуже, а то и выше», а бенчмарк на наборе договоров CUAD опубликован в его блоге: на момент проверки страница не открылась. Цифры есть только у соседней модели classify.
Кто измерял: сам вендор, и это другая модель — classify. Не переносите цифры на Extract.
Классификация запросов для маршрутизации; значения для Mini и Nano — расчёт по заявленному разрыву в 3,46 и 10,86 п.п.
Отметьте, что про вас верно. Стрелка баланса покажет, стоит ли тратить время на тест, — честно, в том числе «нет».
Три из них описывает сам вендор; четвёртый — наш. У каждого — источник.
Из реплик клиента — номер заказа, суть жалобы, тип обращения и тональность. Это пример из README интеграции с LangChain.
order_id → «Номер заказа, который называет клиент» issue_type → billing | delivery | other sentiment → frustrated | neutral | satisfied
Источник: README scaledown-team/langchain-integration
Вендор описывает извлечение для голосовых помощников и чатов: продукт, канал, срок покупки, способ оплаты, тип проблемы, желаемое действие. Тут задержка критична — отсюда и заявленные менее 50 мс.
product → из каталога магазина intent → возврат | обмен | отслеживание order_id → из текста
Источник: пост ScaleDown об извлечении для e-commerce (данные вендора)
ScaleDown публикует бенчмарк Extract на CUAD — наборе договоров; поля — стороны, срок, неустойка. Результаты мы открыть не смогли: проверьте сами, прежде чем ссылаться на них.
contract_no → «Номер договора» term → «Срок действия» argument → null, если нет в тексте
Источник: блог ScaleDown «How We Benchmark Extract on CUAD»
Наш пример: из свободного письма достать адрес, время и способ оплаты. Хорошо работает, когда схема короткая и стабильная — и совсем плохо, когда каждое письмо нужно понять по смыслу.
address → «Адрес доставки» delivery_time → «Когда привезти» payment_method → card | cash | online
Идея Strelka AI: не пример вендора
Извлечение проверяют на своих данных: возьмите 20–30 сообщений, задайте базовый уровень в топовых моделях и сравните с Extract.
Зайдите в app.strelka.ai: без VPN и без зарубежной карты, оплата — российской картой.
Возьмите 20–30 реальных сообщений и прогоните через топовые модели из каталога приложения. Состав каталога смотрите в приложении — он меняется.
Extract — отдельный API ScaleDown: ключ берут на панели вендора. Те же сообщения, та же схема — сравните точность, null и скорость.
Ты извлекаешь данные. Из сообщения клиента верни JSON с полями: order_id (строго из текста, иначе null), issue_type (billing | delivery | quality | other), sentiment (frustrated | neutral | satisfied). Ничего не выдумывай. Сообщение: [вставьте]
Из текста договора извлеки contract_no, signed_on, term, penalty, arbitration. Если поля нет в тексте — null, а не догадка. Для каждого значения приведи цитату. [вставьте текст]
Вот 10 сообщений и схема. Верни таблицу «сообщение → поля» и отметь строки, где ты не уверен или где поле пришлось угадывать. [вставьте сообщения и схему]
Хорошая новость выглядит убедительнее, когда рядом написаны границы.
«≈95% дешевле», «менее 50 мс», «в 10–15 раз дешевле», «в 2–20 раз быстрее» — из материалов ScaleDown и совместного поста с Arthur. Условия замера (модели сравнения, нагрузка, железо) не раскрыты, а в одном из постов расчёт экономии не сходится.
Вендор пишет о бенчмарке на наборе договоров CUAD, но страница не открылась. Независимых тестов Extract нет. Единственные цифры точности — у соседней модели classify.
Размер модели, окно контекста, архитектура и данные обучения нигде не названы. В каталогах LiteLLM и Bifrost поля контекста пусты.
В примерах вендора схема привязана к таксономии магазина. Как Extract работает вне такого домена — неизвестно; без своего теста решение принимать нельзя.
Ответ пользователю формулирует ваша LLM. Изображения и файлы через LiteLLM отклоняются: «биллинг для них не покрыт текстовым тарифом».
Если сервис недоступен, middleware продолжает без извлечения и лишь пишет предупреждение, а поле без значения возвращается как null. Нужен код, который различает оба случая.
Запросы идут на api.scaledown.xyz; условий хранения данных мы не нашли. Вендор молодой: компания представлена в июне 2026 года. Для персональных данных нужен юридический разбор.
labels — классификация: метки могут быть строками или объектами с name и rubric. Пример схемы с order_id и sentiment приведён в README интеграции с LangChain.fields — значение с наибольшей уверенностью для каждого ключа схемы или null, если ничего не найдено; entities — найденные совпадения с полями text, type, confidence, start и end. Если сервис недоступен, middleware продолжает работу и пишет предупреждение.Сравните топовые модели на своих сообщениях и договорах — потом решайте, нужна ли узкая модель. Без VPN и без зарубежной карты.
