В этом материале
Текстовый поиск и поиск по изображениям страниц могут терять разные доказательства, поэтому страницы-кандидаты и ошибки представлений нужно проверять раздельно.
Nemotron 3.5 Embed стоит проверять на согласованном наборе текстовых запросов и изображений страниц: представление документа меняет саму задачу поиска. Успешная загрузка или более крупный checkpoint не доказывает, что схема, скан таблицы и цифровой абзац дадут одинаково пригодные подтверждения для ответа.
Хранить вариант вместе с контрактом входа
Официальная карточка 1B BF16 описывает конкретный checkpoint, а не произвольно заменяемый embedding-сервис. Его ревизия, процессор, инструкции запроса и подготовка документов составляют единую конфигурацию. Карточка 8B BF16 задаёт отдельного кандидата для сравнения. Подготовку старшего варианта нельзя переносить в младший только из-за общего названия семейства: сначала нужен явно подтверждённый контракт соответствующего варианта.
Собрать парный набор документов
Возьмём небольшое руководство оборудования с текстовой характеристикой, схемой подключения и сфотографированной таблицей. Сохраним оригинальную страницу, извлечённый текст, идентификатор страницы и ручную оценку релевантности. Один вопрос обслуживания проверим на каждом представлении. Так можно отличить визуальное подтверждение, потерянное при извлечении текста, от ошибки ранжирования доступного подтверждения внутри выбранного поискового представления документа.
| Вопрос | Текстовое подтверждение | Подтверждение на изображении |
|---|---|---|
| Какой разъём требуется? | Подпись и ссылка | Схема и обозначения |
| Какое ограничение действует? | Извлечённая строка таблицы | Строка с заголовками столбцов |
| Какая редакция актуальна? | Абзац о редакции | Заголовок и штамп |
Сохранить роли запроса и документа
Вопрос и документ остаются разными ролями входа там, где этого требует карточка. Поисковая обёртка может уже добавлять инструкцию; повторное добавление меняет вход. Финальный обработанный запрос следует хранить рядом с конфигурацией процессора документов. Сравнение теряет смысл, если один кандидат получает название документа, а другой — только безымянный текст без сопоставимого контекста и сведений о происхождении.
Сравнить поиск до генерации ответа
В анонсе семейства NVIDIA описаны retrieval-модели и мультимодальные возможности. Он не устанавливает качество на частном собрании руководств. Сначала проверяют попадание размеченной страницы в кандидаты. Затем смотрят, содержат ли возвращённые текст или изображение достаточно деталей для ответа. Генератор способен скрыть поисковый промах, предложив правдоподобную общую инструкцию обслуживания вместо ответа по конкретному источнику.
Разделить ошибки представления
Если текстовый поиск находит абзац, но пропускает вопрос по схеме, сначала проверяют полноту извлечения, а не меняют индекс. Если поиск изображений выбирает верную страницу, но теряет подпись, проверяют рендеринг, масштабирование и выбор страницы. Если оба варианта пропускают известный точный идентификатор, сравнивают токенизацию и формулировку запроса. Это разные причины с разными исправлениями; смешивать их в одной категории не следует.
Зафиксировать воспроизводимый выбор
Результат — небольшая матрица запроса, представления, ревизии checkpoint, релевантной страницы и объяснения ошибки. Текстовые и визуальные результаты остаются доступны отдельно даже при последующем объединении. Крупная модель может улучшить часть вопросов и увеличить эксплуатационные затраты, но направление изменения не следует из имени. Вариант принимают после проверки того, какие подтверждения он сохраняет и какие ошибки всё ещё остаются.
Связанные материалы: Embeddings и rerankers: другие задачи для свободного GPU; Размерность эмбеддингов: как посчитать память индекса.