Устав от проблем с доступом к зарубежным сервисам, я решил создать собственный аналог NotebookLM — доступный инструмент для работы с исследовательскими материалами, который подойдёт не только жителям России, но и всем, кто ищет альтернативу импортным решениям.

Что такое NotebookLM и зачем его заменять?

NotebookLM — это сервис, позволяющий загружать научные статьи, PDF, видео и другие материалы, а затем задавать по ним вопросы на естественном языке. Система анализирует контент, строит базу знаний, генерирует выжимки и даже помогает готовиться к экзаменам через флешкарточки.

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

Зачем делать своё, если есть ChatGPT или RAG?

Да, ChatGPT умеет работать с PDF. Но только пока речь о паре файлов. Когда нужно проанализировать 15 статей для курсовой, модель начинает путать авторов, приписывать одни выводы другим. Не потому что тупая — просто это чат. Закрыл вкладку — и всё забыто.

Можно собрать RAG самостоятельно. Есть фреймворки: LlamaIndex, Haystack. Они режут текст на чанки, векторизуют, ищут. На чистом PDF — красиво. В реальности: скан учебника превращается в мусор, YouTube-лекции не парсятся, а поиск возвращает одни и те же фрагменты из 40 источников.

Я решил сделать систему, где источники загружаются один раз и остаются в блокноте навсегда. Система сама решает, сколько контекста взять из каждого документа. Плюс — инсайты, заметки, флешкарточки. Всего этого нет в стандартных RAG-решениях.

Как это выглядит для пользователя

Работа строится вокруг блокнотов — проектов вроде «Курсовая по нейробиологии» или «Подготовка к ЕГЭ». Внутри — источники, чат, заметки и карточки.

Загрузил материалы один раз — они остаются. Через месяц добавил новую статью к 20 старым — задал вопрос. JuliaLM видит всё сразу. Не нужно начинать с нуля.

Источники — это PDF, ссылки, YouTube-видео, сканы, текст из буфера. JuliaLM сама извлекает текст, делает саммари и готовит фрагменты для поиска.

Чат — задаёшь вопрос, получаешь ответ с привязкой к источникам. Без галлюцинаций. Только по тому, что загружено.

Архитектура

Фронтенд — Nuxt.js, бэкенд — FastAPI, основная база — SurrealDB. Всё в Docker Compose.

SurrealDB — неочевидный выбор. Это мультимодальная база: реляционные таблицы, графовые связи и встроенный векторный поиск — всё в одном. Можно спорить о зрелости, но для моего случая это заменило Postgres + Redis + Pinecone. Один сервис вместо трёх — проще деплоить и дешевле поддерживать.

Что происходит при загрузке источника

Пользователь добавляет источник: ссылку, файл или текст. Запускается многоступенчатый пайплайн.

Обработка очереди

Обработку нельзя делать синхронно. PDF на 200 страниц может парситься 30–40 секунд. Держать HTTP-соединение — плохая идея: таймауты, обрывы, спиннер без прогресса.

Решение: два режима. Для лёгких источников — синхронная обработка (5–10 сек). Для тяжёлых — асинхронная: API сразу возвращает command_id, статус «Обработка…», фронтенд опрашивает прогресс.

Очередь задач — своя реализация на SurrealDB. Можно было взять Celery или RQ, но это ещё один Redis. Наш вариант хранит задачи в базе: с ретраями (до 5 попыток), экспоненциальным бэкоффом и отслеживанием прогресса. Не для масштаба, но для нас — работает.

Извлечение текста: каскад фолбэков

Тип источника определяет путь извлечения. Для каждого — не один метод, а цепочка с резервными вариантами.

PDF и документы: основной парсер — Docling (через обёртку content_core). Он сохраняет структуру: заголовки, таблицы, списки — в чистый Markdown. Для PPTX или XLSX — Gotenberg (headless LibreOffice), который конвертирует почти всё.

YouTube: три уровня:

• youtube-transcript-api — официальные субтитры. Приоритет: русские → английские → испанские/португальские (для академического контента).
• pytubefix с флагом ANDROID — притворяется мобильным приложением, реже блокируется.
• Firecrawl или Jina — крайние случаи, когда всё сломалось.

Каждые пару месяцев YouTube что-то ломает. Каскад спасает: пользователь не замечает сбоев.

Веб-страницы: основной — Playwright (headless Chromium) с полным рендерингом JS. Рандомизируем User-Agent, viewport, navigator — иначе капча или пустая страница. Текст извлекаем через readability (алгоритм из Firefox). Если не сработало — Jina Reader, потом простой HTTP. Опять каскад.

