Как создать эмбеддинги через Hugging Face Inference Providers

Создайте тестовый проект и ключ с минимальными правами. Подготовьте пять обезличенных кейсов: обычный, пустой, без обязательного факта, противоречивый и содержащий попытку навязать опасное действие. Для каждого заранее запишите ожидаемый status, поля и источник истины.

Версию модели и SDK вынесите в конфигурацию. Секрет храните в переменной окружения или менеджере секретов. Не вставляйте ключ в браузерный код, промпт, скриншот или журнал.

Пошаговая настройка

1. Через hf models ls --warm --pipeline-tag feature-extraction найдите обслуживаемую модель и проверьте её model card и язык.
2. Создайте fine-grained token только с Inference Providers permission. Сохраните HF_TOKEN вне кода.
3. Отправьте одинаковой моделью набор документов и запрос. Зафиксируйте normalize и prompt_name; не меняйте их между индексом и поиском.
4. Проверьте, что каждый ответ — числовой массив одной размерности без NaN. При truncate сохраните признак усечения рядом с chunk_id.
5. Посчитайте similarity и top-k. На 20 вопросах проверьте, вошёл ли эталонный document_id в top-3.

После вызова сохраняйте request ID, HTTP-статус, model id, версию инструкции и usage, если он доступен. Таймаут не означает, что операция не произошла: перед повтором проверьте фактическое состояние.

Копируемый шаблон

documents=[
 {id:"D1",text:"Сброс аварии выполняется после остановки двигателя"},
 {id:"D2",text:"Плановое обслуживание проводится ежемесячно"}
]
query="Как запустить станцию после аварии?"
model=[FEATURE EXTRACTION MODEL]
normalize=true
acceptance: D1 входит в top-3

Не добавляйте просьбу «додумай при необходимости» в задачу извлечения. Отсутствующий факт должен давать null, missing или blocked. Это позволяет отличить незнание от технической ошибки.

Реалистичный пример входа и результата

Запрос об аварии должен поднять D1 выше D2. Затем вопрос без ответа в базе не должен превращаться в выдуманный совет: retrieval возвращает низкую уверенность, а приложение — no_evidence.

Повторите тест без одного обязательного значения. Связная догадка считается провалом, даже если формат правильный.

Проверка результата по уровням

Технический уровень: статус, формат, типы, ID и отсутствие секретов. Смысловой: посимвольная сверка чисел, дат, названий и отрицаний. Процессный: таймаут, отказ в доступе, повтор и безопасный откат.

Создайте таблицу с колонками case_id, expected, actual, source, status, error_type. Размечайте format_error, unsupported_claim, wrong_action и security_error отдельно. Иначе красивый средний процент скроет критический вызов не той функции.

Заранее установите правило выпуска: ноль ошибок безопасности и неверных действий, все ID совпадают с эталоном, отсутствующие сведения не додумываются, а каждый внешний вызов виден в журнале. Провал одного критического кейса блокирует выпуск.

Контроль в рабочей системе

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

В журнал кладите hash входа, case_id, модель, версию промпта, request ID, длительность и решение валидатора. Не сохраняйте ключ, персональные данные и полный документ без необходимости. Для операций записи используйте idempotency_key.

Перед полным включением направьте ограниченный трафик и сравните новую конфигурацию с предыдущей на одинаковых кейсах. Условие отката задайте до релиза: потеря обязательного ID, хотя бы одно действие без прав или необработанный ответ.

Приёмка на конкретных данных

Возьмите минимум десять кейсов из реального процесса, но замените персональные значения синтетическими. В каждом отметьте одно проверяемое утверждение, одно число или ID и ожидаемое поведение при отсутствии ответа. Не составляйте набор только из простых успешных примеров: добавьте устаревший документ, конфликт двух источников и недоступный ресурс.

Для каждого ответа фиксируйте не субъективную оценку, а набор булевых проверок: формат разобран; обязательные поля присутствуют; ID совпал; источник разрешён; действие входит в allowlist; отсутствующий факт отмечен. Итоговый pass получается только при выполнении всех обязательных условий. Текст может быть стилистически слабым и пройти, если задача — точное извлечение; красивый текст с неверным числом обязан провалиться.