Если пользователи будут получать ответы некорректные, то это в любом случае плохо. Мы не можем просить задавать только простые вопросы.
Еще проблема, что сложность субъективна. По одному из вопросов у нас возник спор.
Звучит пункт примерно так: Заказчик должен подписать акт приемки через 5 дней после уведомления о доставке в электронной системе, но не позднее 20 дня.
Вопрос: может ли заказчик подписать акт приемки на 5 день после уведомления?
Для художественной и профессиональной литературы, где одна и та же мысль повторяется многократно в разных абзацах достаточно чанкирования по абзацам и даже работает по словам с 20% перекрытием.
Для регламентов важен каждый пункт.
А вы все законы через ada пускаете? Я бы предложил локальный токенайзер. Дешевле.
Да, он используется исключительно как референс. Я думаю, что никто не будет отрицать, что GPT4 на сегодняшний день это эталон. Поэтому все локальные решения нужно делать сравнивая с ним в %.
Все так. Если нет никаких ограничений по облаку и зарубежным сервисам, то можно не заморачиваться и просто бить на огромные куски. GPT4-Turbo контекст больше Claude. 128К токенов. Это десятки страниц... И он работает, только дорого получается. около 0.2 $ за запрос.
В юридических документах пункты могут содержать очень мало информации и релевантны только в сочетании с родительским пунктом. Например:
Товар можно отправлять в термоконтейнерах, когда:
1. Есть указание в заказе наряде
1.2. Груз содержит реагенты с хранением до -4
Товар нельзя отправлять в термоконтейнерах, когда:
2.1. Есть указанием в заказе наряде
2.2. Есть груз содержит реагенты с хранением более 15 градусов
Соответственно пункты 1.1. и 2.1. индентичны и имеют смысл только в сочетании с родителем.
По второму вопросу (суммаризация чанка):
Рассматривал в теории, но пока решил отказаться. Так как вопросы по тексту задавали с очень конкретным контекстом: перечисли случаи когда можно делать хххх. Сколько дней даётся на подписание документа Y. А можно ли подписать акты на 12 день? А на 9 дней после приемки? ---- Кажется, что при суммаризации все эти детали потеряются.
Но соглашусь, что гипотезу можно проверить и делать вектора по саммари.
По окну контекста:
Так смысл состоит в том, чтобы выбрать эти релевантные пункты. В самом начале я вообще перевёл регламент на английский язык и смог запихнуть большую главу сразу в промпт. И это работало. Но хочется как-то более оптимально.
Хотя конечно были идеи, все перевести на английский и кидать сразу по 50 страниц.... Но эта идея разбивается о требование, чтобы все работало в закрытом контуре или хотя бы на отечественных решениях.
А какая бизнес разница?
Если пользователи будут получать ответы некорректные, то это в любом случае плохо. Мы не можем просить задавать только простые вопросы.
Еще проблема, что сложность субъективна. По одному из вопросов у нас возник спор.
Звучит пункт примерно так: Заказчик должен подписать акт приемки через 5 дней после уведомления о доставке в электронной системе, но не позднее 20 дня.
Вопрос: может ли заказчик подписать акт приемки на 5 день после уведомления?
Мнения юристов, меня и GPT разошлись
Верно подмечено.
Для художественной и профессиональной литературы, где одна и та же мысль повторяется многократно в разных абзацах достаточно чанкирования по абзацам и даже работает по словам с 20% перекрытием.
Для регламентов важен каждый пункт.
А вы все законы через ada пускаете? Я бы предложил локальный токенайзер. Дешевле.
Да, кстати тоже заметил, что гпт3 вполне годен.
Принято. Добавлю Claude в исследование.
Меня уже попросили Мистраль добавить.
Да, Макс. Согласен ручная разметка вообще топчик. И кстати это может быть намного дешевле в итоге, чем городить онтологический граф.
Да, он используется исключительно как референс. Я думаю, что никто не будет отрицать, что GPT4 на сегодняшний день это эталон. Поэтому все локальные решения нужно делать сравнивая с ним в %.
Все так. Если нет никаких ограничений по облаку и зарубежным сервисам, то можно не заморачиваться и просто бить на огромные куски. GPT4-Turbo контекст больше Claude. 128К токенов. Это десятки страниц... И он работает, только дорого получается. около 0.2 $ за запрос.
По первому вопросу (Иерархия):
В юридических документах пункты могут содержать очень мало информации и релевантны только в сочетании с родительским пунктом. Например:
Товар можно отправлять в термоконтейнерах, когда:
1. Есть указание в заказе наряде
1.2. Груз содержит реагенты с хранением до -4
Товар нельзя отправлять в термоконтейнерах, когда:
2.1. Есть указанием в заказе наряде
2.2. Есть груз содержит реагенты с хранением более 15 градусов
Соответственно пункты 1.1. и 2.1. индентичны и имеют смысл только в сочетании с родителем.
По второму вопросу (суммаризация чанка):
Рассматривал в теории, но пока решил отказаться. Так как вопросы по тексту задавали с очень конкретным контекстом: перечисли случаи когда можно делать хххх. Сколько дней даётся на подписание документа Y. А можно ли подписать акты на 12 день? А на 9 дней после приемки? ---- Кажется, что при суммаризации все эти детали потеряются.
Но соглашусь, что гипотезу можно проверить и делать вектора по саммари.
По окну контекста:
Так смысл состоит в том, чтобы выбрать эти релевантные пункты. В самом начале я вообще перевёл регламент на английский язык и смог запихнуть большую главу сразу в промпт. И это работало. Но хочется как-то более оптимально.
Хотя конечно были идеи, все перевести на английский и кидать сразу по 50 страниц.... Но эта идея разбивается о требование, чтобы все работало в закрытом контуре или хотя бы на отечественных решениях.
Это можно назвать ретро стайл.
Но если серьезно, то существует великое множество готовых библиотек с учётом морфологии. GPT это даже овер для таких задач.
В крайнем случае можно прицепить триггер на insert в таблице и дергать по api анализ.