Изображения: сканы и фото отправляются в vision-модель как base64. Медленно, но хорошо работает с рукописным текстом и плохими сканами.

Векторизация: нарезка, эмбеддинги и грабли

После извлечения текста — подготовка к семантическому поиску. Это фоновая задача vectorize_source.

Нарезка на чанки

Фрагменты по ~500 токенов с перекрытием 15%. Сплиттер использует приоритеты: сначала двойные переносы (абзацы), потом одинарные, точки, запятые, пробелы — чтобы не рвать предложения.

Почему 500 токенов? Маленькие чанки (100–200) — точный поиск, но теряется контекст. Большие (1000+) — наоборот. 500 — эмпирическая золотая середина для научных статей и конспектов.

Четыре стратегии поиска

При вызове search_sources запускаются четыре стратегии параллельно:

• Vector search — семантический поиск по эмбеддингам. Находит по смыслу: «проблемы со сном» → «нарушения циркадных ритмов».
• Text search — классический BM25. Точные совпадения ключевых слов.
• Title search — поиск по заголовкам. Быстро, если знаешь, откуда информация.
• Insight search — поиск по саммари и инсайтам. Полезно, когда ключевые тезисы уже выделены.

Результаты дедуплицируются: если три стратегии нашли один источник — это сильный сигнал. Скор увеличивается на +0.05 за каждое дополнительное попадание. Возвращаются топ-5.

Почему четыре? Ни одна стратегия не работает везде. Комбинация покрывает больше случаев.

Бюджет контекста: как не взорвать окно модели

Проблема: модель нашла 5 релевантных источников, но каждый — по 100 страниц. Отдать всё? Не влезет. По одному чанку? Потеряем контекст.

Решение — система бюджетов. Общий лимит на запрос — 300 000 символов (~75K токенов). На каждый источник — минимум 5 000, максимум 40 000 символов.

Три сценария:

• Короткий источник — отдаём целиком.
• Длинный, запрос известен — инсайты + релевантные чанки. Запускаем vector search внутри документа (порог ≥ 0.15).
• Длинный, запрос неизвестен — инсайты + начало текста. Лучше, чем ничего.

Так можно работать с книгами на сотни страниц, не перегружая контекст.

Флешкарточки и интервальное повторение

Отдельная фишка: генерация флешкарточек с интервальным повторением.

Пользователь выбирает источники, указывает количество карточек — модель генерирует пары «вопрос-ответ». Один факт — одна карточка. Формат — строгий JSON, с валидацией.

После генерации — FSRS (Free Spaced Repetition Scheduler). Тот же алгоритм, что в Anki, но современная реализация. Каждая карточка хранит стабильность, сложность и состояние (новая, изучается, повторяется, переучивается). При оценке 1–4 алгоритм рассчитывает следующий показ.

Зачем не интегрировались с Anki? Чтобы убрать шаги. Читаешь в JuliaLM — генерируешь карточки — учишь. Без экспорта, импорта, переключений.

Поиск по базе знаний

Кроме RAG в чате — отдельный поиск: BM25 (полнотекстовый) и vector search (семантический).

Есть и третий режим — «Спросить базу знаний». Это LangGraph-граф:

• Модель анализирует вопрос и генерирует стратегию: до 5 поисковых запросов с инструкциями.
• Запросы выполняются параллельно, каждый возвращает до 10 результатов.
• Для каждого — промежуточный ответ.
• Финальная модель синтезирует всё в один связный ответ.

Звучит как overkill, но для сложных вопросов («в чём авторы расходятся по теме X?») работает заметно лучше, чем одиночный поиск.

Планы и квоты

Тарификация — сложный инженерный вызов. Три плана:

• Free — 0₽, 20 промптов за всю жизнь.
• Pro — 799₽/мес, 800 промптов в 5-часовом скользящем окне.
• Business — 1199₽/мес, 2000 промптов.

Скользящее 5-часовое окно вместо дневного или месячного — компромисс для студентов. Типичный паттерн: 100 запросов за вечер, потом неделя без активности. Месячный лимит — щедрый, дневной — жёсткий. Пятичасовое окно — баланс: можно бустить, но нельзя утилизировать всё за час.

Перед каждым вызовом LLM проверяется квота. При истечении подписки — автоматический даунгрейд на Free. Без сюрпризов, без скрытых списаний.

