Поначалу я споткнулся на поиске объектов, так как команда objgraph.by_type('types.TracebackType') не находила вообще ничего. И это — несмотря на то, что я знал о том, что имеется огромное количество подобных объектов. Оказалось же, что в качестве имени типа надо использовать строку traceback. Причина этого мне не вполне ясна, однако что есть — то есть.
Пошел посмотреть что же там в файле types.py и знаете, лучше бы я этого не делал. Не думал, что от кода в стандартной библиотеке могут волосы на жопе начать шевелиться:
А по сути — by_type ищет по fully-qualified или сокращенному имени класса и обо всех его алиасах, определенных в других местах (типа types.py), функция не знает. Профиль кучи специально отображает fq имена в имена через types. Видимо для наглядности.
Проблема embedding в том, что при его использовании сложно контролировать расстояние между объектами.
Это очень похоже на DSSM. Подход строит такие эмбеддинги документов, у которых косинусное расстояние между указанными парами будет минимально.
В изначальной форумулировке DSSM используется для FTS и минимизирует расстояние между query и релевантными документами. Но вроде бы ваш датасет просто привести в такую форму. Берете в качестве query любой документ, а в качестве релевантных ему используете близкие к нему объекты. Получатся эмбеддинги, которые ваши исходные требования по близости будут учитывать.
Концептуально интересно. Из-за такого выбора функции расстояния у вас теперь немного связаны руки и приходится использовать vantage-point tree. Если использовать эмбеддинги в качестве промежуточного шага, то вся задача превращается в уже вдоль и поперек изъезженное поле. Например, все полученные вектора швыряются в faiss и с умопомрачительной скоростью (миллисекунды для миллионов документов) для данного вектора находятся соседи. Или вообще можно влезть в DSSM, если так хочется йоба-саенса и материала для новой статьи)
Почему выбран подход с именно такой попарной функцией расстояния на исходных объектах?
Я на пирахан не умею говорить, поэтому вряд ли могу содержательно ответить) Про флексивность ничего не знаю, но вот помню, что союзов в нем нет. По-крайней мере отсутствие союзов входит в понятие "язык без рекурсии", которым оказался пирахан.
У Ноама Хомского с данного факта сильно пригорело. Он как-то выдал, что рекурсивность чуть ли не единственный критерий, который отличает человеческие языки от животных коммуникаций.
Судя по их жизнеописанию, никак. У них всё ориентировано на чувственный опыт. Тактические действия мотивируются текущими потребностями, типа "проглодался — сходил поел", без привлечения лишних концепций в сознание. Дальше же у них нет никакого интереса. Вот случай, описанный Everett'ом:
I brought in a Brazilian canoe master, and spent days with them and him in the jungle; we selected the wood, and made a dugout canoe. The Pirahã did all the labor—so they knew how to make a canoe, and I gave them the tools—but they came to me and they said, we need you to buy us another canoe. I said, well we have the tools now, and you guys can make canoes. But they said, Pirahã don't make canoes. And that was the end of it. They never made a canoe like the Brazilians, even though I know that some of them have the skills to do that.
Абсолютно упоротая ситуация для большей части людей на земле, а им — норм. Пока делали каноэ, они были в состоянии умеющих-делать-конэ, а как закончили, так сразу забыли как инструменты в руках держать. Потому что в общем у них представление о себе, как о тех, кто делать каноэ не умеет.
Если вдруг дальше вопросы есть, то лучше обратиться к первоисточникам. Такие вещи легко переврать, пропуская через себя.
Обсуждать сабж не хочу, не очень люблю такие витиеватые статьи на Хабре. Но просто оставлю тут две, на мой взгляд, релевантные ссылки для автора и тех, кому все же будет интересно.
Возможна ли в математике, как в строгой, абстрактной, систематической, языковой структуре, концепция «системы времен»? И как бы она могла выражаться.
Если в обычном человеческом языке система времен складывалась практически сразу же — это, в сущности, и отличает язык от системы коммуникаций животных
Есть хороший пример того, что это не так. В лесах Амазонки живет любопытное племя Пираха, от которого все антропологи и лингвисты писают кипятком. А все потому, что у них в языке нет времени, ни как языковой сущности, ни как концепции. Такой язык на сознании членов племени оставляет большой отпечаток, в их мире не существует ни прошлого, ни будущего, а вместо смерти — сон.
Племя подробно изучал Dan Everett, ссылки есть на Вики. На русском тоже есть несколько переводов, рекомендую. То, как живут эти люди и смотрят на мир — прямо небольшой психоделический трип.
Да и без мистики аномалии могут быть. В декабре у студентов сессия, поэтому августовских львов так мало. Зато раков навалом, потому что ну кто же к сессии готовится заранее?
Вот автор развлекается со сплайнами, весело ему. А в итоге ещё одна рукопись Войнича получится, и через 200 лет люди будут мозги ломать и консилиумы собирать, пытаясь выяснить что же это такое.
ipfs мне представляется как р2р файлообменная сеть типа edonkey, gnutella, bittorrent вместе взятые без недостатков каждой отдельной файлообменной сети с наличием глобального поиска файлов и многофайловых раздач.
Увы, слишком идеалистичное представление.
IPFS — это только хранение файлов, поиск к IPFS не относится. Конкретно в случае LibGen метаданные для поиска живут в отдельно распространяемой БД, которая не связана с IPFS никак. Были попытки засунуть эту БД в OrbitDB, СУБД на основе IPFS. Чем всё закончилось я не знаю. Соответственно и поиск по этим метаданным — ответственность зеркал или тех, кто разворачивает дампы меты у себя. Импорт дампов и разворачивание зеркал пока является работой с открытой концовкой, никаких quickstart здесь нет. Разве что могу подсказать, что сами ссылки на дампы есть на archiveteam.
Про русский язык замечание принимаю, правда обещать пока ничего не буду. Я сейчас попробовал зайти на https://freeread.org/ipfs/ в Chrome, щелкнуть правой кнопкой на тексте и перевести всю страницу на русский язык. Получилось сносно, хотя достоверно оценить не могу, глаза у меня уже замылены наглухо всеми этими инструкциями.
Я вас понял. Наверняка можно решить задачу и сравниванием растров, это правда. Сказать какой метод будет точнее я не могу, у меня не было такого опыта. Но я бы все равно решал эту задачу через распознание текста и его последующее сравнение. Потому что в растре тоже может быть много мешающего шума, если говорить о дублях, которые появились из-за сканирования разными людьми на разном оборудовании разных копий книги. Извлечение текста этот шум уберет.
Надежда на то, что где-то (может быть в LibGen) хоть как-то будет организовано.
Попробуйте Google Scholar. Находите что-нибудь, а потом на странице поисковой выдачи под строкой с найденным жмете Cited by X…
Так же работает ResearchGate.
Мне казалось, что первичен скан. <...>
Файлы могут получаться абсолютно разными, а вот текстовый слой будет почти одинаковым. Странно было бы, если бы текст сильно различался. На всякий случай, текстовый слой — это собственно само текстовое содержание PDFки, с откинутым форматированием и без графики.
— Есть-ли какие-либо соображения и оценки возможности организации на СЕРВЕРАХ индексов мета-данных уровня ссылки/библиография?
Для книг готового ссылочного графа я не знаю. Для научных статей существует инициатива открытого цитирования в партнерстве с CrossRef. API CrossRef умеет отдавать ссылки статей друг на друга в рамках этой инициативы. Поэтому принципиальная возможность самостоятельно построить индексы по ссылкам есть.
— Возможно-ли исключение дубликатов содержания (например — шкурки DJVU/PDF к отсканированным оригиналам)?
Возможно всё, вопрос усилий. Дубликаты хорошо отсеиваются и по метаданным, по-крайней мере в случае LibGen.
Для исключения дубликатов по содержанию нужно уметь извлекать текстовый слой из файла. Для PDF с распознаными символами есть утилиты типа PDFBox/grobid. Для нераспознанных сканов необходимо сначала запускать OCR. Что есть для djvu — не знаю, но точно что-то есть.
Мне известны библиотеки, которые проделывали такую работу и заодно выделяли ключевую лексику из текстов, а потом успешно искали дубликаты по пересечению ключевиков. Есть ещё алгоритм шинглов, описанныйiseg для Яндекса — это если предположить, что качество текстового слоя хромает и четкого дубликата не будет из-за ошибок распознавания.
Еще учась в институте и познакомившись с админом тамошнего студенческого форума, где у нас в том числе был свой файловый архив с отсканенными учебниками, билетами и т.д. я прям загорелся идеей свободной литературы.
Тем интереснее вам будет наблюдать за звеньями одной цепи. Из этих файловых архивов российских университетов появились свободные библиотеки, которые, спустя десятилетия тихой работы множества людей, начали менять научный ландшафт в мире. Европа уже планирует перекрыть кислород безумию платного доступа. И у истоков инициативы европейских академий стоят те люди, которые во времена своей учебы узнали о Sci-Hub и LibGen, и совершенно точно пользовались ими. Вот так идея оказалась сильнее плохих традиций и перешагнула границы и время.
Вот прям ровно наоборот все: в IPFS лежат файлы, в зеркале же хранятся хеши файлов. Пользователь находит в зеркале хеш нужного файла, идет с хешом в IPFS и получает себе сам файл.
Суть в том, что метаданные и хеши занимают маленькие объемы диска и каждый может быстро поднять базу с этой информацией, поэтому на одно прикрытое зеркало появится 10 новых. Без IPFS зеркала вынуждены самостоятельно таскать за собой все 100TB книг и статей вместо их хешей. Мало кто из энтузиастов может себе позволить содержать такие объемы дисков и обеспечивать соответствующий трафик, поэтому и зеркал существует не очень много. IPFS должен помочь изменить эту ситуацию. Кроме того, содержать только метаданные немного безопаснее, чем содержать ещё и файлы.
Так под весь объем и не надо поднимать. В IPFS можно запинить столько файлов, сколько позволит диск и это все равно будет существенным вкладом. Более того, система из 10 человек, раздающих по 1GB, будет в целом устойчивее, чем 1 человек, раздающий все 10GB.
Ориентировочные размеры такие:
LibGen — 40TB, мета от 500MB до 10GB без индексов. Размер меты зависит от алгоритма сжатия и от того, как считать — в jsonах, инсертах в файле SQL дампа или в бинарном виде без схемы. Необходимые индексы в БД тоже сколько-то места занимают, от 50% до 200% размера БД.
Sci-Hub — 70TB, мета от 10 до 50GB. У БД Sci-Hub'a метаданных больше на порядок, так как в ней 87 миллионов записей против 2.7 миллионов LibGen'а.
Сами pdfки неплохо жмутся, 15%-20% размера можно срезать, если, например, включить сжатие zlibом на файловой системе.
Вдобавок к написанному, сложность настройки/использования нельзя недооценивать. Несовершенная технология с простым, удобным интерфейсом, качественной документацией и хорошим коммьюнити выживет с большим шансом, чем теоретически вылизанная технология без поддержки сообщества и с интерфейсом в виде перекомпиляции всей библиотеки (я утрирую, но тем не менее).
Пошел посмотреть что же там в файле types.py и знаете, лучше бы я этого не делал. Не думал, что от кода в стандартной библиотеке могут волосы на жопе начать шевелиться:
А по сути — by_type ищет по fully-qualified или сокращенному имени класса и обо всех его алиасах, определенных в других местах (типа types.py), функция не знает. Профиль кучи специально отображает fq имена в имена через types. Видимо для наглядности.
inb4 поговорил с переводом, традиции Хабра
Это очень похоже на DSSM. Подход строит такие эмбеддинги документов, у которых косинусное расстояние между указанными парами будет минимально.
В изначальной форумулировке DSSM используется для FTS и минимизирует расстояние между query и релевантными документами. Но вроде бы ваш датасет просто привести в такую форму. Берете в качестве query любой документ, а в качестве релевантных ему используете близкие к нему объекты. Получатся эмбеддинги, которые ваши исходные требования по близости будут учитывать.
Концептуально интересно. Из-за такого выбора функции расстояния у вас теперь немного связаны руки и приходится использовать vantage-point tree. Если использовать эмбеддинги в качестве промежуточного шага, то вся задача превращается в уже вдоль и поперек изъезженное поле. Например, все полученные вектора швыряются в faiss и с умопомрачительной скоростью (миллисекунды для миллионов документов) для данного вектора находятся соседи. Или вообще можно влезть в DSSM, если так хочется йоба-саенса и материала для новой статьи)
Почему выбран подход с именно такой попарной функцией расстояния на исходных объектах?
Вы цитируете Бурбаки, но вы делаете это без уважения...
Я на пирахан не умею говорить, поэтому вряд ли могу содержательно ответить) Про флексивность ничего не знаю, но вот помню, что союзов в нем нет. По-крайней мере отсутствие союзов входит в понятие "язык без рекурсии", которым оказался пирахан.
У Ноама Хомского с данного факта сильно пригорело. Он как-то выдал, что рекурсивность чуть ли не единственный критерий, который отличает человеческие языки от животных коммуникаций.
На их языке все три варианта должны звучать одинаково.
Судя по их жизнеописанию, никак. У них всё ориентировано на чувственный опыт. Тактические действия мотивируются текущими потребностями, типа "проглодался — сходил поел", без привлечения лишних концепций в сознание. Дальше же у них нет никакого интереса. Вот случай, описанный Everett'ом:
Абсолютно упоротая ситуация для большей части людей на земле, а им — норм. Пока делали каноэ, они были в состоянии умеющих-делать-конэ, а как закончили, так сразу забыли как инструменты в руках держать. Потому что в общем у них представление о себе, как о тех, кто делать каноэ не умеет.
Если вдруг дальше вопросы есть, то лучше обратиться к первоисточникам. Такие вещи легко переврать, пропуская через себя.
Обсуждать сабж не хочу, не очень люблю такие витиеватые статьи на Хабре. Но просто оставлю тут две, на мой взгляд, релевантные ссылки для автора и тех, кому все же будет интересно.
https://en.wikipedia.org/wiki/Temporal_logic
Есть хороший пример того, что это не так. В лесах Амазонки живет любопытное племя Пираха, от которого все антропологи и лингвисты писают кипятком. А все потому, что у них в языке нет времени, ни как языковой сущности, ни как концепции. Такой язык на сознании членов племени оставляет большой отпечаток, в их мире не существует ни прошлого, ни будущего, а вместо смерти — сон.
Племя подробно изучал Dan Everett, ссылки есть на Вики. На русском тоже есть несколько переводов, рекомендую. То, как живут эти люди и смотрят на мир — прямо небольшой психоделический трип.
Да и без мистики аномалии могут быть. В декабре у студентов сессия, поэтому августовских львов так мало. Зато раков навалом, потому что ну кто же к сессии готовится заранее?
Вот автор развлекается со сплайнами, весело ему. А в итоге ещё одна рукопись Войнича получится, и через 200 лет люди будут мозги ломать и консилиумы собирать, пытаясь выяснить что же это такое.
Увы, слишком идеалистичное представление.
IPFS — это только хранение файлов, поиск к IPFS не относится. Конкретно в случае LibGen метаданные для поиска живут в отдельно распространяемой БД, которая не связана с IPFS никак. Были попытки засунуть эту БД в OrbitDB, СУБД на основе IPFS. Чем всё закончилось я не знаю. Соответственно и поиск по этим метаданным — ответственность зеркал или тех, кто разворачивает дампы меты у себя. Импорт дампов и разворачивание зеркал пока является работой с открытой концовкой, никаких quickstart здесь нет. Разве что могу подсказать, что сами ссылки на дампы есть на archiveteam.
Про русский язык замечание принимаю, правда обещать пока ничего не буду. Я сейчас попробовал зайти на https://freeread.org/ipfs/ в Chrome, щелкнуть правой кнопкой на тексте и перевести всю страницу на русский язык. Получилось сносно, хотя достоверно оценить не могу, глаза у меня уже замылены наглухо всеми этими инструкциями.
Я вас понял. Наверняка можно решить задачу и сравниванием растров, это правда. Сказать какой метод будет точнее я не могу, у меня не было такого опыта. Но я бы все равно решал эту задачу через распознание текста и его последующее сравнение. Потому что в растре тоже может быть много мешающего шума, если говорить о дублях, которые появились из-за сканирования разными людьми на разном оборудовании разных копий книги. Извлечение текста этот шум уберет.
Попробуйте Google Scholar. Находите что-нибудь, а потом на странице поисковой выдачи под строкой с найденным жмете Cited by X…
Так же работает ResearchGate.
Файлы могут получаться абсолютно разными, а вот текстовый слой будет почти одинаковым. Странно было бы, если бы текст сильно различался. На всякий случай, текстовый слой — это собственно само текстовое содержание PDFки, с откинутым форматированием и без графики.
Для книг готового ссылочного графа я не знаю. Для научных статей существует инициатива открытого цитирования в партнерстве с CrossRef. API CrossRef умеет отдавать ссылки статей друг на друга в рамках этой инициативы. Поэтому принципиальная возможность самостоятельно построить индексы по ссылкам есть.
Возможно всё, вопрос усилий. Дубликаты хорошо отсеиваются и по метаданным, по-крайней мере в случае LibGen.
Для исключения дубликатов по содержанию нужно уметь извлекать текстовый слой из файла. Для PDF с распознаными символами есть утилиты типа PDFBox/grobid. Для нераспознанных сканов необходимо сначала запускать OCR. Что есть для djvu — не знаю, но точно что-то есть.
Мне известны библиотеки, которые проделывали такую работу и заодно выделяли ключевую лексику из текстов, а потом успешно искали дубликаты по пересечению ключевиков. Есть ещё алгоритм шинглов, описанный iseg для Яндекса — это если предположить, что качество текстового слоя хромает и четкого дубликата не будет из-за ошибок распознавания.
Тем интереснее вам будет наблюдать за звеньями одной цепи. Из этих файловых архивов российских университетов появились свободные библиотеки, которые, спустя десятилетия тихой работы множества людей, начали менять научный ландшафт в мире. Европа уже планирует перекрыть кислород безумию платного доступа. И у истоков инициативы европейских академий стоят те люди, которые во времена своей учебы узнали о Sci-Hub и LibGen, и совершенно точно пользовались ими. Вот так идея оказалась сильнее плохих традиций и перешагнула границы и время.
Вот прям ровно наоборот все: в IPFS лежат файлы, в зеркале же хранятся хеши файлов. Пользователь находит в зеркале хеш нужного файла, идет с хешом в IPFS и получает себе сам файл.
Суть в том, что метаданные и хеши занимают маленькие объемы диска и каждый может быстро поднять базу с этой информацией, поэтому на одно прикрытое зеркало появится 10 новых. Без IPFS зеркала вынуждены самостоятельно таскать за собой все 100TB книг и статей вместо их хешей. Мало кто из энтузиастов может себе позволить содержать такие объемы дисков и обеспечивать соответствующий трафик, поэтому и зеркал существует не очень много. IPFS должен помочь изменить эту ситуацию. Кроме того, содержать только метаданные немного безопаснее, чем содержать ещё и файлы.
Почитать можно достаточно хорошую документацию и whitepaper
Да, сохраняет.
Так под весь объем и не надо поднимать. В IPFS можно запинить столько файлов, сколько позволит диск и это все равно будет существенным вкладом. Более того, система из 10 человек, раздающих по 1GB, будет в целом устойчивее, чем 1 человек, раздающий все 10GB.
Ориентировочные размеры такие:
LibGen — 40TB, мета от 500MB до 10GB без индексов. Размер меты зависит от алгоритма сжатия и от того, как считать — в jsonах, инсертах в файле SQL дампа или в бинарном виде без схемы. Необходимые индексы в БД тоже сколько-то места занимают, от 50% до 200% размера БД.
Sci-Hub — 70TB, мета от 10 до 50GB. У БД Sci-Hub'a метаданных больше на порядок, так как в ней 87 миллионов записей против 2.7 миллионов LibGen'а.
Сами pdfки неплохо жмутся, 15%-20% размера можно срезать, если, например, включить сжатие zlibом на файловой системе.
Вдобавок к написанному, сложность настройки/использования нельзя недооценивать. Несовершенная технология с простым, удобным интерфейсом, качественной документацией и хорошим коммьюнити выживет с большим шансом, чем теоретически вылизанная технология без поддержки сообщества и с интерфейсом в виде перекомпиляции всей библиотеки (я утрирую, но тем не менее).