Список районов городов РФ: от провалившегося SQL-плана к n8n + Wikipedia API + OpenAI

Это был небольшой срочный заказ с очень конкретным результатом: нужен список в формате регион; город; район по городам России, а если районов нет — строка должна быть без района.

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

Что было важно для бизнеса

• Получить полный список по всем городам РФ, а не частично корректную выгрузку.
• Сохранить понятный формат результата для дальнейшего использования клиентом.
• Не отдавать "формально готовый", но фактически ненадёжный файл.
• Держать прозрачную коммуникацию по срокам, когда выяснилось, что исходная оценка была слишком оптимистичной.
• Довести задачу до рабочего результата, даже если для этого нужно сменить источник и всю логику сборки.

С бизнес-точки зрения ключевой момент был не в том, чтобы любой ценой уложиться в первоначальный план "сделать за один запрос", а в том, чтобы не отдать клиенту некорректные данные. Для подобных задач это важнее скорости: плохая справочная таблица потом ломает фильтры, сегментацию и любые последующие автоматизации.

Если у вас похожая задача (массовая справочная таблица, нестандартная выгрузка, объединение официальных и открытых источников, проверка качества результата), можно прислать задачу в бриф — помогу собрать рабочий pipeline, а не просто "что-то выгрузить".

Отправить бриф

Перед тем как перейти к ходу решения, важный контекст по терминам. В России есть историческая база "КЛАДР" (старый классификатор адресов) и более новая государственная база "ГАР" (государственный адресный реестр). Для задач на адреса и справочники это частые источники, но они не гарантируют, что данные будут лежать в точности в том бизнес-формате, который нужен в конкретном заказе.

Отдельно важно: в РФ есть административное деление и муниципальное деление, и это не одно и то же; плюс нет одной "идеальной" общей федеральной базы, где для всех городов в одинаковом виде лежали бы нужные клиенту внутригородские районы.

Что планировалось сначала

Изначально предполагал, что всё решится простым SQL-запросом к базе КЛАДР, с которой уже работал раньше. Логика была понятная: взять справочник, собрать структуру "регион → город → район", выгрузить CSV и отдать.

Но когда дошло до практики, выяснилось, что в КЛАДР данных по районам городов в нужном виде нет. На этом этапе стало понятно, что "быстрый SQL" не получится, и нужно искать другой источник.

Технические challenges: почему не сработал путь через ГАР

1. Верный источник по идее, но тяжёлый в работе

Поиск по открытым источникам привёл к ГАР (государственный адресный реестр), где действительно есть более актуальные и подробные данные, чем в КЛАДР. Проблема — объём: архив около 50 ГБ.

2. Скачивание из-за границы оказалось нетривиальным

Отдельная неожиданность: страница с индексом файлов была недоступна из-за пределов РФ. Но если получить прямую ссылку на нужный файл, дальнейшее скачивание уже работало (с другого домена). То есть технически данные доступны, но путь к ним оказался неочевидным.

3. Архив не помещался в рабочий ноутбук после распаковки

Даже после скачивания возникла следующая проблема: распаковать весь архив целиком было нельзя — не хватало места на ноутбуке. Решение было промежуточным и довольно "инженерным": читать архив и распаковывать его батчами (примерно по 10 регионов за раз), затем сразу обрабатывать и освобождать место.

4. Главная проблема — качество/структура данных для задачи клиента

После частичной обработки ГАР выяснилось, что автоматизированно получить корректный список районов по всем городам всё равно не получается:

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

Именно здесь был важный момент принятия решения: технически "что-то" уже собиралось, но результат нельзя было отдавать клиенту как качественный и полный. Формально файл есть, по сути — данные ненадёжные.

Разворот решения: n8n + Wikipedia API + OpenAI

Третьим подходом стал workflow в n8n. На вход подал список всех городов РФ, а дальше для каждого города выполнялся такой сценарий:

1. Открыть страницу города в Википедии.
2. Забрать текст статьи через API Википедии.
3. Передать текст в OpenAI с задачей извлечь внутригородские районы/округа в структурированном виде.
4. Собрать итоговую таблицу и сохранить результат.

На практике это сработало лучше, чем ожидалось: результат получился почти идеальным по полноте и качеству.

Отдельные сложности уже в LLM-подходе

• Иногда по названию города Википедия возвращала не статью города, а страницу значений (disambiguation). Таких случаев было около двух десятков, под них сделал отдельное ветвление в workflow.
• Для Москвы и Санкт-Петербурга было быстрее и надёжнее сделать отдельную ручную обработку, чем пытаться универсализировать всё в один шаблон извлечения.
• Нужна была проверка результата не только на формат, но и на смысл (что извлечены именно районы/округа города, а не любые административные сущности из текста).

Результат

• Итоговый файл получился полным и пригодным для использования клиентом.
• Удалось закрыть задачу, хотя исходный план ("один SQL-запрос") оказался неверным.
• Собран переиспользуемый подход через n8n + API + LLM для задач, где официальные справочники не дают нужную бизнес-структуру "из коробки".

Практический вывод из кейса

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

В этом кейсе путь оказался длиннее, чем планировалось: сначала КЛАДР, потом попытка с ГАР, потом n8n + Wikipedia + OpenAI. Но именно разворот решения дал рабочий результат. Иногда это и есть главная ценность в проекте: не упереться в первый технический план, а довести до корректного выхода.