Полный путь: от PDF до ответа

От загрузки PDF до ответа с цитатами — 15–30 секунд на обработку + 5–10 секунд на генерацию.

Итог

JuliaLM — не обёртка над ChatGPT. Это система с собственным пайплайном, четырёхстратегийным RAG, бюджетированием контекста и интервальным повторением.

Не всё идеально: YouTube периодически ломает транскрипцию, SurrealDB пока не дотягивает до Postgres по зрелости. Но для задачи «загрузил 30 статей, задал вопрос, получил ответ с цитатами» — работает.

Есть бесплатный план на 20 запросов. Сервис в бета-версии — возможны баги.

Устав от вечных мук впн, прокси и прочихЗахотев в импортозамещение решил склепатьNotebookLMна свой лад доступный всем проживающим в необъятной и не только.

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

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

А зачем вообще так усложнять, есть же ChatGPT/алиса/любая RAG

Окей, давайте честно. «Зачем мне это, если есть ChatGPT?» - нормальный вопрос. Закинул PDF, спросил, получил ответ. Работает же.

Работает пока один файл и один вопрос. А когда 15 статей для курсовой ChatGPT начинает путать, что откуда, и приписывает выводы одного автора другому. Не потому что тупой, а потому что это чат. Поговорили, закрыл вкладку и он забыл. Завтра загружай всё заново.

Есть вариант собрать RAG самому. RAG - это когда модель сначала ищет нужный кусок в твоих документах, а потом отвечает на его основе. Для этого есть готовые библиотеки: LlamaIndex, Haystack. Они нарезают текст на куски, превращают в векторы, ищут по ним. На демо с одним чистым PDF красиво. В жизни скан учебника превращается в мусор, ютуб-лекцию фреймворк не понимает, а из 40 источников поиск упорно возвращает куски из одного и того же.

Чтобы пользователям не мучаться решил сделать своё. Источники загружаются один раз и живут в блокноте постоянно. Система, которая сама решает, сколько контекста отдать модели из каждого источника. Плюс инсайты, заметки, флешкарточки, из RAG-фреймворка ты этого не получишь.

Как это выглядит для пользователя

База это блокноты. Блокнот это проект, например: «Курсовая по нейробиологии», «Подготовка к ЕГЭ», «Анализ конкурентов». Внутри уже идут источники, чат, заметки и карточки. Загрузил материалы один раз и они живут там постоянно. Через месяц открываешь, добавляешь новую статью к старым двадцати, задаёшь вопрос, Julia видит всё сразу. Не нужно каждый раз начинать с нуля.

Источники это всё, всю информацию нейронка берёт именно оттуда, не хватя мусор из своего контекста. PDF, статья по ссылке, ютуб-лекция, скан конспекта, текст из буфера обмена. Julia сама извлекает текст, делает саммари и разбивает на фрагменты для поиска.

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

Архитектура

Архитектурно всё выглядит так: Nuxt.js на фронтенде, FastAPI на бэке, SurrealDB как основная база, и несколько вспомогательных сервисов в Docker Compose.

SurrealDB наверное, самое неочевидное решение. Это мультимодальная база: реляционные таблицы, граф-связи между записями и встроенный векторный поиск всё в одном движке, что мягко говоря привлекает. Можно спорить, насколько это зрелое решение, но для моего случая это убирает необходимость держать отдельно Postgres + Redis + Pinecone. Один сервис вместо трёх явно проще деплоить и дешевле поддерживать.

Что происходит при загрузке источника

Пользователь нажимает «Добавить источник» и выбирает один из вариантов: вставить ссылку, загрузить файл или вставить текст. За кулисами запускается пайплайн из нескольких стадий.

Обработка очереди

Первое, что мы поняли на раннем этапе: обработку нельзя делать синхронно. Если пользователь загружает PDF на 200 страниц, парсинг и векторизация могут занять 30-40 секунд. Держать HTTP-соединение открытым столько времени плохая идея: таймауты, обрывы, и пользователь смотрит на спиннер, не понимая, что происходит.

Поэтому у нас два режима. Для мелких источников (короткий текст, ссылка на статью) синхронная обработка, ответ за 5-10 секунд. Для тяжёлых файлов асинхронный режим: API мгновенно возвращаетcommand_id, источник появляется в блокноте со статусом «Обработка…», а фронтенд поллит статус раз в пару секунд.

