Как использовать Files API Claude: загрузка, file_id и удаление документа

Понадобятся API-ключ, тестовый документ без закрытых данных и серверное хранилище связи file_id с владельцем. Используйте тестовую копию. Удалите пароли, токены, персональные сведения и коммерческие секреты, если их обработка не разрешена. Секреты храните в переменных окружения или специализированном хранилище.

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

Пошаговый процесс

Загрузите файл через Files API официальным SDK или HTTP-запросом и сохраните возвращённый file_id, имя и MIME type. Никогда не принимайте file_id от пользователя без проверки владельца в своей базе.

В Messages API добавьте документ как content block с ссылкой на file_id и задайте узкий вопрос. Для проверки попросите название раздела или страницу, если формат поддерживает citations. По окончании проекта удалите файл API-методом согласно политике приложения. Обрабатывайте удалённый, недоступный и неподдерживаемый файл отдельными ошибками. Не храните токен и file_id в публичной ссылке или клиентском логе.

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

Готовый шаблон

Ответь только по документу file_id. Верни answer, evidence и missing. Для числа укажи единицу и место в документе. Если ответа нет, answer=null.

Замените квадратные скобки конкретными значениями. Не добавляйте «додумай при необходимости» в задачу извлечения фактов. Для программного потребителя сначала валидируйте форму, затем бизнес-правила и происхождение значений.

Пример входа и результата

Вход

Инструкция содержит давление 25 бар и расход 1,8 м³/ч, но не содержит массу станции.

Ожидаемый результат

Ответ извлекает давление и расход с единицами, массу возвращает null. После завершения теста временный файл удаляется.

Повторите тест без одного обязательного факта. Правильный ответ возвращает null, missing или blocked по вашей схеме. Убедительная догадка опаснее явной ошибки, потому что проходит дальше незаметно.

Три уровня проверки

На техническом уровне проверьте формат, статусы, ID и отсутствие секретов. На смысловом — вручную сверьте минимум три элемента, включая число, дату и отрицание. На процессном — воспроизведите таймаут и убедитесь, что повтор не создаёт дубль.

Меняйте один параметр за итерацию. Одновременная смена модели, промпта и данных лишает эксперимент смысла. Старую рабочую версию храните до полного регрессионного прогона.

Матрица тестов и критерии решения

Не оценивайте результат словами «вроде верно». Создайте таблицу с колонками case_id, input, expected, actual, source, status и error_type. Для извлечения данных сравнивайте каждое поле: точное совпадение для идентификаторов, чисел и перечислений; отдельно проверяйте допустимый null. Для текста заранее задайте обязательные факты и запрещённые утверждения. Кейс считается пройденным только тогда, когда выполнены все обязательные проверки.

Размечайте ошибки хотя бы на четыре класса: format_error — ответ нельзя разобрать; unsupported_claim — утверждение не подтверждается входом; wrong_action — выбрана неверная функция или операция; security_error — раскрыт секрет либо обойдена проверка прав. Такая классификация показывает, что именно исправлять. Изменение формулировки промпта редко устранит ошибку авторизации, а дополнительная схема не проверит истинность извлечённой цены.

Установите правило выпуска до теста. Например: ни одной ошибки безопасности и неверного действия; все идентификаторы совпадают посимвольно; отсутствующие сведения возвращаются как null; каждый внешний вызов виден в журнале. Это критерии приёмки, а не обещание точности модели. Если хотя бы один критический кейс провален, сохраните вход и конфигурацию, исправьте одну причину и повторите весь набор.