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

Главных примеров всего будет три: из биологии, из статистики и из архитектуры компьютеров. Вот такой вот забавный набор получился. Хоть примеры и будут специфическими, но при этом они останутся доступными широкому кругу людей. Сами же ментальные приёмы будут размазаны непосредственно по примерам из озвученных областей.

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

Эта статья завершает цикл "Управление знаниями в Obsidian". В ней будет предполагаться, что вы способны понять все техники и приемы из прошлой второй части про базовый рабочий процесс, т.к. здесь будут показаны продвинутые способы управления персональной базой знаний. В частности, статья затронет следующие темы:

• Ведение визуальной базы знаний (Excalidraw + Excalibrain)

• Создание системы для интервального повторения (Spaced repetition)

• Создание гибкой иерархии (Breadcrumbs + Excalibrain)

• Использование алгоритмов для поиска новых связей между заметками (Graph Analysis)

• Написание длинных текстов (Longform)

В этой статье будет показано как можно начать организовывать свою базу знаний в Obsidian, отталкиваясь от источников. В статье будет разобрано то, какие стоит использовать папки и теги; как создать свою первую точку входа в систему. Также будет уделено внимание способу ведения журнала (дневника). Статья будет предполагать, что вы не против автоматизации процессов в своей базе знаний, поэтому все источники будут шаблонизированы и впоследствии собраны в свои отдельные библиотеки с помощью Dataview. Завершится статья подробным примером (алгоритмом) рабочего процесса.

Этот текст открывает цикл статей по рассмотрению проблемы управления знаниями в Obsidian. Эта часть почти не будет содержать практических советов о работе с заметками конкретно в Obsidian. Однако в ней будут раскрыты несколько более важные проблемы обработки различных источников информации. Несмотря на последовательное перетекание статьи из одной главы в другую, вы можете попробовать каждый пункт рассматривать как идею, как хак или как возможность внедрить в свою жизнь и рабочий процесс что-то новое.

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

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

• что такое модели NLU и как они применяются в компьютерной лингвистике;
• что такое векторы предложений и как их получить;
• как обучить векторизатор предложений [NLU] на базе архитектуры BERT;
• как можно использовать обученные модели NLU

• У меня в Психотронке можно следить за подготовкой обновленной версии, ну и написать мне за помощью. А можете не следить: версия 2.0 выйдет на Хабре.
• В русскоязычном сообществе Zettelkasten в Телеграме сидят люди, которые хорошо разбираются в теме. Мы обожаем помогать новичкам.

Эта статья появилась по нескольким причинам.

Во-первых, в подавляющем большинстве книг, интернет-ресурсов и уроков по Data Science нюансы, изъяны разных типов нормализации данных и их причины либо не рассматриваются вообще, либо упоминаются лишь мельком и без раскрытия сути.

Во-вторых, имеет место «слепое» использование, например, стандартизации для наборов с большим количеством признаков — “чтобы для всех одинаково”. Особенно у новичков (сам был таким же). На первый взгляд ничего страшного. Но при детальном рассмотрении может выясниться, что какие-то признаки были неосознанно поставлены в привилегированное положение и стали влиять на результат значительно сильнее, чем должны.

И, в-третьих, мне всегда хотелось получить универсальный метод учитывающий проблемные места.

В рекомендательных системах нет доминирующего класса моделей. Матричные разложения, графовые  и контентные рекомендеры активно развиваются: про них пишут научные статьи, их используют в продакшене. Пять лет назад на волне интереса к нейронным сетям стали популярны нейросетевые рекомендеры, но довольно быстро наступило разочарование. На RecSys 2019 лучшей выбрали статью с критикой нейросетевого подхода (в этом году его тоже пинают). Стоит ли практикам забыть о нейронных сетях в рекомендациях? Я уверен, что нет. Мой рекомендер уже год работает в продакшене и помогает пользователям Одноклассников заказывать интересные товары. Я расскажу, почему построил рекомендер на основе нейронной сети. После прочтения статьи у вас не останется причин не сделать также в вашем сервисе.

Дисклеймер:

Введение

Обо мне

Всем привет, я обычный учащийся по специальности "техник-программист". С детства увлекаюсь компьютерами, с класса 7-го начал познавать само программирование. Являюсь владельцем подписки на Яндексу Музыку уже больше года и в целом доволен сервисом (правда сейчас в плейлисте дня сплошные повторы).

Предыстория

Уж не помню точно, из-за чего я решил поискать официальную документацию API данного сервиса, вроде бота хотел для Telegram написать, но столкнулся с тем, что её нет… Спустя некоторое время наткнулся на issue в репозитории yandex/audio-js. Там ребятки задают точно такой же вопрос, как и я: "А где API?". Не многие горят желанием слушать музыку через браузер, они хотят приложение, но приложения под Linux тоже нет! Интегрировать к своему любимому плееру невозможно!

Тут я загорелся идеей сделать это. Естественно, мне нужно как-то работать с сервисом, городить костыли вокруг веб-приложения не вариант. Я понимал, что имея такой сервис, имея мобильные приложения и приложения под Windows (из Microsoft Store) просто невозможно не иметь своё внутреннее API для взаимодействия. Я оказался прав!

Обязательно к прочтению перед основной частью

Я отдаю себе отчёт в том, что, изучая их непубличное API я роюсь в чужих грязных вещах. Ниже будут описаны различные спорные моменты, решения разработчиков и в целом то, как это написали, как они этим пользуются. Местами я был просто шокирован, но я уверен, что если они так сделали, то на это были свои причины! Не будем забывать, что это никто не должен был видеть. Так же хочу сказать, что всё написанное ниже моё мнение. Вы можете с ним согласить или нет.

Понимание роли мозга