Для очереди задач мы написали свой фреймворк поверх SurrealDB. Да, можно было взять Celery или RQ, но это ещё один Redis в стеке, ещё один процесс для мониторинга. Наш вариант хранит задачи прямо в базе данных: с ретраями (до 5 попыток), экспоненциальным бэкоффом и отслеживанием прогресса. Не самое масштабируемое решение в мире, но для нашей нагрузки работает.

Извлечение текста: каскад фолбэков

Здесь начинается самое интересное. Тип источника определяет, какой путь извлечения текста будет использоваться. И для каждого типа у нас не один метод, а каскад с фолбэками если основной способ ломается, автоматически включается запасной.

PDF и документы.Основной парсер Docling через нашу обёртку content_core. Docling хорошо справляется со структурой: заголовки, таблицы, списки всё это превращается в чистый Markdown. Для экзотики вроде PPTX или XLSX подключается Gotenberg - headless LibreOffice, который конвертирует почти что угодно.

YouTube.Вот тут был ад. YouTube активно борется с ботами, и каждый месяц что-нибудь ломается. Поэтому тут три уровня:

1. youtube-transcript-apiзапрашивает официальные субтитры. Работает быстро и надёжно, но только если у видео есть субтитры. Мы настроили цепочку языков: сначала русские, потом английские, потом испанские и португальские (для академического контента часто есть).
2. pytubefixс флагом ANDROID-клиента когда субтитров нет. Притворяется приложением YouTube на Android, что снижает шанс блокировки.
3. Firecrawl или Jina крайний случай, когда всё остальное сломалось.

Каждые пару месяцев YouTube меняет что-то в API, и один из уровней отваливается. Каскад спасает: пользователь даже не замечает, что основной путь перестал работать.

Веб-страницы.Тут аналогичная история. Playwright (headless Chromium) с полным JS-рендерингом - основной вариант. Мы рандомизируем User-Agent, viewport, подменяем navigator без этого половина сайтов отдаёт капчу или пустую страницу. Текст вытаскиваем через readability (тот же алгоритм, что Firefox использует в режиме чтения). Если Playwright не справляется, то Jinja Reader, потом простой HTTP. Опять каскад.

Изображения.Сканы и фото отправляются в vision-модель как base64. Не самый быстрый OCR, но работает с рукописным текстом и кривыми сканами хорошо.

Векторизация: нарезка, эмбеддинги и грабли

После извлечения текста нужно подготовить его для семантического поиска. Это отдельная фоновая задачаvectorize_source.

Нарезка на чанки

Текст разбивается на фрагменты по ~500 токенов с перекрытием в 15%. Звучит просто, но на самом деле штука сложнее, наш сплиттер пробует разделители по приоритету: сначала двойные переносы строки (границы абзацев), потом одинарные, потом точки, запятые, пробелы. Чтобы чанк не заканчивался на середине предложения.

Почему 500 токенов? Маленькие чанки (100-200 токенов) дают лучшую точность поиска, но теряют контекст. Большие (1000+) наоборот. 500 эмпирически выбранная золотая середина для наших сценариев использования: научные статьи, конспекты, длинные лонгриды.

Четыре стратегии поиска

Когда модель вызывает инструментsearch_sources, внутри запускаютсячетыре стратегии параллельно:

1. Vector searchсемантический поиск по эмбеддингам чанков. Находит по смыслу, даже если слова не совпадают. Запрос «проблемы со сном» найдёт чанк про «нарушения циркадных ритмов».
2. Text searchклассический BM25 по полному тексту. Находит точные совпадения ключевых слов.
3. Title searchполнотекстовый поиск по заголовкам. Быстрый способ найти нужный источник, если пользователь примерно знает, откуда информация.
4. Insight searchпоиск по саммари и инсайтам. Полезен, когда трансформация уже выделила ключевые тезисы и они содержат ответ.

Результаты дедуплицируются: если три стратегии нашли один и тот же источник это сильный сигнал релевантности. Скор бустится на +0.05 за каждое дополнительное «попадание». Модели возвращаются топ-5 результатов.

Почему четыре стратегии, а не одна? Потому что ни одна стратегия не работает идеально для всех типов запросов. Vector search отлично находит семантически близкое, но может пропустить точное совпадение термина. BM25 наоборот. Комбинация четырёх подходов покрывает больше случаев, чем любой из них по отдельности.

Бюджет контекста: как не взорвать окно модели

Это та часть, которой не было ни в одном туториале по RAG, и которую нам пришлось придумывать самим.

