Develop

[audetv]

Начинаем делать парсер для вопрос-ответ видео выпуска.

Это будет парсер сервер по аналогии, как feed, с прицелом, что бы перенести и основной парсер вопросов/комментариев сюда же. Но сначала только видео выпуски и комментарии к ним.

Предполагаю, что выпуск вопрос ответ надо сразу разбивать на чанки по 1800 - 3600 символов, для поисковой выдачи, а в контексте будет целый выпуск с комментариями. Комментарии не трогать(не разбивать), оставлять как есть.

[iprst]

Можно рассмотреть такую структуру — берём вопрос ведущего и ответ на него. Если общий размер превышает заданное значение, разбиваем ответ на необходимое количество частей, и перед каждой частью публикуем вопрос, то есть учитываем в будущих чанках длину вопроса.

У комментариев есть потолок по размеру. Я его превышал, но он очень высокий, сейчас не скажу какой. Можно найти в старых комментариях гигантские портянки, отправленные почти одновременно, это они.

[audetv]

Просмотрел пару десятков текстов вопросов ответов, для обновления информации. Причем разных годов, начиная с 2013.
Во всех просмотренных стенограммах отделены ведущий и Валерий Викторович. Т.е. тексты легко можно разбить на диалог и сохранить в структуре диалога. Но не всегда это вопрос ответ. Ведущий иногда произносит уточняющие реплики, или общий один вопрос разрывается подвопросом. Иногда это просьба прояснить, прокомментировать и во все это как бы не вопрос, а утверждение. Или вопрос ведущего и односложный ответ да\нет.

Из освоенных технологий на данный момент доступно разбиение на части диалога. Ведущий/Валерий Викторович, это сделаю. Нейросети пока оставим как будущее, пока у меня нет готового решения как это сделать на сервере, Т.е. не в каком то кабинете какой-то сети побаловаться, а так сказать промышленное для нас решение. Его пока нет у меня. Я не знаю, как разбить на реальные вопросы ответы нейросетью. Т.е. чтобы подвопросы и реплики соединились в один вопрос, разделы чанков. Но возможно это и не надою, поэтому:

Можно попробовать пока упростить задачу. Разбить на реплики диалога. Ведущий - Валерий Викторович, и если ответ Валерия Викторовича превышает оптимальный размер чанка, разбивать такой ответ на несколько частей-чанков, и далее можно попробовать реализовать отображение в поиске, как реплика ведущего и ответ Валерия Викторовича, в каждом чанке, реплика или вопрос ведущего для понимания контекста человеком.

И еще это осталось в умолчаниях, поэтому уточню. что чанки вопрос ответ будут в том же поиске ФКТ, никакого другого сайта/поддомена не планирую. Ищем по ФКТ, попадаем или на обычное обсуждения - комментарии, или на чанки вопроса ответа и все это в единой выдаче. Кажется, что это и не требует уточнения. но я уточнил)

[audetv]

У комментариев есть потолок по размеру. Я его превышал, но он очень высокий, сейчас не скажу какой. Можно найти в старых комментариях гигантские портянки, отправленные почти одновременно, это они.

Комментарии на ФКТ скорее всего ограничены размером текстового поля в БД mysql

TINYTEXT: представляет текст длиной до 255 байт.
TEXT: представляет текст длиной до 65 КБ.
MEDIUMTEXT: представляет текст длиной до 16 МБ
LONGTEXT: представляет текст длиной до 4 ГБ

Обычно, если не производить дополнительных действий это будет TEXT - 65535 байт (первый байт 0) как-то так
Именно байт а не символов, и если учесть, что символы кириллицы в utf-8 могут быть более 1 байта , то кол-во символов скорее всего менее 64 тысяч. Это по умолчанию. Что сделали на ФКТ не знаю и не проводил экспериментов с длиной комментария)

Подумал, что вообще мне большая длина комментария в выдаче поиска на СВОДД не мешает, отсутствие чанков для комментариев. Да. попадаются длинные тексты, но это уже привычно и удобно читать прямо из выдачи поисковой не переходя к вопросу и не совершая дополнительных действий. Возможно потому что таких комментариев не очень много. Но вопрос ответ точно будет выбиваться из общего правила и будет часто вылетать на первые позиции, чисто из-за длины ответа\выпуска, поэтому требуется разбить на чанки. Мы такое видели на поиске по сайтам кремля, не удобно было просматривать.

[iprst]

кол-во символов скорее всего менее 64 тысяч. Это по умолчанию. Что сделали на ФКТ не знаю и не проводил экспериментов с длиной комментария)

64 тысячи символов это похоже на правду. Одно могу сказать точно, текста длиной 16 мегабайт в форме комментария я точно не писал, так что это уже слишком высокий порог.

[iprst]

если ответ Валерия Викторовича превышает оптимальный размер чанка, разбивать такой ответ на несколько частей-чанков, и далее можно попробовать реализовать отображение в поиске, как реплика ведущего и ответ Валерия Викторовича, в каждом чанке, реплика или вопрос ведущего для понимания контекста человеком

Если я правильно понял, то такой сценарий и имел в виду, без ИИ.

Если ответ умещается в установленный предел:

Вопрос А
Ответ Б 

Если ответ больше установленного предела:

Вопрос А
Ответ Б-1

Вопрос А
Ответ Б-2

Вопрос А
Ответ Б-3

Возможно этот контекст и не нужен, но по опыту использования библиотеки контекст вообще используется регулярно, скажем каждый третий или четвёртый сценарий включает в себя рассмотрение контекста.

[audetv]

Да, вроде нормальная и понятная схема.
В случае если ответ больше установленного предела, подмешивать в каждый чанк вопрос. причем делать это надо прямо на уровне до записи в БД. Т.е. чанк реально будет всегда содержать вопрос ответ(часть ответа), это будет немного увеличивать размер БД, но для поиска так похоже будет лучше. Этот вопрос контекст всегда будет находиться внутри своих чанков, его можно разметить дополнительно, и в том случае когда будет освоена технология нейро сетей, чанки размечены и будут содержать и вопрос(контекст) и ответ/часть ответа.

Сначала была мысль в режиме реального времени при поисковом запросе подмешивать в выдачу к каждому чанку вопрос, но решил, что лучше записать сразу в БД таким образом, чтобы вопрос/реплика ведущего сразу хранились рядом с ответом, как одна запись в БД.

В таком случае может возникнуть некоторая сложность, если надо будет дополнительно провести действия чтобы обратно разложить стенограмму в вид один вопрос, склеенные чанки с одним вопросом. Но с другой стороны возможно, что это и не надо, т.к. оригинал стенограммы есть на сайте ФКТ, а на СВОДД реализован поиск и информация разбита с целью упрощения последующей ее обработки, для работы с информацией, а не для дублирования контента с сайта ФКТ. Ссылка на оригинал всегда будет в чанке.

[iprst]

Сначала была мысль в режиме реального времени при поисковом запросе подмешивать в выдачу к каждому чанку вопрос, но решил, что лучше записать сразу в БД таким образом, чтобы вопрос/реплика ведущего сразу хранились рядом с ответом, как одна запись в БД.

Когда будет ИИ, наверное всегда можно будет пересобрать базу из созданной или даже пройтись новым парсером, заточенным под этот ИИ. То что это двойная работа… ну, да, спору нет, но в то же время это нормальный эволюционный подход.