Классификация текстов: метки, отказ от классификации и оценка
Автор: Ai Flowi · Опубликовано
Классификация текстов назначает одну или несколько меток единице текста по заданной таксономии. Такой единицей может быть документ, аннотация или фрагмент; таксономия определяет смысл меток. Полезный классификатор также умеет отказаться от назначения метки, когда текст не подтверждает метку или не позволяет разрешить конкуренцию между метками.
Задачи с одной меткой, несколькими метками и иерархией
Классификация с одной меткой выбирает одну категорию для каждого принятого входного текста. Если текст затрагивает несколько тем, нужен критерий выбора. Указания «выберите главную тему» недостаточно, если проверяющие расходятся в том, означает ли «главная» начальную тему, самое длинное обсуждение или заявленную цель документа.
Классификация с несколькими метками допускает несколько независимо применимых категорий. Для каждой нужен критерий включения, а для пустого набора — способ представления. Иерархия организует метки в родительские и дочерние категории, например «Операционная деятельность», а затем «Инфраструктура». Решите, можно ли принять родительскую категорию без дочерней и разрешены ли несколько ветвей.
Эти структуры задают условия задачи, а не измеряют сложность модели. Ответ с несколькими метками не подходит целевой системе, принимающей одну категорию, если проверенное правило не разрешает ситуацию. Иерархия может описывать таксономию, хотя сама задача всё ещё требует одну конечную метку.
Вымышленная таксономия для аннотаций документов
Вымышленный сценарий внутренних документов с разрешённым доступом; запуск классификатора не заявляется. Представьте исследовательскую команду, распределяющую аннотации по указателю. Версия таксономии topics_v1 использует три категории для выбора одной метки и состояние проверки.
| Метка | Включать | Исключать или проверять |
|---|---|---|
| Методы | Процедуры сбора или анализа измерений в исследованиях. | Обслуживание помещения с оборудованием без процедуры измерения. |
| Инфраструктура | Помещения, инженерные системы и обслуживание пространств общего пользования. | Правила одобрения исследований или хранения их записей. |
| Управление | Ответственность за проверку, разрешения и правила хранения записей. | Простое упоминание комитета без правила или решения. |
| needs_review | Недостаточный текст, конкурирующие категории без правила приоритета или тема вне таксономии. | Не используйте это состояние как четвёртую тематическую категорию в статистике тем. |
Рассмотрим три вымышленные аннотации: «Процедура калибровки температурных измерений» подтверждает метку «Методы»; «График проверки лабораторной вентиляции» — «Инфраструктура»; «Правила одобрения и хранения записей исследования» — «Управление». Это учебные метки, назначенные автором, а не предсказания.
«Требования к одобрению ремонта лаборатории» касаются и инфраструктуры, и правила одобрения. При схеме с одной меткой без правила приоритета верните needs_review и сохраните обе причины. В проверенной схеме с несколькими метками могли бы применяться и «Инфраструктура», и «Управление». Изменение структуры меток меняет правильный ответ.
Чем классификация, распознавание сущностей и поиск ключевых слов отличаются друг от друга?
Документ может упоминать университет, хотя его тема — обслуживание вентиляции. Распознавание именованных сущностей выделяет фрагмент с этим названием и определяет его тип; классификация назначает метку аннотации целиком. Эти результаты отвечают на разные вопросы.
Тематическое ключевое слово — основание для проверки, но не обязательно правило классификации. Слово «одобрение» может встречаться в исключении, цитате или второстепенном предложении. Начните с детерминированного сопоставления, если категория явно задана в доверенном поле. Используйте интерпретацию, когда тему нужно вывести из разрешённого текста, и сохраняйте границу таксономии, обосновывающую этот вывод.
В руководстве по классификации заявок поддержки метки применяются для первичной обработки и маршрутизации заявок. В этом примере указателя документов нет требований к очереди, серьёзности проблемы или действиям в отношении клиента. Здесь условия назначения меток касаются тематики и возможности проверки.
По теме: Выделение ключевых слов в тексте: фразы и подтверждающие цитаты.
Отказ от назначения метки — решение, а не ошибка разбора
Явно указывайте причину отказа: недостаточное содержание, выход за таксономию, конфликт тем или неподтверждённый результат. Сохраняйте исходную ссылку на документ и версию таксономии. Корректно оформленная запись needs_review может соответствовать формату результата и при этом не подходить для автоматического индексирования.
В сокращённой аннотации может отсутствовать предложение, определяющее её тему. Если после сокращения осталось только «ремонт лаборатории», «Инфраструктура» выглядит правдоподобно, даже когда пропущенный фрагмент объясняет правила одобрения. Фиксируйте, какая версия текста классифицирована, и помечайте неполную аннотацию для проверки по topics_v1. Метка фрагмента не должна незаметно становиться меткой невидимого полного документа.
В этом примере предлагаемый результат приложения содержит поля document_ref, taxonomy_version, label, evidence_excerpt и abstention_reason. Метка вне утверждённого набора нарушает условия результата. Допустимая метка с нерелевантным подтверждением — семантическая ошибка. Фиксируйте эти случаи отдельно.
Пример матрицы ошибок
Пример расчёта, составленный вручную, а не результаты сравнительного тестирования. Предположим, шесть размеченных примеров получили гипотетические назначения ниже. Строки показывают эталонные метки, столбцы — предложенные. Каждая строка содержит два примера.
| Эталонная / предложенная | Методы | Инфраструктура | Управление |
|---|---|---|---|
| Методы | 2 | 0 | 0 |
| Инфраструктура | 0 | 1 | 1 |
| Управление | 1 | 0 | 1 |
На диагонали — четыре правильных назначения из шести. Точность метки «Методы» — два правильных предсказания «Методы» из трёх предсказаний этой метки; её полнота — два найденных примера «Методы» из двух эталонных. Для «Инфраструктуры» одно предсказание верно из одного предложенного, но найден только один из двух эталонных примеров. Это различие выявляет ошибки, которые может скрыть общий итог.
Фиксируйте отказы отдельно от этой матрицы принятых назначений. Если ещё два примера отложены для проверки, оцениваемый набор содержит восемь примеров, а охват принятыми назначениями — шесть из восьми. Не показывайте долю правильных принятых назначений без указания этого охвата и анализа случаев, направленных на проверку.
Оценка на отложенном наборе и изменение меток
Держите отложенный набор отдельно от примеров, использованных для составления таксономии или настройки промпта. Включите короткие аннотации, смешанные темы и темы вне таксономии. До разделения сгруппируйте почти одинаковые документы, чтобы слегка отредактированная копия не попала одновременно в наборы разработки и оценки.
Попросите проверяющих разметить данные независимо, затем изучите расхождения. Неясный критерий включения — проблема таксономии; предсказание, нарушающее согласованное правило, — ошибка модели. Сохраняйте неразрешённые разногласия людей вместо предположения, что каждый эталон бесспорен.
Дрейф таксономии возникает при изменении смысла меток или категорий. Присваивайте таксономии версии и фиксируйте соответствие старых категорий новым до сравнения количеств. Изменение языка документов или распределения тем — другой сдвиг; он может менять характер ошибок даже при неизменных метках.
Границы компонентов AI Flowi Workflow
Используйте записи каталога Structured Output и Batch Run для изучения интерфейсов, на которых основаны эти испытания таксономии документов.
Оба испытания отвечают на один вопрос о тематической метке при разных объёмах входных данных. В пакетном испытании сохраняйте ссылки на документы в копии для проверки, но передавайте модели для интерпретации только аннотацию. Административная папка «Управление» не должна становиться основанием для классификации аннотации о процедурах измерения. Сверяйте полученную метку с текстом, а не с местом хранения.
пример конфигурации, а не зафиксированный тест
Для одной аннотации передайте ссылку на документ и текст через Structured Output.input_value. Установите system_prompt в проверенные критерии включения topics_v1 и правила needs_review; установите schema_name в document_topic и настройте проверенную таблицу типа Table в поле output_schema для предлагаемых полей результата. В поле modelвыберите настроенную модель, совместимую с LanguageModel.
Для отдельного пакетного испытания передайте таблицу типа Table с разрешёнными данными через Batch Run.df, установите column_name в abstract и output_column_name в topic_proposal, а таксономию поместите в system_message. Проверьте, сохраняется ли связь ссылок на источники со значениями результатов. Наличие прямой цепочки от Structured Output к Batch Run или принудительно обеспечиваемой схемы пакетного результата не заявляется.
Оба варианта требуют вашей собственной учётной записи и ключа API поставщика модели; услуги поставщика оплачиваются отдельно. Structured Output и Batch Run документированы в каталоге; не проверены Ai Flowi в производственной среде. Используйте ручную проверку при небольшой коллекции или когда метки управляют решениями со значимыми последствиями. В разделе сценариев использования приведены существующие примеры рабочих процессов с собственными границами применения; структурированный вывод объясняет ограничения формата.