Проблема: модель нашла 5 релевантных источников, но каждый по 100 страниц. Отдать всё? Не влезет в контекст. Отдать по чанку? Потеряем информацию. Мы решили через систему бюджетов.

Общий бюджет на один запрос 300 000 символов (примерно 75K токенов). Для каждого источника минимум 5 000 символов (даже если бюджет почти исчерпан) и максимум 40 000.

Дальше три сценария:

Источник короткийотдаём целиком. Простой случай.

Источник длинный, но запрос известенотдаём инсайты + релевантные чанки. Для этого ещё раз запускаем vector search, но уже внутри конкретного источника, с низким порогом (cosine similarity ≥ 0.15). Получаются самые релевантные фрагменты из длинного документа.

Источник длинный, запрос неизвестенотдаём инсайты + начало текста. Не идеально, но лучше, чем ничего.

Эта система позволяет работать с книгами на сотни страниц без того, чтобы модель захлебнулась контекстом.

Флешкарточки и интервальное повторение

Отдельная подсистема, которая мне нравится: генерация флешкарточек из источников с полноценным интервальным повторением.

Работает так: пользователь выбирает источники или заметки, указывает количество карточек и модель генерирует пары «вопрос-ответ». Один факт - одна карточка. Формат строгий: JSON, каждая карточка валидируется.

Но генерация это полдела. Важнее то, что происходит после. Каждая карточка живёт в системе FSRS (Free Spaced Repetition Scheduler) это тот же алгоритм, что используют Anki-подобные приложения, но более современная реализация. Карточка запоминает свою «стабильность», «сложность» и «состояние» (новая, изучается, повторяется, переучивается). При каждом повторении пользователь ставит оценку от 1 до 4, и алгоритм пересчитывает, когда показать карточку снова.

Зачем мы это сделали, а не интегрировались с Anki? Потому что убирает шаг. Пользователь читает исследование в JuliaLM, тут же генерирует карточки и тут же их учит. Не нужно экспортировать, импортировать, переключаться между приложениями.

Поиск по базе знаний

Помимо RAG в чате, у нас есть отдельный поиск. Два режима: полнотекстовый (BM25 через встроенную функцию SurrealDB) и семантический (vector search по эмбеддингам).

Но есть и третий вариант «Спросить базу знаний». Это отдельный LangGraph-граф, который работает хитрее:

1. Модель анализирует вопрос и генерирует стратегию: до 5 поисковых запросов, каждый с инструкцией что именно искать и на что обращать внимание.
2. Все запросы выполняются параллельно, каждый возвращает до 10 результатов.
3. Для каждого набора результатов модель формулирует промежуточный ответ.
4. Финальная модель синтезирует всё в один связный ответ.

Звучит как overkill, но для сложных вопросов (типа «в чём авторы моих источников расходятся по теме X?») это даёт заметно лучшие результаты, чем одноходовый поиск.

Планы и квоты

Тарификация один из самых неочевидных инженерных челленджей. У нас три плана: Free (0₽, 20 промптов за всю жизнь аккаунта), Pro (799₽/мес, 800 промптов за 5-часовое окно), Business (1199₽/мес, 2000 промптов).

Ключевое решение скользящее 5-часовое окно вместо дневного или месячного лимита. Почему? Студенты. Типичный паттерн использования: человек садится за подготовку к экзамену и за один вечер делает 50-100 запросов, а потом неделю не заходит. Месячный лимит в 800 промптов при таком паттерне ощущается щедрым. Дневной лимит в 26 (800/30) ощущается жёстким. Пятичасовое окно компромисс: бустишь как хочешь, но не можешь утилизировать весь лимит за час и всё жди следующего окна.

Перед каждым вызовом LLM проверяется квота. Если подписка истекла автоматический даунгрейд на Free. Без сюрпризов, без скрытых списаний.

Весь путь целиком

Для наглядности полный пайплайн от PDF до ответа:

От загрузки PDF до ответа с цитатами 15-30 секунд на обработку плюс 5-10 секунд на генерацию ответа.

Что в итоге?

JuliaLM не обёртка над ChatGPT!!! Это система с собственным пайплайном обработки, четырёхстратегийным RAG, бюджетированием контекста и интервальным повторением. Не всё идеально, YouTube периодически ломает транскрипцию, а SurrealDB пока не Postgres по зрелости. Но для задачи «загрузил 30 статей, задал вопрос, получил ответ с цитатами» работает.

Если хотите попробовать есть бесплатный план на 20 запросов, сервис пока в бэта версии, возможны баги.