“The stone which the builders rejected, the same is become the head of the corner…” — Matthew 21:42 (Oxford King James Version)

⚠️ Legal Disclaimer

Important Notice for Readers and Regulators:

1. Project Status: The system architecture described in this article is strictly a personal, non-commercial “pet project” (Proof of Concept) developed exclusively for educational, private research, and benchmarking purposes. The system is deployed strictly on isolated local infrastructure, is not distributed, and offers no public web interface, hosting, or external API.
2. Medical & Regulatory Compliance: This software does not qualify as Software as a Medical Device (SaMD) under the US Food and Drug Administration (FDA), European Union Medical Device Regulation (MDR), or Russian Roszdravnadzor frameworks. It is not intended for clinical use, patient triage, automated diagnosis, or treatment planning. It does not replace professional medical advice, diagnosis, or treatment.
3. Copyright & Text Mining: The referenced dataset of 2,500 monographs is stored strictly on a local machine and used solely for private text-indexing, natural language processing (NLP) benchmarking, and search experiments. This use complies with international “Fair Use” principles for non-commercial research (17 U.S. Code § 107) as well as personal-use exemptions under Art. 1273 of the Civil Code of the Russian Federation. The copyrighted source texts are not hosted, published, mirrored, shared, or distributed in any form.
4. Data Privacy: This project operates entirely offline using simulated, synthetic, or fully anonymized test queries. It does not collect, transmit, process, or store Protected Health Information (PHI) under US HIPAA, Personal Data under EU GDPR, or any real-world personal data.

Executive Summary

The article outlines an architecture for an offline, local edge-compute information retrieval system designed to mine global medical literature on standard commodity hardware within strict memory constraints. By utilizing a body of about 2,500 modern curated monographs instead of periodical literature and a resource-efficient agentic framework, the system bridges the gap between massive medical literature databases and local edge-compute boundaries while maintaining absolute data privacy and deterministic auditability. The system facilitates the extraction of scientific knowledge from literature in the fields of clinical medicine, clinical pharmacology, and biochemistry. It also provides a linguistic search engine for pathological medical images and DICOM visualization tools. The proposed AI assistant serves as an accessible semantic research accelerator for frontline practitioners, biomedical engineers, and interdisciplinary researchers.

1.0 Introduction: Motivation for Engineering a Medical Practice AI Assistant — Personal, Strategic and Otherwise

All of us fall ill at some point. Yet, it’s particularly difficult to watch a loved one helplessly struggle with a disease, especially after having fruitlessly visited multiple doctors and amassed stacks of diagnostic test results.

There are two major issues with this situation. First, it is statistically typical, and second, the high cognitive and emotional load almost certainly prevents a patient from rigorously analyzing their data to find a plausible solution. Someone else has to carefully and systematically inspect those doctors’ notes and the wealth of available diagnostic tests, in order to identify discrepancies and make necessary adjustments in parallel with trying to find a more suitable medical specialist.

To successfully resolve this issue, one must evaluate a colossal volume of medical literature, retain vast amounts of complex data, and cross-reference it all with clinical notes and laboratory results. Unless that person is a highly trained, experienced medical professional with exceptional cognitive recall, this remains a nearly impossible task for a human. However, this is precisely where AI-powered Retrieval-Augmented Generation (RAG) systems excel.

The observations detailed above constituted my personal motivation for engineering practice-centric medical AI assistants, particularly because decades of applied mathematical work in biomedical applications have allowed me to accumulate a substantial volume of relevant literature in the field.

More importantly, there is a strategic dimension that motivates this work. With few exceptions, most individuals find it difficult to retain vast volumes of information, with medicine being perhaps one of the most demanding disciplines in terms of memory utilization. The availability of an AI assistant capable of processing thousands of scientific monographs and rapidly retrieving the required context could, at least theoretically, significantly augment the professional capacity of an average physician, effectively bridging the gap with leading experts.

Finally, a properly tailored medical AI assistant serves as a valuable tool for the broader community. It enables individuals to systematically monitor their health parameters, adequately prepare for clinical consultations, and fundamentally enhance their health literacy, among other essential health management tasks.

“The stone which the builders rejected”: building an offline medical search engine on consumer hardware

In order to build an information system that is equally valuable to the professional community and the general public, strict hardware constraints must be imposed.

First, it is imperative that all private data entered into the system remains strictly confidential, as neither enterprise users nor private individuals want their data leaked to the Web. Consequently, the system must be designed to operate solely on a local device without an internet connection. This architecture simultaneously addresses a second critical requirement: maintaining continuous operations in remote regions where network connectivity is unavailable.

Second, the system must run on affordable, commodity hardware. Enterprise clients are equally reluctant to fund expensive, GPU-packed server racks when a standard office laptop should suffice. Ideally, one would want the system to run directly on a smartphone, given the ubiquitous nature of these devices in daily life (see the Figure 1).

However, simple resource-allocation calculations quickly demonstrate that such a deployment would strictly require a top-tier flagship device. Consequently, we establish the standard office laptop (16GB RAM) as our baseline reference hardware with the following Core Engineering Metrics:

