Части 1, 2, 3, 4-1, 4-2, 5, 6, 7, 8, 9,
В первой части этой статьи мы освоили создание базовой структуры данных для документов, находящихся в материалах дела, и загружать её в GPT-системы.
Теперь мы переходим к следующему этапу — к пониманию и использованию этой базы данных в контексте возможностей, которые предоставляют системы GPT.
Стоит отметить, что полностью охватить все аспекты использования таких систем невозможно, и, к счастью, это и не требуется в рамках юридической практики. Однако в контексте примера конкретного судебного процесса мы сможем выделить наиболее полезные и практичные решения, которые окажутся востребованными в повседневной практике юриста.
Прежде чем приступить к практической работе с загруженным списком данных, необходимо убедиться, что система воспринимает эти данные как совокупность, а не как текст. В противном случае результаты могут быть аналогичны тем, что представлены на рисунке 2.
Проверить это можно, задав запрос с объёмным результатом ответа. Для проверки необходимо задать запрос, содержащий требование на выдачу результата не менее 2000 знаков.
Такой запрос позволяет системе продемонстрировать, как она обрабатывает и воспринимает данные, что даёт возможность увидеть максимальную область информации, который она идентифицирует как базу данных.
Второй аспект, который проверяется предыдущим действием, — это тот, что всю ли информацию восприняла GPT-система. На языке программирования такие действия называют «проверкой целостности базы данных». Данная процедура важна для обеспечения корректной работы системы и предотвращения возможных ошибок в дальнейшем и согласуется со стандартами, таким как ГОСТ Р ИСО/МЭК 9075-93 и ГОСТ 34.321-96, а также «Требованиям по безопасности информации», утверждённым приказом ФСТЭК России от 14 апреля 2023 года № 64.
Одним из ключевых факторов, влияющих на результаты анализа, является сохранность данных во времени GPT-системами. Хотя эти системы сохраняют сеанс работы, но время этого сохранения ограничено.
Я лично наблюдал, как уже на следующий день GPT-система утрачивает доступ к предыдущей информации, и приходится вводить данные заново. С бытовой точки зрения такое поведение вполне объяснимо и понятно. Представьте себе, сколько информации будет накоплено в хранилище данных от сеансов работы, которые были забыты пользователями. В течение года или двух объёмы таких данных могут достичь колоссальных размеров, измеряемых миллионами серверных хранилищ.
Поэтому процедура автоматической дезактивация старых сеансов представляется абсолютно необходимой для поддержания высокой производительности и эффективности работы всей системы.
Из вышесказанного следует, что, прежде всего, перед тем как начать анализировать факты из базы данных, требуется тщательно подготовить соответствующую инфраструктуру для хранения информации. Ставим эту задачу перед собой - создать специальную папку и продумать систему именования файлов и алгоритма именования файлов.
Объём этих файлов невелик, но чтобы не потерять результаты и развивать альтернативные предположения вашего исследования, необходимо разработать понятную систему, которая позволит отслеживать ход анализа.
Рекомендуется использовать интуитивно понятную систему именования, которая поможет быстро определить, какая идея была проанализирована в каждой группе файлов. Поэтому первое правило - исходные данные называть таким образом, чтобы исключить возможность их смешивания с другими файлами. При необходимости анализа различных вариантов событий необходимо создавать копии исходных данных, добавляя к ним идентификаторы направлений.
Важно отметить, что все технологии, работающие с базами данных, включая SQL Python или другие, действуют аналогичным образом - они последовательно преобразуют исходную базу данных с использованием простых команд, создавая промежуточные таблицы до достижения конечного результата. Но языки программирования позволяют скрыть промежуточные этапы обработки данных и представить только окончательный результат работы программы.
Мы подошли к этапу осваивания возможностей по поиску новых фактов в систематизированном списке. Прежде чем приступить к процессам преобразования, классификации, сортировки и кластеризации, необходимо вспомнить основные принципы, которые имеют ключевое значение для работы юриста.
Во-первых, мы работаем с текстовой информацией, не используя табличные формы представления данных, что требует от нас умения анализировать большие объёмы текста и выделять из них нужную информацию.
Во-вторых, необходимо обеспечить возможность сохранения исходных данных и результатов исследования на доступном носителе в нужное время и нужном месте с минимальным риском потери найденной информации. Это даёт нам возможность в любой момент вернуться к найденной информации и использовать её в дальнейшей работе.
В-третьих, мы используем естественный язык общения, чтобы задавать преобразования и получать результаты. В ChatGPT имеется возможность провести необходимые преобразования через формулы SQL, но мы отказываемся от этого варианта, предполагая что у юриста нет времени на освоение этого языка.
Учитывая эти ограничения, при работе с текстовым представлением данных, лучше всего подойдут следующие форматы: TXT, JSON или XML.
На рисунке 3 представлена сравнительная схема этих трёх форматов. Как видно из рисунка 3 отличие форматов от естественного языка заключается в процессе формирования разметки, а также введении вводных и заключительных элементов.
Формат JSON - более новый по сравнению с XML, но XML является естественным языком Word и Excel, то есть напрямую воспринимается этими программами. Это означает, что данные в формате XML могут быть легко восприняты этими программами без дополнительных трансформаций.
В отличие от XML, формат JSON читается Excel’ем, начиная с версии 2016 года и только через Power Query. Этот аспект делает работу с данным форматом значительно сложнее для тех пользователей, кто не имеет соответствующего опыта, включая представителей юридической профессии.
При этом, из рисунка 3 видно, что формат JSON «экономнее», то есть требует меньше токенов при загрузке в GPT-системы, что означает меньшие затраты на обработку информации. Выбор формата JSON может стать предпочтительным решением в ситуациях, где важна оптимизация расходов и эффективности.
Ранее я упоминал, что текстовая загрузка в GPT-систему может привести к неопределённости результатов. Однако, представление информации в формате баз данных, таких как JSON или XML, дисциплинирует используемые системы при формировании необходимой структуры и порядок в ответах при работе с большими объёмами информации, превышающими 2000 знаков.
Такое состояние, на мой взгляд, обусловлено относительной новизной данной технологии, но уверен, что со временем она будет усовершенствована до уровня, обеспечивающего возможность получать надёжные и предсказуемые результаты.
Тем не менее, на текущем этапе для выполнения задач юристов и определённых в этой публикации, можно использовать следующую последовательность действий:
1.Формирование списка.
2. Открытие сеанса.
3. Загрузка списка.
4. Форматирование списка в JSON или XML.
5. Сохранение результатов.
6. Открытие нового сеанса.
7. Загрузка данных в формате JSON или XML.
8. Преобразование, классификация, сортировка, кластеризация, проверка дубликатов, упорядочивание.
9. Сохранение результатов.
Эту последовательность действий можно представить в виде схемы, показанной на рисунке 4.
Процесс сохранения результатов в форматах JSON и XML показан на рисунке 5. Он составляет следующую цепочку:
1) Создание отдельного файла в Word для JSON и XML, удобней всего в виде «Имя БД_JSON/XML_год-месяц-день». При таком имени вы сразу будете видеть в проводнике нужную группу, а дата будет подсказывать последнюю версию;
2) Сохраняем файл Word’а в txt-формате, и при сохранении выбираем кодировку UTF-8.
3) Переименовываем расширение с “txt” на JSON/XML.
Все файлы доступны во всех системах.
Размышляя над вопросом о том, как наглядно и кратко описать процесс формирования запросов к GPT-системе при работе с базой данных, я столкнулся с трудностью нахождения оптимального подхода. Этот процесс объёмный и требует внимания к множеству деталей.
Вспоминается анекдот: «Ночь, светится один фонарь, и вокруг него ходит человек и что-то ищет. К нему подходит товарищ и спрашивает: «Что ищешь?» — «Да ключи потерял», — ответ. «И где потерял?» — «Да где-то там», — машет в сторону темноты первый. «А почему здесь ищешь?» — удивляется второй. И в ответ слышит: «А тут светло».
Этот пример иллюстрирует проблему поиска решений там, где удобнее, а не там, где они действительно могут находиться. Чтобы увеличить вероятность успеха, необходимо принести источник света в то место, где потеряны ключи, вместо того, чтобы пытаться усилить освещение на месте, которое кажется удобным.
Поэтому и предлагается на промежуточном этапе представить результаты в виде, который можно рассмотреть под светом IT-решений (таблица XML). Этот подход может оказаться более целесообразным и экономичным, нежели попытка усилить вычислительные мощности системы ради достижения цели.
Отправить же материалы дела программисту и попросить с помощью IT-технологий найти те несколько узелков, которые позволят обосновать и достичь необходимого представления в судебном процессе, полагаю, что все согласятся — это довольно утопическая надежда. Мы понимаем, что даже самые современные технологии не могут полностью заменить человеческий опыт и интуицию, особенно в таких сложных областях, как право.
Для читателей на рисунках 6 и 7 я показал некоторые яркие примеры промтов моего общения с GPT-системами, которые представляют на сколько машинное решение требует участие человека.
Продолжение следует
Часть 1. Давайте дружить
Часть 2. Криминалистическое описание
Часть 3. Дефекты печати, пока не преодолимо
Часть 4-1. Систематизация (1)
Часть 4-2. Систематизация (2)
Часть 5. Инструменты GPT
Часть 6. Zero-shot - контролируй соперника
Часть 7.
Часть 8.
Часть 9.