Собрать полностью локальный медицинский RAG-ассистент на ноутбуке с 4 ГБ VRAM можно как справочный прототип. Он ищет фрагменты в заранее подготовленном корпусе, кратко объясняет найденное и возвращает точные цитаты. Комфортная работа зависит от размера локальной LLM, свободной RAM, контекста, KV-кэша и числа последовательных вызовов, поэтому одного факта загрузки модели недостаточно.
Практичная граница проекта проходит между справочным поиском и клинической автоматизацией. Ассистент может найти нужный раздел монографии, сопоставить вопрос с локальными текстами, показать иллюстрацию или открыть DICOM-исследование. Диагноз, назначение лечения, экстренная сортировка и самостоятельная интерпретация снимка требуют отдельной клинической валидации и в такую архитектуру по умолчанию не входят.
В основе схемы лежат контролируемый корпус монографий, локальные эмбеддинги, векторный индекс, лёгкое переранжирование, последовательные агентные роли и журнал цитат. Принципы работы mmap в llama.cpp помогают понять загрузку крупных файлов, но не создают дополнительную быструю VRAM. Готовой реализации медицинского RAG, DICOM-вьюера или подтверждённых замеров именно на 4 ГБ VRAM для этой схемы нет, поэтому характеристики и бенчмарки нужно получать собственными тестами.
Офлайн медицинский ИИ без интернета: что реально получить на 4 ГБ VRAM
Что означает «полностью локальный»
Полностью локальный контур означает, что запрос пользователя, LLM, модель эмбеддингов, индекс, оркестратор, изображения, DICOM-файлы и журнал цитат обрабатываются на ноутбуке. Удалённый API не участвует в генерации, поиске, распознавании текста и просмотре исследования.
Проверять нужно весь стек. Установленный пакет может обращаться к сети за моделью, обновлением, телеметрией, OCR или внешним сервисом индексации. Для автономной работы заранее скачайте нужные веса и зависимости, отключите сетевые вызовы, проверьте настройки журналирования и протестируйте приложение при заблокированном соединении.
Удобный контрольный сценарий выглядит так: сеть отключена, запрос отправлен, найден фрагмент локального документа, цитата открывается по сохранённой координате, а изображение читается из локального хранилища. Если какой-либо шаг ломается, система ещё не офлайн.
Для конфиденциальных документов полезно сравнить эту схему с общими сценариями работы локальных LLM без передачи данных во внешний сервис.
Что такой ассистент может и чего не должен обещать
Допустимый набор задач включает поиск по монографиям, извлечение релевантных абзацев, сравнение определений, краткое резюме с цитатами и навигацию по локальному архиву изображений. Пользователь получает путь к фрагменту и видит, на каком тексте построено объяснение.
Система не должна выдавать диагноз, подбирать лекарство, назначать дозировку, определять срочность обращения или интерпретировать снимок как врач. Такой запрет относится и к уверенным формулировкам, и к мягким подсказкам, которые фактически подменяют решение специалиста.
Цитата подтверждает наличие утверждения в документе. Она не доказывает, что документ подходит конкретному пациенту, не гарантирует актуальность рекомендации и не заменяет медицинскую проверку. В интерфейсе полезно разделить три блока: дословный фрагмент, пересказ и вывод об ограничениях.
Медицинский AI-ассистент на 4 ГБ VRAM: считаем память до запуска
Почему размер GGUF-файла - только начало расчёта
Размер файла GGUF описывает веса модели на диске. При запуске появляются дополнительные расходы: часть весов может попасть в VRAM, часть останется в RAM, а вычисления используют временные тензоры. Отдельно расходуются память под контекст и KV-кэш.
До сборки зафиксируйте:
- название модели и вариант квантования;
- размер GGUF-файла;
- свободную RAM после загрузки ОС и фоновых программ;
- доступную VRAM;
- размер контекста;
- объём KV-кэша;
- временные буферы и режим offloading;
- размер эмбеддингов и локального индекса;
- число последовательных вызовов в агентной цепочке.
RAG добавляет к обычному диалогу найденные фрагменты, служебные инструкции и историю обмена между ролями. Длинная выдержка или несколько шагов подряд могут изменить задержку и расход памяти даже при коротком пользовательском вопросе.
Как работает mmap в llama.cpp
mmap отображает файл модели в виртуальное адресное пространство процесса. Операционная система подгружает нужные страницы по мере обращения к ним, поэтому весь файл не обязан немедленно оказаться в RAM.
Механизм упрощает работу с крупным файлом, но не превращает 4 ГБ VRAM в большой пул быстрой видеопамяти. Если часть вычислений и весов обслуживается через RAM и CPU, скорость зависит от обмена между компонентами. Задержка может стать приемлемой для короткого вопроса и неудобной для длинного контекста.
Полезно различать три факта: файл доступен системе, модель запускается, сценарий подходит для ежедневной работы. mmap влияет на способ доступа к данным, а не отменяет ограничения пропускной способности, KV-кэша и временных буферов.
Связь между размером модели, контекстом, KV-cache и скоростью подробно раскрывается в разборе ограничений локального инференса.
Контекст и KV-кэш: почему короткий запрос не показателен
KV-кэш хранит промежуточные состояния для уже обработанных токенов. Чем длиннее контекст и история диалога, тем больше памяти занимает этот буфер. В RAG к истории добавляются найденные чанки, инструкции маршрутизатора и результаты предыдущих ролей.
Проверяйте конфигурацию минимум в трёх режимах:
- короткий вопрос по одному фрагменту;
- длинная выдержка с несколькими источниками;
- последовательная агентная цепочка с поиском, проверкой и формированием ответа.
Фиксируйте время до первого токена, скорость генерации, пиковую RAM и VRAM, а также момент, когда начинается заметный обмен с CPU. Универсальный численный предел здесь не задан: результат зависит от модели, квантования, движка, контекста и фоновой нагрузки.
Чек-лист перед сборкой
| Параметр | Что записать | Зачем это нужно |
|---|---|---|
| Модель | Название, квантование, размер GGUF | Оценить весовой бюджет и режим offloading |
| Память | Свободная RAM и доступная VRAM | Понять запас для ОС, индекса и буферов |
| Контекст | Лимит токенов и фактический объём чанков | Оценить KV-кэш и длину промпта |
| Поиск | Размер эмбеддингов и индекс | Проверить расход памяти до запуска генератора |
| Оркестрация | Количество последовательных ролей | Понять задержку и пиковую нагрузку |
| Сценарий | Короткий вопрос, длинный документ, цепочка | Проверить реальную пригодность, а не факт старта |
Модель Qwen3.8-Flash-Next IQ3_XSS можно использовать лишь как пример записи конфигурации в таком чек-листе. Доступных данных недостаточно, чтобы приписать ей конкретную скорость или пригодность для ноутбука с 4 ГБ VRAM.
Как собрать медицинский RAG на ноутбуке: схема полностью локальной системы
Маршрут запроса от вопроса до цитаты
Запрос удобно представить как структуру с полями: текст вопроса, тип задачи, допустимый набор источников, требование к цитате и режим ответа. Планировщик определяет, нужен ли текстовый поиск, поиск изображения, открытие DICOM или честный отказ из-за отсутствия данных.
- Маршрутизатор классифицирует запрос и задаёт ограничения.
- Retriever ищет кандидатов в локальном индексе.
- Переранжировщик сортирует небольшой набор по нескольким сигналам.
- Проверяющий оценивает достаточность evidence.
- Генератор формулирует ответ в пределах переданных фрагментов.
- Валидатор проверяет цитаты и возвращает результат вместе с координатами источника.
Каждый шаг получает структурированный вход и отдаёт структурированный выход. Такой контракт упрощает отладку: можно понять, ошибка возникла в классификации, поиске, сортировке, проверке или генерации.
Подробный разбор базового пайплайна с чанками, эмбеддингами и цитатами есть в статье о подключении документации к LLM через RAG.
Какие данные остаются внутри локального контура
Разделите хранилища по типам данных:
- оригинальные PDF, изображения и DICOM-файлы;
- извлечённый текст и результаты OCR;
- чанки с заголовками и координатами;
- векторы и индекс;
- запросы, ответы и журнал цитат;
- временные файлы просмотра и кэш интерфейса.
Потенциальные точки утечки находятся рядом с каждым компонентом. OCR может быть внешним, библиотека может отправлять телеметрию, интерфейс способен сохранять чувствительный запрос в общий лог, а обновление модели может обращаться к сети. Офлайн-профиль требует проверки всех этих путей.
Для DICOM отдельно контролируйте идентификаторы пациента, дату исследования, название учреждения и метаданные оборудования. Копии для индекса и временные файлы должны получать те же ограничения доступа, что и исходное исследование.
Минимальная конфигурация и точки расширения
Первый рабочий контур лучше ограничить четырьмя частями: локальная LLM, локальные эмбеддинги, индекс выбранного корпуса и интерфейс вопрос-ответ с цитатами. На этом этапе измеряется базовая задержка и проверяется отказ при отсутствии нужного факта.
Агентные роли, поиск изображений и DICOM-просмотр подключаются по очереди. После каждого изменения фиксируйте RAM, VRAM, время ответа и сетевую активность. Если чат-модель и эмбеддер не помещаются одновременно, запускайте их последовательно и освобождайте память перед сменой компонента.
Такой порядок даёт понятную точку сравнения. Если сразу добавить несколько генераторов, мультимодальный поиск и длинный контекст, причина сбоя останется неизвестной.
RAG-система для медицины локально: почему основой становятся монографии
Монография и поток публикаций решают разные задачи
Тщательно отобранная монография или другая reference work обычно имеет стабильную структуру, последовательную терминологию и понятную редакцию. Эти свойства упрощают чанкинг, навигацию и повторную проверку цитаты.
Поток публикаций может содержать более свежие сведения, разные методики, противоречивые выводы и неодинаковое качество описаний. Такой корпус требует отбора, версионирования, контроля происхождения и отдельной проверки актуальности.
Стабильный reference corpus удобен для справочных вопросов, где важны воспроизводимость и единая терминология. Он не покрывает всю предметную область и не заменяет процесс обновления клинически актуальных сведений. Монография не получает статус безусловного авторитета только из-за формы публикации.
Как отбирать документы для корпуса
Перед загрузкой PDF задайте правила включения. Проверьте предметную область, полноту нужного раздела, качество текста, редакцию, дату и происхождение документа. Отдельно отметьте таблицы, схемы, подписи к изображениям и приложения, которые могут потеряться при обычном извлечении текста.
Каждому документу присвойте статус:
- Основной, материал разрешено использовать для прямых ответов.
- Дополнительный, текст помогает уточнить термин, но требует осторожного пересказа.
- Устаревший, документ сохраняется для истории корпуса, однако ответ не должен скрывать его редакцию.
- Исключённый, файл не участвует в поиске из-за плохого качества, неполного содержания или неизвестного происхождения.
Зафиксируйте причину каждого решения. Это избавит от ситуации, когда одинаковый вопрос сегодня и после переиндексации получает разные источники без понятного объяснения.
Извлечение текста, чанкинг и метаданные
Чанк храните вместе с названием источника, главой, страницей или другой устойчивой координатой, редакцией, датой и идентификатором версии. Для таблицы полезно сохранять заголовки столбцов, для рисунка - подпись и связь с текстом, для раздела - родительские заголовки.
Разбивайте текст по смысловым границам. Слишком короткий фрагмент теряет условия утверждения, слишком длинный увеличивает контекст и смешивает несколько тем. Заголовок раздела можно добавлять к чанку как служебный контекст, сохраняя исходную цитату отдельно.
Проверяйте несколько страниц вручную после OCR. Ошибка в отрицании, единице измерения, сокращении или таблице способна изменить смысл медицинского утверждения. Наличие вектора не означает, что исходный текст извлечён корректно.
Версионирование и обновление базы
Состав корпуса и дату индексации храните в манифесте. Для каждого чанка сохраняйте связь с первичным файлом, страницей, редакцией и версией индекса. Новые документы добавляйте отдельной версией, не перезаписывая старую без журнала изменений.
В ответе указывайте, если найденный фрагмент относится к старой редакции. При отсутствии нужного раздела система сообщает, что evidence в текущем корпусе не найдено. Она не должна замещать пробел текстом из памяти модели.
Справочная работа может отражать один срез быстро развивающейся области. Поэтому рядом с цитатой полезно показывать дату документа и статус источника, а обновление корпуса проводить как отдельную проверяемую процедуру.
Поиск и лёгкое переранжирование без тяжёлого cross-encoder
Сначала получить небольшой набор кандидатов
Векторный поиск сопоставляет вопрос с локальными эмбеддингами чанков. Retriever возвращает ограниченный список кандидатов, score и метаданные. Генератору не нужно передавать весь корпус: лишний текст расходует контекст и затрудняет проверку цитат.
Для медицинских запросов полезна дополнительная проверка терминов, сокращений, единиц и идентификаторов. Семантически близкий фрагмент может относиться к другому органу, методу или значению одного и того же сокращения. Текстовый сигнал помогает заметить такую ошибку.
Результат поиска храните до генерации. Лог должен показывать исходный запрос, список кандидатов, score, источник и координаты фрагментов.
Что может делать лёгкий reranker
Лёгкий переранжировщик сортирует небольшой набор кандидатов без отдельного тяжёлого cross-encoder. Для оценки можно объединить несколько заранее описанных сигналов:
- смысловую близость запроса и чанка;
- совпадение ключевых медицинских терминов;
- соответствие нужному разделу;
- полноту фрагмента и наличие условий утверждения;
- качество метаданных и происхождение документа;
- близость связанных фрагментов из одной главы.
Формулу и веса сигналов фиксируйте в конфигурации. При одинаковом запросе, составе индекса и настройках порядок должен повторяться либо подробно журналироваться. Без этого нельзя понять, почему цитата изменилась.
Переранжирование помогает выбрать лучший фрагмент среди найденных кандидатов. Оно не создаёт evidence, которого нет в индексе, и не исправляет полностью повреждённый OCR.
Когда переранжирование не спасает поиск
Дополнительная сортировка бесполезна в нескольких случаях:
- нужный факт отсутствует в корпусе;
- документ не распознан или важная часть попала только в изображение;
- запрос слишком общий;
- термин имеет несколько значений;
- утверждение находится в таблице, подписи или схеме, которые индекс не связал с текстом;
- корпус содержит конфликтующие редакции без метаданных.
При недостатке evidence ассистент сообщает об ограничении, показывает близкие найденные фрагменты и предлагает уточнить запрос. Догадка модели не должна появляться под видом медицинского факта.
Агентная схема: разделить поиск, проверку и формулировку ответа
Планировщик и маршрутизатор запроса
Планировщик определяет тип задачи: текстовый справочный вопрос, поиск изображения, запрос к DICOM, неоднозначный термин или вопрос вне корпуса. Его задача - выбрать маршрут, формат результата и ограничения. Медицинский вывод он не формулирует.
На ноутбуке с 4 ГБ VRAM планировщик можно сделать правиловым для простых случаев, а локальную модель подключать к сложной классификации. Это уменьшает число генеративных вызовов. В плане полезно хранить список разрешённых коллекций, максимальное число кандидатов и обязательность точной цитаты.
Retriever и переранжировщик
Retriever передаёт следующей роли список кандидатов, score, название источника, координаты фрагмента и версию корпуса. Переранжировщик меняет порядок по зафиксированной логике и возвращает объяснимый набор сигналов.
При дефиците VRAM эти шаги выполняются последовательно. Индекс может работать отдельно, а локальная LLM загружаться только для тех операций, где требуется генерация. Число кандидатов ограничивается тестами, а не произвольным большим значением.
Проверяющий доказательства
Проверяющий получает черновые утверждения и найденные фрагменты. Для каждого утверждения он ставит один из статусов: подтверждено цитатой, подтверждено частично, не подтверждено или противоречит найденному тексту.
В журнале сохраняются утверждение, дословный фрагмент, название документа, глава или страница и идентификатор версии корпуса. Проверяющий не расширяет смысл цитаты и не заполняет отсутствующие условия своими знаниями.
Генератор ответа и проверка цитат
Генератор получает только отобранные фрагменты и формирует полезный текст с разделением цитаты, пересказа и ограничения. Для факта вне контекста используется явная формулировка: «В текущем корпусе подтверждение не найдено».
Финальный валидатор проверяет, что цитата присутствует в указанном документе, координата не потеряна, версия совпадает, а пересказ не добавляет нового утверждения. Если проверка не пройдена, ответ отправляется на исправление или заменяется отказом.
Несколько специализированных ролей не гарантируют высокий результат сами по себе. При ограниченной памяти роли можно объединить попарно: retriever с переранжировщиком, проверяющий с валидатором цитат. Границы обязанностей сохраняются в структуре данных, даже если код запускает их одной функцией.
Общую идею многошагового поиска с планированием можно сопоставить с разбором агентной маршрутизации запросов, но облачный пример нельзя переносить на полностью офлайн-ноутбук без отдельной адаптации.
Поиск медицинских изображений и DICOM-вьюер без выхода в сеть
Как работает поиск изображения по текстовому описанию
Для локального image search нужен архив изображений или исследований, текстовые описания и общий способ сопоставить текстовый запрос с визуальным материалом. Описание и изображение преобразуются в представления, затем индекс возвращает близкие записи с именем файла, типом исследования и сохранёнными метаданными.
Качество результата зависит от подписей. Если описание слишком общее, содержит ошибку или не отражает ключевую особенность кадра, ближайшее изображение может оказаться лишь тематически похожим. Интерфейс обязан показывать происхождение записи и позволять открыть исходный файл.
Поиск похожего материала не означает поиск патологии у конкретного пациента. Система может найти иллюстрацию по термину или исследование по описанию, но такой результат не превращается в диагноз.
Зачем нужен DICOM-вьюер в RAG-системе
DICOM-вьюер даёт доступ к самому исследованию: серии, отдельным кадрам и связанным метаданным. RAG-слой помогает найти нужное исследование или объяснить термин из локального корпуса. Вьюер остаётся отдельным слоем просмотра.
Маршрут может выглядеть так: текстовый запрос находит запись, проверка связывает её с локальным файлом, интерфейс открывает исследование, а пользователь вручную выбирает серию и просматривает данные. В журнале фиксируйте, какой файл был открыт и какие метаданные показаны.
Текстовый ответ не заменяет навигацию по серии и визуальный контроль изображения. Даже точная цитата из монографии не подтверждает интерпретацию конкретного снимка.
Приватность и ограничения мультимодального контура
Храните DICOM-файлы, изображения, подписи и временные копии на локальном диске с раздельными правами доступа. Контролируйте логи: полный запрос, имя пациента или уникальный идентификатор не должны попадать туда без необходимости.
Перед тестами используйте обезличенные исследования, если это разрешено правилами проекта. Проверяйте кэш браузера, временные каталоги, резервные копии и экспортированные изображения. Сеть должна оставаться отключённой во время поиска и просмотра.
Без отдельной клинической проверки нельзя обещать распознавание патологий, интерпретацию снимков или пригодность для медицинского решения. В описании функции называйте её поиском и просмотром, а не диагностикой.
Точные цитаты и проверяемость: как оценивать ассистента без экзаменационных бенчмарков
Контракт точной цитаты
Для каждого существенного утверждения сохраняйте дословный фрагмент, название источника, главу или страницу, версию документа и идентификатор записи в индексе. Пользователь должен открыть тот же фрагмент после повторного запуска.
Разделяйте уровни результата:
- Прямая цитата, текст без пересказа и скрытого исправления.
- Резюме, короткое изложение найденного фрагмента.
- Интерпретация, объяснение связи с вопросом.
- Ограничение, что найденный текст не подтверждает или не покрывает.
Если фрагмент взят из старой редакции, это отображается рядом с цитатой. Если координата потеряна, утверждение нельзя считать проверяемым, даже если сам текст выглядит правдоподобно.
Набор воспроизводимых проверок
Соберите небольшой фиксированный набор сценариев:
- вопрос, прямой ответ на который присутствует в корпусе;
- запрос по отсутствующему факту;
- неоднозначный медицинский термин;
- вопрос с длинным контекстом;
- два фрагмента с различающимися условиями;
- запрос к индексу изображений;
- проверка открытия DICOM-записи;
- вопрос, который провоцирует диагноз или назначение лечения.
Для каждого теста фиксируйте модель, квантование, размер контекста, состав индекса, версию корпуса, число кандидатов и порядок агентных шагов. Сравнивайте retrieval, корректность цитаты, честность отказа, задержку и потребление памяти по отдельности. Результаты нельзя называть бенчмарком, пока измерения реально не проведены.
Типовые ошибки и корректное поведение при отказе
| Ошибка | Что должен показать интерфейс |
|---|---|
| Нужный фрагмент не найден | Отсутствие подтверждения и близкие результаты без уверенного вывода |
| OCR исказил текст | Предупреждение о качестве извлечения и ссылка на исходную страницу |
| Цитата не совпала с источником | Блокировка ответа до повторного поиска или исправления |
| Редакция устарела | Название версии и дата документа рядом с цитатой |
| Генератор вышел за пределы evidence | Удаление неподтверждённого утверждения или честный отказ |
| Запрос просит диагноз | Отказ от клинического вывода и предложение обратиться к специалисту |
Хороший отказ содержит причину. Фраза «ответ не найден» слабее, чем сообщение о том, что в индексе нет нужного раздела, найденный текст относится к другой редакции или координата цитаты не прошла проверку.
Когда прототип можно считать пригодным для справочной работы
Прототип подходит для ограниченной справочной задачи, если выполнены все условия:
- LLM, эмбеддинги, индекс, изображения и DICOM-файлы работают без удалённых вызовов;
- расход RAM и VRAM измерен в коротком, длинном и агентном сценариях;
- корпус имеет правила отбора, манифест и версии;
- чанки сохраняют источник, координаты и контекст;
- поиск возвращает небольшой набор объяснимых кандидатов;
- переранжирование фиксирует свои сигналы и порядок;
- цитаты воспроизводятся при повторной проверке;
- out-of-corpus запросы приводят к честному отказу;
- ошибки OCR, конфликтующие фрагменты и устаревшие документы видны пользователю;
- image search и DICOM-вьюер не описываются как клиническая автоматизация.
Экзаменационный benchmark не отвечает на вопросы о составе локальной базы, качестве OCR, происхождении источника, воспроизводимости цитат и поведении при отсутствии evidence. Для такого ассистента полезнее собственный набор сценариев с фиксированной конфигурацией и понятным ожидаемым результатом.
Начинайте с текстового справочного контура и короткого контекста. Затем добавляйте переранжирование, агентные роли, поиск изображений и DICOM-просмотр по одному компоненту. На ноутбуке с 4 ГБ VRAM такой порядок позволяет измерять цену каждой функции и сохранять главную границу проекта: ассистент помогает найти и объяснить локальный материал, но не принимает медицинское решение.