• Target Hardware Substrate: Optimized explicitly for Ubuntu Linux using a fixed budget of 4 GB VRAM and 16 GB System RAM.
• Data Isolation Vector: Air-gapped pipeline operates entirely offline, safeguarding proprietary model weights and preventing unauthorized remote data compilation.

In the remainder of this article, we discuss architectural approaches that appear rational and have proven effective for such information systems, as well as analyze the primary architectural challenges arising from the constraints imposed above. Software implementation details will be completely omitted, as they are thoroughly documented in the literature.

Finally, we emphasize that our objective is to design an information system that facilitates the extraction of scientific knowledge from medical literature. The proposed architecture is distinctly not designed as a diagnostic system or a clinical decision support system of any kind. It does not manage compliance, track legal protocols, or automate a physician’s routine duties. Instead, it serves strictly as a semantic research accelerator, allowing professionals and researchers to rapidly mine global scientific literature for deep medical insights under extreme local hardware constraints.

2.0 Architecture of Retrieval-Augmented Generation (RAG) database

We start this section by reiterating the final statement made in the Introduction. It is habitual for a medical RAG to have a prioritized three-tier architecture consisting of (i) an operational tier based on clinical protocols which define step-by-step symptom based diagnostic algorithms, (ii) a safety-and-law tier which provides safety and legal guardrails, and (iii) an explanatory tier based on medical literature. The first two tiers are normally considered the most important, among other things, because they dictate what the local doctor is legally and baseline-operationally expected to do.

However, here the aim is to build an information extraction system designed for scientific discovery. Contrary to the case described above, it serves a completely different engineering purpose than being an operational automation tool designed to manage a doctor’s workflow, legal compliance, or paperwork. Thus, we assume in what follows that a qualified physician must know the laws, protocols, and medical standards of their jurisdiction.

