С 2021 года я учусь в аспирантуре по экономической географии. Чтобы защитить кандидатскую диссертацию, надо опубликовать хотя бы две качественные научные статьи, а лучше — больше. Желательно также поучаствовать в нескольких конференциях. Первые пару лет дело шло медленно, так что к концу 2023 года я понял: либо в турборежиме всё успеваю, либо смысла в аспирантуре дальше нет. На тот момент моё портфолио выглядело пустовато: два выступления на конференциях, ноль научных статей по географии. Сейчас ситуация совершенно иная: восемь конференций, шесть статей. На всё ушёл год с небольшим. Рассказываю, как мне это удалось.
Дисклеймеры, или Чудес не бывает
Призна́юсь: заголовок не лишён «желтизны». Во-первых, всё же не за год, а за год и четыре месяца. Во-вторых, первые два года в аспирантуре я не бездельничал, а искал данные и писал код, которые мне потом сильно помогли (об этом дальше). В-третьих, «маленькая статья» — это и правда короткий, страниц на пять, текст по мотивам доклада на конференции. В-четвёртых, «большая статья» — это всё же не 30 страниц, а скорее 10–15, из них часть — графики, карты и таблицы. В-пятых, на конференциях я выступал исключительно в онлайне. Тем не менее, это полноценные статьи в достаточно качественных рецензируемых изданиях (не мусорных, не хищнических, не за деньги) и реальные конференции (не заочные сборники), где я рассказывал о своём исследовании и отвечал на вопросы (порой заковыристые).
Научные статьи по экономической географии отличаются от научных статей по математике и компьютерным наукам: в них меньше формул и вычислительных экспериментов, больше карт и описаний. Конференции географов не похожи на конференции айтишников: меньше модной практики и хай-тека, больше выдержанной в дубовых бочках теории и родных просторов (порой и таких, которые «нигде не заканчиваются»). Отличается и технический уровень участников: среди эконом-географов, по моим впечатлениям, программирует меньшинство. Не факт, что мой рассказ пригодится тем, кто верстает на Латехе и коммитит каждый час. Однако тем, кто пишет в Ворде, считает в Экселе и готовит слайды в Гугль-доке, возможно, будет интересно.
Я не использовал чатГПТ, Perplexity, Гигачат и подобные им продукты. Вообще. Не знаю, было бы с ними проще или нет. С недавних пор пытаюсь их применить в исследовательской работе и программировании — первые впечатления противоречивые. Может быть, потом расскажу подробнее, но пока советов вида: «Достаточно использовать простой китайский ДипСик» не будет. Если за вас уже пишут ИИ-агенты, то, наверное, эта статья покажется рассказом деревенщины из российской глубинки. Впрочем, если редакторы качественных журналов возвращают написанное ИИ-агентами с вердиктом «отклонить», то, быть может, мой текст вам всё же будет небесполезен.
Наконец, чтобы написать много статей, нужно в первую очередь много сидеть и писать — порой даже когда нет настроения, лень или не клеится. Нужно говорить себе (и другим) «нет» на отвлекающие манёвры и не надеяться на «завтра сделаю». Относительная продуктивность тоже важна, но без запаса времени она не работает. Мне, в частности, помог переход на четырёхдневку с потерей части зарплаты: когда понимаешь, что за свободное время буквально платишь, мотивация возрастает. Искатели магии, позволяющей за неделю «на расслабоне» пробиться в Nature, скорее всего, будут разочарованы моими рекомендациями.
Итак, эта статья — не универсальное руководство, не волшебная пилюля, не мотивационный гайд о продуктивности, а рассказ о тех инструментах и приёмах, которые помогли мне. Может быть, они пригодятся ещё кому-то. В особенности я рассчитываю, что моя история будет полезна тем, кто хочет поднять технический уровень своей исследовательской деятельности, но пока не уверен, надо ли ему это, и не слишком хорошо понимает, что именно и как можно сделать. Также возможно, что отдельные инструменты заинтересуют и более продвинутую аудиторию.
Данные как фундамент, или Прославляем data-driven approach
Все мои статьи и доклады на конференциях построены на базе одного набора данных — геокодированной таблицы с информацией о юридических фирмах в России. На его подготовку я потратил ещё полгода вдобавок к году, который ушёл на статьи, но дело того стоило: генератор данных — это полноценное консольное приложение на Python. Возможно, оно заслуживает отдельной статьи — подумаю, написать или нет. Если кратко, то программа скачивает несколько наборов открытых данных с сайта Федеральной налоговой службы, извлекает из них всё ценное, убирает лишнее, геокодирует адреса и сводит всю информацию в удобную таблицу. Без такой подготовки открытые данные — это 200 Гб архивов из xml-файлов, использовать которые для прикладного анализа, мягко говоря, неудобно. Может быть, полгода на получение данных и стоило бы включить во время работы над статьёй, но я так не делаю, поскольку мне кажется, что я слишком уж много усилий потратил на то, чтобы реализовать процесс подготовки данных именно в виде приложения, а не в виде набора разовых скриптов. Кроме того, не всегда с данными всё будет так сложно — иногда их можно просто скачать или недорого купить.
На мой взгляд, данные — это и необходимость, и отличная возможность для многих областей современной науки. О data-driven approach, исследованиях на данных, говорят уже довольно давно и много. Несмотря на это, по моим впечатлениям, занимается ими сравнительно небольшой слой специалистов. Среди эконом-географов многим по-прежнему хватает Росстата. Конечно, официальная статистика — это тоже данные, но со своими нюансами: с пробелами, искажениями, агрегированные, не всегда даже оцифрованные, не говоря об отсутствии машиночитаемости. Соответственно, подход к работе с такой информацией в основном «ламповый»: сидеть и вручную изучать отчёты, графики и таблицы. Впрочем, есть и такие географы, которые берутся за альтернативные источники: спутниковые снимки, сведения мобильных операторов, административные данные (включая открытые данные ФНС, которыми воспользовался я), OpenStreetMap, соцсети и подобные.
Исследования на данных обычно выглядят гораздо более айтишно: здесь и ETL-цепочки, и прикладная статистика, а порой и машинное обучение. Понятно, что технологии и данные сами по себе не повышают академический уровень работы, но они способствуют этому: нестандартные данные позволяют выдвинуть нестандартные гипотезы, а продвинутые методы их анализа — более строго их проверить, более убедительно подтвердить или опровергнуть. Кроме того, айтишный компонент в научных статьях там, где подобное пока не стало нормой, вызывает повышенный интерес и редакторов, и рецензентов, и читателей. Статья может быть не слишком новаторской по предмету исследования, но выделяться данными и методами.
Основная практическая трудность исследований на данных — это доступ к ним. Удобнее всего, когда нужные сведения выложены в форме открытых данных: бесплатно в интернете, без регистрации и лицензионных ограничений, в машиночитаемом виде (csv-таблица, parquet и другие варианты), с документацией, метаданными, версиями. К сожалению, такое бывает далеко не всегда: иногда данные есть в интернете, но в неудобном виде, иногда они есть, но хитро спрятаны, иногда их нужно выковыривать из недокументированного АПИ, иногда требуется зарегистрироваться, иногда — заплатить, иногда — написать запрос, на который иногда не ответят или откажут, а иногда данных нет, не было, и никто не знает, есть ли они, были ли и будут ли. В России, к сожалению, де-факто идёт курс на закрытость, поэтому даже те данные, которые раньше были доступны, нередко пропадают, а ситуация в тех местах, где всё было плохо, не улучшается. ФНС России — это скорее редкое исключение, но и то не обошлось без причуд: в какой-то момент пропали версии за прошедшие годы. Повезло, что к тому времени я уже всё скачал.
Поиск данных для исследований, как по мне, ближе к искусству, чем к технологии, особенно если речь идёт о России. Обычно приходится долго гуглить (вариант — спрашивать чат-ботов), искать похожие исследования, смотреть профильные сайты или каналы, спрашивать коллег. Часто так бывает, что о потенциально интересном датасете узнаёшь почти случайно: новость где-то бегло видишь или замечаешь ссылку в чужой работе. Мне также помогает относительно неплохой кругозор в сфере юриспруденции и гостеха: несмотря ни на что, государственные информационные системы продолжают строиться, и нередко на их сайтах публикуются какие-то данные (или АПИ не слишком хорошо защищены, так что из них можно выцепить интересующие сведения). Из специализированных ресурсов мне нравится дата-каталог социального некоммерческого проекта «Если быть точным». Раньше весьма перспективной была «Инфраструктура научно-исследовательских данных», но сейчас она уже несколько лет как в подвешенном состоянии и почти не обновляется. Интересные ссылки порой появляются в телеграм-канале Ивана Бегтина. В плане геоданных пользовался GADM и geoBoundaries: эти два сайта помогли мне с административными границами.
Заранее подготовленные данные сильно помогли мне: можно сказать, что все статьи и доклады — это проверка разных гипотез на одном наборе данных или описание этих данных в разных разрезах. Я смотрел на поля таблицы и думал, какие вопросы я могу к этим данным задать, какие ответы ожидаю получить, и почему именно их. Не исключено, что статьи можно было бы объединить в один длиннющий аналитический отчёт, но поскольку в науке котируются именно самостоятельные публикации, то вышло много отдельных текстов. У каждого свои предмет, методы и результаты, но тематика исследований объединяет их концептуально, а набор данных — практически.
Итак, совет простой: идите от данных. Найдите или соберите большой, качественный и разнообразный датасет по интересующей вас проблемной области и изучите его в разных аспектах. Набор данных при таком подходе становится ядром исследования: сначала вы думаете, какие данные нужны и как их достать, а потом задаёте к добытым данным вопросы, применяете методы, получаете результаты и обсуждаете их.
Всё есть код, или Пишем статью как компьютерную программу
Я выбрал себе такой стек для написания статей: R для статистики, карт и визуализации, RMarkdown для текста, RStudio для разработки, git+GitHub для истории версий. Наверное, слово «стек» смотрится непривычно в контексте академических публикаций. Это для технарей Латех стал стандартом, а многие географы (и не только) по-прежнему пишут в Ворде или Гугль-доке. Однако в контексте исследований, основанных на данных, весьма привлекательно смотрится literate programming — совмещение кода и текста в одном флаконе. Придумали этот термин довольно давно. Для айтишников и аналитиков, пожалуй, наиболее известный его пример — это тетрадки (notebooks) в Jupyter, Google Colab, Kaggle и аналогичных продуктах. Научную статью тетрадкой пока не опубликуешь, но сгенерировать её из кода и текста вполне возможно. Дальше кратко напишу о каждом элементе стека и его субъективных преимуществах.
Язык программирования R немного причудлив и не слишком известнен в массах. Тем не менее, в науках о данных он, пожалуй, стоит наравне с Python. Особенно велика его роль в «классической» статистике и специализированных академических приложениях. В своё время экологи (это было за несколько лет до географии) мне его позиционировали как крутую бесплатную замену мощным статистическим пакетам. Отчасти это верно, поскольку в языке чувствуется фокус на статистике, обработке данных, вычислениях: грубо говоря, то, что на Python делают pandas, matplotlib и statsmodels, в R работает «из коробки». Впрочем, в остальном это полнофункциональный язык программирования с ООП и функциями первого класса, пригодный для разных задач вплоть до разработки веб-приложений. Я его использовал в «методической» части статей: брал датасет, загружал его, предобрабатывал, делал статистические тесты, считал описательные статистики, строил простые линейные модели, создавал графики и карты. Если влезать в технические детали, то в основном полагался на пакеты группы tidyverse, для геоданных использовал sf, а в конце подключил renv для создания максимально воспроизводимых окружений.
RMarkdown — это гибрид R и языка разметки Markdown. Его основная идея в том, что ты пишешь текст, вставляешь туда куски кода на R, потом нажимаешь одну кнопку — и получаешь готовую статью в doc, pdf, html, odt или каком-то другом формате. Штука эта нетривиальная с технической точки зрения, но использовать её сравнительно легко, если знать R и Markdown. Об R я уже написал; Markdown же относительно прост: на практике чаще всего хватает десятка правил вида «чтобы выделить текст жирным, надо написать вот так: **это выделено жирным**». Для более сложных случаев в интернете есть много кратких и подробных инструкций. По сути, статья на RMarkdown — это компьютерная программа. Её «исходный код» — это собственно текст статьи и фрагменты кода на R. Результат работы программы — это статья в более традиционном формате, то есть документ Word, ODT или pdf-файл. Помимо RMarkdown, есть похожий на него более новый продукт под названием Quarto от той же компании-разработчика. В нём поддерживается больше языков программирования: если RMarkdown понимает только R, то Quarto позволяет писать, например, на Python. Есть и другие отличия и полезные функции. Я попробовал Quarto для презентаций к некоторым конференциям — понравилось, но в плане статей нашёл не так уж много существенных плюсов и пока остался на более привычном и знакомом RMarkdown.
Git и GitHub — средство версионирования и одна из платформ, основанных на нём. Технически статья, написанная на RMarkdown — это простой текстовый файл. Такие файлы идеально подходят для git: можно создать репозиторий для статьи и отправлять промежуточные версии на Гитхаб. Плюсы — осмысленная история изменений, резервное копирование и возможность легко поделиться исходным кодом статьи. Хотя git — не самый простой инструмент, на практике обычно хватает нескольких типовых команд. Как и в случае с Markdown, в интернете много более или менее понятных инструкций. С точки зрения современных подходов к научным публикациям Гитхаб очень удобен для открытости и воспроизводимости: если вставить в текст статьи ссылку на репозиторий с исходным кодом, то любой технически подкованный читатель сможет изучить его в деталях и при необходимости повторить исследование. Словесное описание методов тоже упрощается: достаточно объяснить их «по верхам» и отправить на Гитхаб за тонкостями реализации. Конечно, есть риск, что редактор, рецензент или читатель найдёт баг в коде, из-за которого все научные открытия превратятся в досадное недоразумение, но такого со мной пока, к счастью, не случалось. Ещё на Гитхабе можно организовать совместную работу над текстом, но так я тоже не пробовал.
RStudio — это среда разработки. Можно сказать, редактор кода на максималках. В RStudio мне довольно удобно писать код на R и тексты на RMarkdown, отлаживать их, собирать статьи из исходного кода, устанавливать дополнительные компоненты (пакеты), читать документацию, просматривать графики. Из того, что может заинтересовать начинающих — там есть визуальный редактор, который снижает порог входа: статью можно писать почти как в условном Ворде. Кроме того, и git c Гитхабом там поддерживаются в графическом интерфейсе — можно до поры до времени не учить команды. Наверное, это самая субъективная часть стека: существуют и другие среды разработки, в том числе более популярные, а кто-то, наоборот, не любит RStudio за чрезмерную перегруженность и предпочитает консоль или простые текстовые редакторы, но так уж повелось с момента первых моих курсов по R, что я привык именно к ней.
Отмечу два преимущества RMarkdown, особенно ценные для научных публикаций: шаблоны для сборки статей и библиография в bibtex. «Головная боль» исследователя — это оформление статей по требованиям журнала, включая ссылки и списки литературы. Шаблоны упрощают оформление: один раз задаёшь поля, шрифт, кегль, абзацные отступы, выравнивание, стиль подписей к картинкам и таблицам — статья после сборки «упаковывается» в шаблон и сразу выглядит так, как нужно (ну, почти). Понадобилось что-то поправить — правишь шаблон, пересобираешь статью. Ссылки и список литературы работают так: собираешь все источники в текстовый файл в формате bibtex, расставляешь по тексту ссылки вид @einstein1905, подключаешь специальный стилевой файл (csl-файл), указываешь в тексте место для списка литературы — после сборки статьи получаешь текст со ссылками и библиографией в нужном стиле (ну, почти). Выглядит как магия, спасает от кучи нудной ручной работы. Для списка источников в bibtex я использовал Zotero, zbib и кнопки для экспорта в bibtex на сайтах журналов. Стилевые файлы можно найти, например, по инструкциям и ссылкам на citationstyles — там есть и готовые для известных журналов, и даже пресловутый ГОСТ (к сожалению, поддержка неполная и местами кривоватая). От мелких правочек, увы, такая автоматизация все равно не избавляет, да и с дублированными англоязычными References для российских журналов приходится возиться отдельно: готовой поддержки двух списков литературы ни в RMarkdown, ни в его более продвинутом аналоге Quarto нет. Но как по мне, всё же проще и быстрее, чем руками делать.
Таким образом, второй совет — используйте айтишные инструменты. Конечно, выучить язык программирования и освоить несколько вспомогательных технологий — задача не из тех, которые даются за неделю. Но, во-первых, она всё же посильная: научиться писать на R/Python и разобраться в Markdown, git, bibtex и csl на уровне, достаточном для подготовки научных статей, можно, и сугубо технический склад ума для этого не нужен. Во-вторых, это выгодная инвестиция: полгода или год, потраченные на вдумчивое освоение инструментов, потом сэкономят кучу времени. Наконец, навыки программирования помогут уйти в айти, если в академии совсем надоест. Я свой путь профессионального разработчика именно с R и статистики для магистерской диссертации начинал, но об этом была другая статья.
ИИ-редактор, или Избавляемся от акцента
Часть статей я писал по-русски, а часть — по-английски. Одна англоязычная ушла в дальнее зарубежье, а две — в ближнее: Казахстан и Беларусь. Я выбрал язык специально: большинство научных статей в мире написаны по-английски, и по моим впечатлениям, статьи на национальном языке читают только внутри страны. В частности, я почти никогда не читал и даже не пытался автоматически перевести статьи на немецком, испанском или, скажем, корейском. Кроме того, тема у меня весьма специфичная, по которой на русском работ почти нет, зато есть что-то на английском. По-английски я нормально читаю, но пишу, по-моему, косноязычно и с ошибками. Раньше я использовал Grammarly, чтобы искать и исправлять ошибки, но на этот раз обратился к Deepl — и он работает впечатляюще.
Deepl Write — это ИИшный редактор текстов на английском (и нескольких других европейских языках). В основе там, скорее всего, лежит LLM, так что совсем без новомодного «искусственного интеллекта» я по факту не обошёлся, но не в виде автогенерации и бесед с чат-ботом, а в виде редактирования собственноручно написанного. Работает Deepl Write так: слева вставляешь текст, при желании чуть настраиваешь — справа видишь отредактированный вариант. Стиль я обычно указывал «Академический». Не уверен, что это наилучший вариант: результат частенько выглядит уж слишком высокопарно. Количество правок раз на раз не приходится: иногда в предложении меняется пара слов, но иногда оно переписывается почти полностью, причём вместе с соседями, объединяясь в одно или разбиваясь на несколько. Можно посмотреть варианты перефразирования и выбрать наиболее подходящий. Бесплатная версия принимает тексты длиной до двух тысяч символов, поэтому я правил статью по кусочкам.
Основная тонкость работы с Deepl Write — за ним нужен глаз да глаз: он не прочь исказить смысл, выдумать лишнее, наделать ошибок (да, бывает и так), писать однотипно (например, мне почти всегда менял use на utilize/employ). Не всегда он с ходу правит наилучшим образом — нужно посмотреть все варианты и выбрать оптимальный. Мне временами хотелось довериться ИИ-редактору и бездумно копировать результат, но я специально тормозил себя: внимательно изучал правки, выбирал нужные фрагменты или переписывал их вручную. Может, в результате получился менее лощёный, но более естественный текст: GPT-детекторы говорили, что он полностью или преимущественно человеческий. К слову говоря, как минимум Springer не возражает против использования ИИ и не требует заявлять о его использовании для редактуры, но предупреждает: отвечает за статью исключительно автор.
Словом, третий совет — смело пишите по-английски с ИИ-редактором. Такой редактор заметно улучшает качество: статьи выглядят менее «деревянными», более естественными. Вероятно, для тех, кто свободно владеет английским, пользы от ИИ немного, но далеко не все отечественные исследователи таковы. У многих, по моим впечатлениям, мысль о том, чтобы опубликоваться в англоязычном журнале, натыкается на страх и сомнения, связанные с языком (вопросы о «Большом Брате» и «тоннеле в Японию» пока аккуратно обойду стороной). ИИ-редактор помогает обойти этот барьер. К слову говоря, помимо Deepl Write есть яндексовский редактор текста на английском, но мне показалось, что он хуже.
Резюме, или Будущее за ИИ?
Мой рассказ о приёмах и инструментах, которые я использовал для своего «марш-броска в эконом-географию», подошёл к концу. Возможно, кто-то найдёт в этом тексте что-то полезное для себя и сможет работать продуктивнее. На всякий случай вот ссылка на мой Гитхаб с исходными данными и кодом статей как подтверждение, что вся эта история не выдумана, и как способ поделиться примерами кода.
Меня начинают посещать мысли, что хотя я автоматизировал довольно много рутинной исследовательской работы, генеративный ИИ способен облегчить жизнь ещё больше. В написании статьи остаётся ещё много скучных и однообразных вещей. Кажется, что современные модели должны справиться с обзором литературы, аннотацией и заключением (по сути, кратким пересказом текста). Если копнуть чуть глубже, то раздел с методикой в статье, основанной на данных, — это пересказ логики, изложенной в коде, а описание результатов — это аналитика по данным, и такие задачи тоже выглядят как посильные для LLM. Сам код, в свою очередь, модели тоже умеют писать. Почти ничего из этого я, впрочем, пока не пробовал. Попытка сделать обзор литературы с помощью Perplexity завершилась неудачей: править пришлось едва ли не каждое предложение, постоянно натыкаясь на ошибки и галлюцинации. Пока я остаюсь скорее скептиком в вопросе о замене исследователя на ИИ-агента. Впрочем, если вдруг в какой-то момент я пойму, как написать качественную статью с помощью ИИ, я не сильно расстроюсь: смысл в исследованиях все равно останется как минимум до того момента, пока «сильный ИИ» не найдёт ответ на главный вопрос жизни, вселенной и всего такого.
Буду рад, если расскажете в комментариях о тех инструментах, технологиях и приёмах для науки, которые используете сами :)
P. S. В качестве обложки для статьи я взял фрагмент работы С. А. Хлюпиной — одного из победителей конкурса «Нарисуй географа». Номинально она не об эконом-географе, а о картографе, но мне показалось, что смыслу моей статьи соответствует больше, чем рисунок об эконом-географе, который среди конкурных работ тоже есть. Надеюсь, что ни Русское географическое общество, ни автор не возражают (а если возразят, то придётся просить чатГПТ нарисовать что-то похожее).