РУКОВОДСТВО · ОБНОВЛЕНО 2026-11-02
Большие идентификаторы в ответе LLM: как не потерять цифры в JSON
Контракт для номеров заказов и внешних ключей, над которыми не требуется арифметика.
Идентификатор заказа или документа не следует автоматически считать числом. В JavaScript обычный Number не гарантирует точность всех целых за пределами безопасного диапазона. Если длинный ID уже разобран как число, перевод результата в строку не возвращает потерянные цифры. Передавайте идентификаторы строками по согласованному контракту и сверяйте их с исходником. Сохраняйте ведущие нули, допустимый алфавит и длину. Успешная проверка JSON-схемы не исправляет изменение, произошедшее раньше при разборе ответа или в другом клиенте.
1. Определите назначение поля
Отделите идентификаторы от измеряемых значений. Если над номером не выполняют арифметику, строковый тип часто лучше передаёт его смысл. Опишите разрешённые символы, длину, регистр и наличие ведущих нулей. Не сокращайте длинный номер для удобства модели, если потом нужно найти точную запись. Сохраняйте фрагмент источника или внешний ключ, по которому приложение может проверить результат независимо от уверенного объяснения нейросети. Для неизвестного ID предусмотрите отсутствие значения, а не случайное число.
2. Проверьте границу разбора JSON
MDN описывает MAX_SAFE_INTEGER как границу безопасных целых Number. Проблема может возникнуть уже при обычном разборе числового литерала. Просьба вернуть кавычки должна сопровождаться проверкой типа в приложении. Если внешний контракт требует числовой int64, выбирайте парсер и представление, которые сохраняют точность, и проверяйте совместимость клиента. Не превращайте уже округлённое число в BigInt или строку в надежде восстановить исходный литерал: нужен оригинальный ответ или повторное получение корректного значения.
3. Сверьте все преобразования
Проследите путь ID через модель, SDK, JSON, очередь, базу, экспорт CSV и интерфейс. Табличный редактор тоже может преобразовать длинную строку в числовое представление. Не удаляйте пробелы и разделители произвольно, если они являются частью установленного формата. Сравнивайте нормализованное значение только по явным правилам источника. Нельзя автоматически исправлять последнюю цифру ради совпадения с существующей записью. Ошибка извлечения и отсутствие объекта должны иметь разные причины отказа.
4. Соберите пограничные примеры
Проверьте соседние большие идентификаторы, строки с ведущими нулями, пустое значение и буквенно-цифровой ключ. Ожидаемый результат должен совпасть посимвольно после прохождения всей цепочки. Добавьте случай, когда число приходит без кавычек, и убедитесь, что приложение не принимает его молча вопреки контракту. Проверяйте также копирование из интерфейса и скачанный файл. Используйте синтетические номера, чтобы тест точности не раскрывал реальные заказы, клиентов или секретные ключи в журнале проверки.
Частые вопросы
Поможет ли String после JSON.parse?
Только если значение ещё точное. Когда число уже округлено, строка сохранит ошибочный результат, а не исходные цифры.
Нужно ли хранить все числа строками?
Нет. Тип выбирают по смыслу и контракту. Для ID важна точная запись, для количества могут требоваться арифметика и другие проверки.
Зачем сохранять нули в начале?
Они могут быть частью идентификатора. Преобразование в число удаляет их и способно связать ответ с другой внешней записью.
Можно ли доверить исправление номера модели?
Модель может повторно извлечь значение из источника, но приложение должно проверить точное совпадение. Угадывать недостающие цифры нельзя.