Consequently, medical regulatory standards and recommendations will be discarded from our database entirely. Also omitted will be clinical protocols designed for immediate step-by-step rigid implementation. The rationale for this is that there is a profound, systemic gap between statistical medicine and individual human biology. We do not want to bias RAG search results by imposing averaged statistics of the human population built into standard protocols over personal cases, as it is mathematically likely to fail. Furthermore, it takes an average of 10 to 17 years for a breakthrough discovery in peer-reviewed medical literature to be officially integrated into a government-approved clinical protocol (see the original landmark study by Balas, E. A., & Boren, S. A. 2000. Managing Clinical Knowledge for Health Care Improvement. Yearbook of Medical Informatics, 09(01), 65–70. https://doi.org/10.1055/s-0038-1637943). If you have a complex or fast-evolving condition, standard protocols are, by definition, running on outdated science.

Instead, we choose to pack our offline database with carefully selected recent medical monographs from the world leading publishers, giving a frontline physician immediate semantic access to the 17 years of science that haven’t been encoded into rigid state protocols yet. We also deliberately avoid inclusion of periodic literature sources such as PubMed, since, in our view, normally they lack generalization power and coherence typical for monographic literature. Prioritizing monographic literature over periodicals (journal papers, individual studies, case reports), resolves the following major engineering bottlenecks inherent to local-edge RAG systems: generalization power vs. fragmentation, on the one hand, and semantic contradictions and noise, on the other.

Indeed, by its very nature the scope of a journal paper is to describe an isolated specific problem, normally making its generalization to broader medical practices difficult, if not impossible. Besides, the periodic literature is inherently full of noise, conflicting results, and premature conclusions. Contrary to this, monographs specifically aim to filter out the periodic noise of articles, resolve contradictions, synthesize and unify disjoint facts into a logical and coherent description of the problem matter. As a result, they provide a generic, comprehensive, much more stable and safe knowledge semantic base for an LLM to work with.

Although monographs are more stable, they may still be years behind the latest breakthrough periodicals. Hence, with the limited resources we have to make a trade-off, sacrificing the absolute latest preprint noise for stable, consolidated knowledge. This is a deliberate architectural compromise.

A tight system memory budget (the 4GB VRAM squeeze) calls for a small context window, necessitating the use of highly structured and optimized for information density self-contained text chunks typical of high quality monographic literature. This is opposite to the LLM needing to swallow an entire journal paper, in order to determine the correct context with an eminent threat of flooding the small context window of a 4-bit quantized local model.

Our experience shows that discriminate selection of about 2,500 top level monographs (about 1.5 million pages) covering all branches of contemporary medicine proves to be sufficient to build a reliable information retrieval system able to process the resulting database within acceptable times. Apart from the medical literature, we find it necessary to supplement the RAG base with purely biological monographic literature covering the fields of virology, genetics and biochemistry (on top of medical biochemistry), since these extensions substantially improve search results. Addition of biochemistry proved to be an absolute must for correct analysis of substances and medications, presumably, due to fast progress in pharmacology.

There are various ways in which the constructed database can be analyzed by an LLM. Two of them were examined. Since the database is structured according to the existing fields of medicine (e.g., neurology, hepatology, cardiology, etc.), an attempt was made to first determine the most relevant medical field based on the user search prompt and then bias the search priority to favor the related field. However, this approach has shown to be inferior and less accurate compared to an unbiased search over the entire bibliographic base. Presumably, owing to the complicated character of human biology, its different systems and, consequently, different fields of medicine are interconnected so intimately that their artificial separation inevitably results in perceptible loss of information. An explanation how cross-disciplinary chunks are synthesized (reranking mechanism) before passing them to the LLM is given in the next Section.

3.0 Agentic Architecture, System Prompts and Reranking Mechanism

Strict memory budget does not allow for the use of a proper full-scale multi-agent system with several specialized agents as independent AI units and an orchestrator as their manager. Consequently, a different tactic has to be adopted.

We introduce several independent agentic units, each having its own specialized system prompt. These are (i) a medical assistant which specializes in the retrieval of clinical information, (ii) an assistant called pharm1 which specializes in drug interactions, dosages, and pharmaceutical classifications, (iii) an assistant called pharm2 which focuses on advanced drug research, covering pharmacokinetics and clinical trials, (iv) an assistant called biochem which analyzes molecular pathways, lab results, and metabolic processes, (v) an assistant called search engine which is a high-precision engine that crawls local medical databases for cited evidence, arbitrary user requests or images (of pathologies, US, MRI and CT scans, etc.).

The traditional approach also requires a reviewer agent to assess overall quality and correctness. We decided not to add it. Instead, we chose to implement a stand-alone “devil’s advocate” architecture with a dedicated explicit adversarial approach based on a critic agent. When compared to the current architecture, in most of the practical cases in would confirm the findings of the presently described search engine, although occasionally it would provide valuable insights and alternatives. As a result, it was decided that the current architecture should be used as the primary research tool, while the adversarial critic agent architecture could be used for its verification.

In principle, an automated orchestrator agent could be also added (with the inevitable speed and representativity loss under the current budget). However, we ensure that the role of the supervisor agent rests with the end user, in order to prioritize and frame the agents’ behaviours as his or her tasks require. Because, normally, the scientific information search is not restricted to a single query, but requires a long history of queries, whose topics can change and are dictated by the user’s personal way of thinking, imposing rigid automated orchestration rules is inadvisable. In order to remember a sufficiently long history of queries and answers, an appropriate memory mechanism was implemented. We also designed the first four system prompts so as to allow for some overlap between the corresponding LLM answers, in order to enable the user to verify them and immediately spot discrepancies or hallucinations (if any) and take the corrective measures when required.

All system prompts were compiled so as to provide emotionally neutral, dry scientific style answers, and strictly to the point of the subject matter. As opposed to some of its main stream counterparts, the LLM was prohibited to adopt an empathetic tone, flatter or patronize the user by means of self-confident answers. It was prompted to be strictly precise and concise, in order to spare the system memory, on the one hand, and, since our “orchestrator agent” is supposed to be a human, not to emotionally influence the user’s decision making process, on the other.

The system prompts also require the LLM to provide a short summary of the first query which, normally, contains the most important information such as a disease description. The purpose of this exercise is to explicitly verify that the LLM has rendered the query correctly and did not start hallucinating from the very outset, in which case the memory must be cleared or the query reformulated. Although it was highly unlikely that hallucinations would occur for an English language query, they might take place for a different language query, since medical vocabulary is exceptionally difficult to translate for either a built in LLM translator or stand-alone dedicated translation LLMs. We have examined quite a few such translator LLMs available both online and offline, with none being hundred per cent satisfactory. Because the bulk of our RAG monographs are in English, we had to simultaneously employ two translational LLMs, in order to at least partially alleviate the translational problems.

There are two practical sides to this issue. The first, is that it prompts the user to learn international medical terminology which is not much different from Latin and not that difficult to memorize even for an applied mathematician.

The second one, is that it is advisable to adhere to simple every day native language, where possible, in order for the translation to be more accurate. Since the LLM will attempt to provide a translation of the query in professional medical English not only in terms of terminology, but also the correct word order and style of medical writing, there is no reason to heavily use native medical vocabulary, where it can be avoided.

Even when compiling, say, a symptoms query in English, the descriptions made in simple words often give better search results than those in professional medical language. Presumably, the use of professional terminology in the query (e.g., for disease) makes the LLM look for exact keyword matches with the provided terms, filtering out some of the other valuable information.

This was one of the reasons that urged us to make LLM always reformulate the original query in simple words and use it in a separate search as a supplement to the search based on the original user’s query.

This technique also forms the basis of the three-stage reranking framework we employed. It was borrowed from the literature and is as follows.

1. Instead of processing a single prompt in our database, we supply two distinct prompts — 1. the original user prompt and 2. its reformulated version (for instance, which expands symptoms and medical terminology in the case of disease description).

2. FAISS scans the vector space and pulls back X chunks from the original prompt and Y from the reformulated version.

3. Next, instead of using a separate, external neural network (like BGE-Reranker) which would eat up the 4GB VRAM, we are using the local LLM itself to do the synthesis and re-prioritization. If a specific monograph chunk is so relevant that it appears in both the top X of the original prompt and the top Y of the reformulated prompt, its structural relevance doubles. By feeding the raw coincidences into the local LLM, we are asking the model to read, filter out duplicate information, discard the noise, and synthesize a single coherent answer.

As a result, we intentionally bypass a dedicated cross-encoder reranker to save VRAM. Instead, we use a two-pronged ultra-fast semantic probe via FAISS, using query reformulation to catch cross-disciplinary links, and leave the final filtering to the local LLM during the synthesis phase. This keeps the memory footprint low while maximizing search coverage.

4.0 Image Processing Techniques

Modern medical monographs often contain excellent illustrations of various pathologies supplied with enlightening explanatory captions. However, illustrations are completely missed by a purely linguistic LLM, making the related AI assistant rather unsatisfactory from the end user’s view point, since a considerable volume of valuable knowledge becomes simply thrown away.

If budget limitations were not a factor, a natural solution would be to employ a multimodal neural network unifying a text encoder with a transformer architecture to process words and sentences, a vision encoder with convolutional networks or vision transformers to scan pictures, and a fusion layer to draw conclusions from mixed media.

A more economical approach had to be adopted in the present case. Very broadly, we use PyMuPDF (fitz) to locate an image in the database documents, determine the image attributes and use them to find the related captions. If the caption contains relevant information, the image is printed out. Of course, there is a long list of special filters to process adverse situations where, for instance, a text document has an image format, or an image occupies more than one page, a caption is not in the same page as an image, and a lot more. Finally, several most appropriate images, the related captions, page numbers and book titles are presented in each image window. To facilitate image search and to make sure that a correct image was spotted, cross-correlations of the user query with the surrounding pages containing the image description are also checked. This technique was found to give reasonably good results for MRI or CT scans and photos of pathologies.

A simplified, but robust, DICOM image viewer was written in Python - javascript combination and integrated into the front end. It displays the three orthogonal planes (axial, coronal, and sagittal) with linked crosshairs and a paging mechanism for scrolling through each image stack.

To enable the user to make comparisons of diagnostic images displayed in the viewer with the related images found in the literature database, the viewer window was placed alongside with the image search window.

An attempt was made to display three-dimensional DICOM images processed by the viewer. However, it was found that at least under the present budget restrictions the resulting tool for manipulating 3D images built upon the combination of Python and javascript was too slow to be practical. A proper professional C++ image viewer is required for this purpose.

Owing to its exceptional practical importance, it is planned to separate and further refine image retrieval and DICOM manipulation software into a standalone tool in the future.

Owing to its exceptional practical importance, it is planned to separate and further refine image retrieval and DICOM manipulation software into a standalone tool in the future.

To verify the performance of the described algorithms, a mobile interface for the MedAI Assistant system was developed and deployed on a local server (see Figure 1).

The application interface is divided into two functional areas:

1. Left Panel (Inference & Agent Selection): Contains a mandatory medical disclaimer and a system status logging console (the screenshot displays a successful initialization of the biochemical_persona and a cleared VRAM state). The bottom of this panel features rapid-toggle buttons to switch between isolated agentic modules (Medical, Pharm 1, Pharm 2, Biochem, and Search Engine). When the Biochem persona is activated, the system switches context to analyze molecular pathways, metabolic processes, and laboratory tests.
2. Right Panel (Medical Record & DICOM Workspace): Features a structured, interactive medical history template ranging from general patient data to family anamnesis. Section IX (Radiological/Imaging Tests) includes a native image integration module linked to a local directory (Local DICOM Workspace Folder), complete with UI controls to load or purge the image stack.

5.0 Evaluation, Real-World Use Cases, and Conclusions

An issue of testing this architecture has remained uncovered so far. One might naturally ask how well this localized system performs against standard medical examination questions. However, multiple-choice board exams are an invalid evaluation framework for the current architecture. Indeed, because the RAG database natively includes comprehensive board-preparation textbooks, the system would often simply find the relevant citation for the corresponding test question, rather than demonstrate generalized synthesis. On top of this data contamination: aspect, this evaluation scenario suffers from the scope alignment problem: the system is not designed to act as a licensed clinician, and none of its system prompts assume this role.

Because this is a strict information retrieval system, its primary performance metric is deterministic auditability. The user can instantly validate any model assertion by requesting an exact citation with the name of the author, monograph title, and the page number for its underlying source material, in order to directly verify the relevance of the answer.

System Sanity Checks and Personal Validation

An instructive and convincing way to conduct authentic stress-testing outside of contaminated benchmarks is to use historical, longitudinal clinical data. With this in mind, I fed the system anonymized, multi-decade clinical test results and symptom descriptions from medical cases collected over my lifetime. Since their outcomes were known to me exactly, this retrospective evaluation served as an excellent sanity check. The architecture consistently synthesized accurate insights, identified cross-disciplinary systemic interactions, and surfaced personally valuable health information that had gone unnoticed during the original consultations years prior.

Case Study: Domain Acceleration in Angiography Software Engineering

The utility of the proposed information retrieval tool extends far beyond clinical research. It acts as an efficient domain-immersion engine for other technical specialists.

Recently I had to engineer a digital angiography imaging software project in the absence of either proper technical specification documents, or access to a senior interventional radiologist. Traditional web searches and high-level regulatory medical documents provided only superficial introductory context.

The breakthrough in understanding of the problem domain, the ways of thinking of its top professionals and their methods came from leveraging this RAG architecture with its world-class monographs on radiology. By using the image-retrieval pipeline to match target angiographic scan patterns with their underlying text descriptions, the system instantly isolated the single most relevant book in global literature. I then restricted the agent’s focus to that specific monograph to effectively extract the precise domain logic, clinical workflows and other information necessary to build the software application.

Conclusion

The described architecture demonstrates the possibility of building a full-featured industrial-grade medical knowledge retrieval system under the extreme constraints of a standard consumer laptop operating fully offline. By trading the absolute relevance of articles for the consolidated structural stability of top-level monographs, this system successfully bridges the gap between vast medical literature databases and local computing frontiers. It serves as an accessible semantic research accelerator for frontline physicians, biomedical engineers, and interdisciplinary researchers alike.

«Камень, который отвергли строители, тот самый сделался главою угла».> — От Матфея 21:42

⚠️ Юридический дисклеймер

Важно для читателей и регуляторов:

1. Статус проекта: Описанная в статье система является исключительно личным pet-проектом (Proof of Concept) автора, созданным в научно-исследовательских и учебных целях. Проект развернут локально, не имеет публичного веб-интерфейса или API, не монетизируется и не распространяется.
2. Медицинское регулирование: Данное ПО не является медицинским изделием в понимании ст. 38 ФЗ № 323 «Об основах охраны здоровья граждан в РФ», не предназначено для постановки диагнозов, назначения лечения или автоматизации клинических решений. Автор не оказывает медицинских услуг.
3. Персональные данные: Система не собирает, не хранит и не обрабатывает персональные данные реальных пациентов (в рамках ФЗ № 152 «О персональных данных»). Все примеры промптов и логов в статье являются полностью вымышленными и синтетическими.
4. Авторские права: Описанный в статье массив документов (2500 монографий и статей) используется исключительно локально для индексации в личных научно-образовательных целях (согласно ст. 1273 ГК РФ). Исходные тексты книг, защищенные авторским правом, не публикуются, не распространяются и не выкладываются в открытый доступ. Все упоминания архитектуры приводятся в академических целях.

Краткое содержание

В статье описывается архитектура автономной (внесетевой) полностью локальной системы поиска информации, предназначенной для анализа глобальной медицинской литературы на общедоступных серийных вычислительных устройствах в условиях жестких ограничений по объему памяти. Используя базу данных из примерно 2500 современных тщательно отобранных монографий и ресурсоэффективную агентную структуру, система преодолевает разрыв между обширными базами данных медицинских публикаций и возможностями работующего локально типового серийного оборудования, сохраняя при этом абсолютную конфиденциальность данных и детерминированную проверяемость результатов поиска. Система облегчает извлечение научных знаний из литературы в области лечебного дела, клинической фармакологии и биохимии. Она также предоставляет механизм поиска изображений медицинских патологий по их словесным описаниям и средства визуализации инструментальных медицинских исследований в формате DICOM. Предлагаемый ИИ асистент служит доступным ускорителем семантических исследований для практикующих врачей, биомедицинских инженеров и междисциплинарных специалистов.

1.0 Введение: Мотивация для разработки ИИ-помощника в лечебном деле — личная, стратегическая и иная

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

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

Для успешного решения этой задачи необходимо оценить значительный объем медицинской литературы, запомнить большое количество сложных данных, сопоставить их с клиническими записями и результатами лабораторных исследований. Если человек не является высококвалифицированным, опытным медицинским работником с исключительной памятью, это становится практически невыполнимой задачей. Однако, именно здесь системы генерации информации с расширенным поиском (RAG) на основе искусственного интеллекта оказываются незаменимыми помощьниками.

Приведенные выше наблюдения стали для меня основной мотивацией для разработки медицинских ИИ-помощников, в том числе ещё и потому, что десятилетия работы прикладным математиком в области биомедицины позволили мне накопить значительный объем соответствующей современной литературы.

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

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

«Камень, который отвергли строители»: собираем автономную медицинскую поисковую систему на серийном железе

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

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

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

В идеале хотелось бы иметь такую систему прямо на мобильном телефоне, поскольку эти устройства стали неотъемлемой частью нашей жизни и используются повсеместно (см. Рисунок 1).

Однако простые расчеты распределения ресурсов показывают, что для такого развертывания неизбежно потребуется флагманское устройство верхнего ценового сегмента. В связи с этим в качестве базового целевого оборудования был выбран стандартный офисный ноутбук (с 16 ГБ оперативной памяти) со следующими ключевыми инженерными метриками:

• Целевая аппаратная подложка: оптимизировано специально под Ubuntu Linux с фиксированным бюджетом в 4 ГБ VRAM (видеопамяти) и 16 ГБ системной RAM (оперативной памяти).
• Вектор изоляции данных: изолированный контур обработки данных работает полностью автономно (офлайн), защищая проприетарные веса моделей и предотвращая несанкционированный удаленный сбор данных.

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

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

2.0 Архитектура базы данных с расширенным поиском и генерацией (RAG)

Обычно медицинская база данных RAG имеет приоритетную трехуровневую архитектуру, состоящую из (i) операционного уровня, основанного на клинических протоколах, которые определяют пошаговые диагностические алгоритмы на основе симптомов, (ii) уровня безопасности и законодательства, который обеспечивает меры безопасности и правовые гарантии, и (iii) пояснительного уровня, основанного на медицинской литературе. Первые два уровня обычно считаются наиболее важными, прежде всего потому, что они определяют, что местный врач должен делать в соответствии с законом и базовыми операционными нормами.

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

Поэтому медицинские нормативные документы и рекомендации будут полностью исключены из нашей базы данных. Также будут исключены клинические протоколы, предназначенные для жесткого пошагового исполнения. Причиной этого является наличии глубокого системного разрыва между статистической медициной и индивидуальной биологией человека. Мы не хотим искажать результаты поиска RAG при анализе конкретных личных случаев, навязывая усредненные статистические данные, полученные для человеческой популяции в целом и заложенные в стандартных протоколах, поскольку существует ненулевая математическая вероятность, что это приведет к ошибке. Кроме того, в среднем требуется от 10 до 17 лет, чтобы прорывное открытие, опубликованное в рецензируемой медицинской литературе, было интегрировано в официально утвержденный клинический протокол (см. оригинальное знаковое исследование Баласа, Э. А., и Борена, С. А. 2000. Управление клиническими знаниями для улучшения здравоохранения. Ежегодник медицинской информатики, 09(01), 65–70. https://doi.org/10.1055/s-0038-1637943). Если у речь идёт о сложном или быстро развивающемся заболевании, стандартные протоколы, по определению, основаны на устаревших научных данных.

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

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

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

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

Жесткие ограничения по памяти системы (дефицит видеопамяти в 4 ГБ) требуют небольшого контекстного окна. Это заставляет использовать автономные текстовые фрагменты с высокой плотностью информации, характерные для качественной монографической литературы. Такой подход противоположен сценарию, когда большой языковой модели (LLM) приходится “проглатывать” научную статью целиком ради поиска нужного контекста, что неизбежно переполнит небольшое контекстное окно локальной модели с 4-битным квантованием.

Наш опыт показывает, что тщательного отбора около 2500 фундаментальных монографий (примерно 1,5 миллиона страниц), охватывающих все направления современной медицины, достаточно для создания надежной информационно-поисковой системы, способной обрабатывать полученную базу данных за приемлемое время. Помимо медицинской литературы, мы считаем необходимым дополнить базу RAG монографиями по фундаментальной биологии в области вирусологии, генетике и биохимии (в дополнение к медицинской биохимии), поскольку эти расширения существенно повышают качество поиска. Включение биохимии оказалось абсолютно необходимым условием для корректного анализа веществ и лекарственных препаратов — по всей видимости, из-за стремительного прогресса в фармакологии.

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

3.0 Агентная архитектура, системные промты и механизм переранжирования

Жесткие ограничения по объему памяти не позволяют использовать полноценную мультиагентную систему с несколькими специализированными агентами в качестве независимых ИИ-единиц и оркестратором в роли управляющего. Поэтому пришлось применить следующий подход.

Вводятся несколько независимых агентных модулей, каждый из которых имеет собственный специализированный системный промт (инструкцию):(i) медицинский ассистент, специализирующийся на поиске клинической информации;(ii) ассистент pharm1, специализирующийся на межлекарственных взаимодействиях, дозировках и фармацевтических классификациях;(iii) ассистент pharm2, ориентированный на углубленные исследования лекарственных средств, включая фармакокинетику и клинические испытания;(iv) ассистент biochem, анализирующий молекулярные взаимодействия, результаты лабораторных анализов и метаболические процессы; (v) ассистент search engine (поисковый движок) — высокоточный модуль, выполняющий поиск в локальных медицинских базах данных для извлечения цитируемых доказательств, ответов на произвольные пользовательские запросы или изображений по тексовым описаниям (патологий, снимков УЗИ, МРТ, КТ и т. д.).

Упомянутый в начале данного раздела традиционный подход также требует наличия агента-рецензента для оценки общего качества и корректности ответов. Мы решили отказаться от его добавления. Вместо этого было решено создать автономную архитектуру «адвоката дьявола» с выраженным состязательным подходом на основе агента-критика. В большинстве практических сценариев сравнение с описываемой здесь основной архитектурой показывает, что данный состязательный агент обычно подтверждает выводы описываемого поискового движка, однако в некоторых случаях он предлагает ценные инсайты и альтернативные варианты. В итоге было решено использовать базовую архитектуру в качестве основного инструмента исследования, а состязательную архитектуру агента-критика — для верификации результатов.

В принципе, в систему можно было бы добавить и автоматического агента-оркестратора (что при текущем бюджете памяти неизбежно привело бы к потере скорости и репрезентативности выходных данных). Однако мы закрепили роль супервизора за конечным пользователем, чтобы расставлять приоритеты и адаптировать поведение агентов под конкретные задачи пользователя. Поскольку в штатном режиме поиск научной информации не ограничивается одним запросом, а требует долгой истории диалога, темы которого могут меняться под влиянием индивидуального мышления пользователя, навязывание жестких автоматических правил оркестровки нецелесообразно. Для сохранения достаточно длительной истории запросов и ответов был реализован соответствующий механизм памяти. Кроме того, мы спроектировали первые четыре системных промта таким образом, чтобы допускать частичное пересечение соответствующих ответов LLM. Это позволяет пользователю верифицировать их, мгновенно замечать расхождения или галлюцинации (если таковые имеются) и при необходимости принимать корректирующие меры.

Все системные промты были составлены так, чтобы обеспечивать эмоционально нейтральные ответы в сухом научном стиле строго по существу вопроса. В отличие от некоторых мейнстримных аналогов, языковой модели было запрещено использовать эмпатичный тон, льстить пользователю или общаться в покровительственной манере с позиции непогрешимого эксперта. Модели предписывалось быть предельно точной и лаконичной, чтобы, с одной стороны, экономить системную память, а с другой — не оказывать эмоционального влияния на процесс принятия решений пользователем, поскольку роль нашего «агента-оркестратора» отведена человеку.

Разработанные системные промты также требуют от LLM предоставлять краткую аннотацию первого запроса, который обычно содержит наиболее важную информацию, например, описание заболевания. Цель этого — явно убедиться в том, что модель правильно интерпретировала запрос и не начала галлюцинировать уже с самого первого шага (в противном случае необходимо очистить память, либо переформулировать запрос). Хотя возникновение галлюцинаций при запросах на английском языке крайне маловероятно, они могут происходить при работе с другими языками, поскольку медицинская лексика исключительно сложна для перевода как встроенными трансляторами LLM, так и специализированными отдельными моделями-переводчиками. Мы изучили довольно много таких переводческих моделей, доступных как онлайн, так и офлайн, и ни одна из них не оказалась удовлетворительной на сто процентов. Поскольку основная масса монографий в нашей базе RAG написана на английском языке, нам пришлось одновременно задействовать две переводческие LLM, чтобы хотя бы частично сгладить проблемы перевода.

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

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

Даже при составлении, к примеру, запроса по симптомам на английском языке, описания, сделанные простыми словами, зачастую дают лучшие результаты поиска, чем на профессиональном медицинском языке. По всей видимости, использование профессиональной терминологии в запросе (например, названия болезни) заставляет модель искать точные совпадения по специализированным ключевым словам, отсеивая другую ценную информацию.

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

Данный метод также лег в основу применяемой нами трехэтапной структуры переранжирования (reranking). Она была заимствована из профильной литературы и выглядит следующим образом:

1. Вместо обработки одного промта в нашей базе данных мы передаем два разных промта: 1. исходный промт пользователя и 2. его переформулированную версию (которая, к примеру, детализирует симптомы и раскрывает медицинскую терминологию в случае описания болезни).

2. Библиотека FAISS сканирует векторное пространство и извлекает X фрагментов текста (чанков) по исходному промту и Y фрагментов по переформулированному.

3. Далее, вместо использования отдельной внешней нейросети (такой как BGE-Reranker), которая поглотила бы доступные 4 ГБ видеопамяти (VRAM), мы задействуем саму локальную LLM для синтеза и переопределения приоритетов. Если конкретный текстовый фрагмент из монографии настолько релевантен, что попадает одновременно в топ-X исходного промта и в топ-Y переформулированного, его структурная значимость удваивается. Передавая эти явные совпадения в локальную LLM, мы просим модель проанализировать их, отфильтровать дублирующую информацию, отсеять шум и синтезировать единый связный ответ.

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

4.0 Методы обработки изображений

Современные медицинские монографии часто содержат высококачественные иллюстрации различных патологий, снабженные информативными пояснительными подписями. Однако чисто текстовые (лингвистические) LLM полностью игнорируют иллюстрации. С точки зрения конечного пользователя, это делает основанного на них ИИ-ассистента довольно неэффективным, поскольку огромный объем ценных знаний попросту выбрасывается.

В отсутствии жестких бюджетных ограничений, естественным решением было бы использование мультимодальной нейросети. Она объединяла бы текстовый кодировщик (текстовый энкодер) с архитектурой Transformer для обработки слов и предложений, визуальный кодировщик (вижн-энкодер) на базе сверточных сетей или Vision Transformers для сканирования изображений, а также слой слияния данных (fusion layer) для формулирования выводов на основе смешанных типов данных.

В данном проекте пришлось применить более экономичный подход. Если говорить в общих чертах, мы используем библиотеку PyMuPDF (fitz) для локализации изображения в документах базы данных, определения его атрибутов и последующего поиска связанных с ним подписей. Если подпись содержит релевантную информацию, изображение выводится на экран. Разумеется, существует длинный список специальных фильтров для обработки неблагоприятных сценариев — например, когда какой-либо текстовый документ представлен в формате изображения, картинка занимает более одной страницы, подпись находится не на той странице, что и само изображение, и многих других сложных ситуаций. В итоге в каждом окне вывода отображается несколько наиболее подходящих изображений, связанные с ними подписи, номера страниц и названия книг. Чтобы облегчить поиск изображений и убедиться в правильности выбора, также проверяется кросс-корреляция поискового запроса пользователя с окружающими страницами, содержащими описание данного изображения. Оказалось, что этот метод дает достаточно хорошие результаты для снимков МРТ, КТ и фотографий патологий.

На базе связки Python и JavaScript также был написан упрощенный, но надежный модуль просмотра изображений DICOM (DICOM-вьюер), интегрированный во фронтенд. Он отображает три ортогональные плоскости (аксиальную, корональную и сагиттальную) со связанным перекрестием и механизмом прокрутки фреймов для перемещения по стеку изображений.

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

Была предпринята попытка отображать трехмерные (3D) DICOM-изображения, наряду с их проекциями, обрабатываемые вьюером. Однако выяснилось, что — по крайней мере, в рамках текущих ограничений по ресурсам — созданный инструмент для манипулирования 3D-изображениями на базе Python и JavaScript работает слишком медленно для практического использования. Для этих целей необходим полноценный профессиональный вьюер на C++.

Ввиду исключительной практической значимости в будущем планируется выделить ПО для поиска изображений и работы с DICOM в отдельный самостоятельный инструмент и продолжить его совершенствование на основе С++ библиотек.

Для проверки работоспособности описанных алгоритмов был разработан мобильный интерфейс системы MedAI Assistant, запущенный на локальном сервере (см. Рисунок 1).

Экран приложения разделен на две функциональные зоны:

1. Левая панель (Инференс и выбор агентов): Содержит обязательный медицинский дисклеймер и область логирования статуса системы (на скриншоте виден успешный запуск biochemical_persona и очистка VRAM). В нижней части панели расположены кнопки быстрого переключения между независимыми агентными модулями (Medical, Pharm 1, Pharm 2, Biochem, Search Engine). При активации режима Biochem система переходит в режим анализа молекулярных путей, метаболических процессов и лабораторных тестов.

2. Правая панель (Медицинская карта и DICOM-пространство): Представляет собой структурированный интерактивный шаблон истории болезни (от общих данных до семейного анамнеза). Раздел IX (Radiological/Imaging Tests) содержит модуль интеграции с локальной папкой рабочих снимков (Local DICOM Workspace Folder) с кнопками загрузки и очистки стека для последующего дискового анализа.

5.0 Оценка работоспособности системы, реальные сценарии использования и выводы

До сих пор осталась неосвященной проблема тестирования данной архитектуры. Может возникнуть на первый взгляд вполне закономерный вопрос: насколько хорошо эта локальнная система справляется со стандартными заданиями медицинских экзаменов?

К сожалению, экзаменационные тесты с множественным выбором (board exams) являются невалидной средой оценки для текущей архитектуры. Дело в том, что база данных RAG изначально включает в себя исчерпывающие учебники для подготовки к этим самым экзаменам, поэтому система зачастую просто находила бы точную цитату для конкретного тестового вопроса вместо того, чтобы демонстрировать способность к обобщению и синтезу знаний. Помимо отмеченного аспекта загрязнения данных (data contamination), этот сценарий оценки страдает от проблемы несоответствия ролей (scope alignment): система не предназначена для работы в качестве лицензированного клинициста, и ни один из ее системных промтов не предполагает эту роль.

Поскольку речь идет о строгой информационно-поисковой системе, ее главным показателем эффективности является детерминированная проверяемость (deterministic auditability). Пользователь может мгновенно подтвердить утверждение модели, запросив точную цитату с указанием автора, названия монографии и номера страницы первоисточника, чтобы напрямую убедиться в релевантности ответа.

Проверка работоспособности системы и личная валидация

Наглядным и убедительным способом проведения подлинного стресс-тестирования вне «загрязненных» бенчмарков является использование исторических, лонгитюдных клинических данных. Имея это в виду, я загрузил в систему деперсонализированные результаты клинических анализов и описания симптомов из медицинских карт, собранных на протяжении своей жизни. Поскольку исходы болезней и лечения были мне точно известны, эта ретроспективная оценка послужила отличной проверкой работоспособности (sanity check). Архитектура стабильно синтезировала точные аналитические выводы, выявляла междисциплинарные системные взаимодействия и подсвечивала ценную для меня информацию о здоровье, которая осталась незамеченной в прошлом во время первоначальных консультаций.

Практический пример: Ускорение погружения в предметную область при разработке ПО для ангиографии

Полезность предложенного инструмента поиска информации выходит далеко за рамки клинических исследований. Система работает как эффективный движок для быстрого погружения в предметную область (domain immersion) для технических специалистов из других областей.

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

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

Заключение

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