by vladimir_pleshko » Tue Jun 01, 2004 5:28 pm
> > 1. Единицей выдачи системы является пассаж - фрагмент
> текста (не более 250
> > символов). Он же является единицей оценки.
>
> как насчет сделать длину параметром рана и иметь несколько разных
> альтернативных номинаций? (типа 150/300 или 250/500?)
>
> В заголовке xml файла будет написано какой размер имеется ввиду.
Я вообще думал выдавать попытаться предложения... Если выбирать из
предложенного, то я бы остановился на варианте 150/300.
>
> > 2. Пассаж описывается смещением (с 0) в байтах от начала исходного
> > документа и длиной в байтах.
>
> то есть длина с учетом html разметки? и это она меньше 250 байт?
> выглядит не очень удачно.
Я действительно нечетко написал. Конечно, длина извлеченного текста и
длина фрагмента в исходном документе - это разные вещи.
> Может быть указывать смещение на начало и приводить текст
> пассажа как его выделила система (вырезав разметку)?
Как тогда быть в случае, если система выдаст текст, находящийся
внутри комментариев или атрибутов alt или title? Засчитывать ли
такие фрагменты? Дело даже не в полезности информации, содержащейся
в этих элементах html, а в том как ее объективно и быстро оценить.
> Насколько я понимаю, мы хотим:
> 1) быть уверенными что выделенные текстовые фрагменты не
> длинее 250 байт
> [нужен только фрагмент]
> 2) иметь возможность показать фрагмент выделенный системой оценщику
> [нужен только фрагмент]
> 3) предоставить оценщику возможность заглянуть в контекст (в
> документ-источник)
> [нужно смещение в документе и фрагмент или смещение и длина
> фрагмента с разметкой]
Я не против включения самого фрагмента текста - это позволит
значительно ускорить работу средства оценки, что немаловажно.
Однако, также требуется иметь возможность достоверно воспроизвести
выделенный системой фрагмент в исходном документе.
>
> > 3. Пассаж может быть отнесен к одной или нескольким темам
> (скажем, не
> > более 3). Системы, которые не производят тематического картирования
> > пассажей, могут не указывать темы, или указывать тему "Прочее".
>
> лучше без тем, а если нет тем - это "прочее"
Перефразирую, если система не картирует, то не нежно ничего записывать,
если же картирует - то всегда должна быть хотя бы одна запись.
Если так, то я согласен.
> Вопрос: мы для этой дорожке как-то ограничиваем число фактов,
> которые можно
> вернуть системе?
Хороший вопрос. Я ожидаю высокую корреляцию между ответами систем в
смысле списков документов. По множеству фактов, разброс будет конечно.
Если предположить, что оценка будет происходить "подокументно", то
есть оценщик будет одновременно видеть все ответы системы по персоне
в рамках документа, то трудоемкость процесса оценки можно считать
пропорциональной оценке поисковой дорожки (напр. с коэф. 2).
Я бы ввел как в прошлом году для поиска ограничение в 100 документов,
а принял бы к рассмотрению первые 50, после упорядочения, напр.,
по возрастанию идентификаторов документов (чтобы повысить корреляцию
ответов систем). А можно упорядочить по убыванию числа фактов,
найденных в документе (чтобы котел был побольше). Либо оставить
упорядочение на усмотрение систем - первыми идут документы с более
"достоверными" фактами.
Т.к. графиков мы не строим, а все упирается в трудоемкость оценки, то
любой из способов ощутимо не навредит.
>Требуем ли упорядочить выдачу по
> какому-нибудь критерию?
Внутри ответа - упорядочение документов, видимо, произвольное (в
данном случае у нас нет понятия "релавантности документа").
Внутри документа - логичным выглядит упорядочение по возрастанию
смещений.
С уважением,
Владимир Плешко