cyber-doctor: a Gradio front end that wires LLMs, Neo4j and RAG into a medical agent

What problem cyber-doctor is trying to solve, and for whom

The README frames the project around uneven access to medical expertise: people in less developed regions travel to major cities for care, which costs time and money. The stated goal is a multi-modal model in the health domain that handles basic diagnosis, medical record analysis and professional question answering. The authors describe it as a summer training project at Southeast University, and they are explicit that the narrow reading of the project is a personal health assistant while the broad reading is a template that can be pointed at any domain by swapping the fine-tuned model and the retrieval sources. That second framing is the more honest one. Nothing in the repository suggests the medical knowledge is baked into the code; it arrives through a Neo4j graph and a file-based knowledge base that the operator supplies. The audience that fits is therefore not patients. It is developers and students who want a runnable Gradio application where the retrieval plumbing already exists and the domain content is a configuration decision. The README also states plainly that the team lacked the capacity to apply for and test multiple API providers, and asks for issues and pull requests to fix adapter bugs. That sentence tells you more about the project's maturity than any feature table.

How the pieces fit: Gradio, Langchain chains, a client factory and Neo4j

The repository layout is the clearest description of the architecture, since the README does not include a data flow diagram in text. app.py builds the Gradio interface and handles multi-modal input, and the README notes the ASR model and the interface itself can be customized there. Behind it sit several directories with distinct jobs. client/ holds the LLM abstraction: LLMclientbase.py defines a base class, LLMclientgeneric.py wraps the call that produces a completion, and clientfactory.py constructs the right client. Two concrete implementations are shipped, ourAPI/client.py and zhipuAPI/client.py, which is consistent with the README's claim that any endpoint speaking the OpenAI SDK works, plus Ollama's local API. Retrieval is split by source. Internet/ contains a three-part pipeline: Internet_prompt.py extracts search keywords, Internet_chain.py coordinates keyword extraction and crawling, and retrieve_Internet.py calls the search interface. audio/ handles the voice path, with audio_extract.py pulling the target text and language out of the model output and audio_generate.py wrapping edge-tts. Speech-to-text uses whisper per the tech stack list. The knowledge graph path is Neo4j with Cypher queries. What is not visible in the supplied material is how the agent decides which of these paths to invoke for a given message. The README describes an agent that judges task type and combines models, but the selection logic is not documented, so treat that as the first thing to read in the source if routing behaviour matters to you.

Getting it running: clone, .env, config-web.yaml, conda, app.py

The startup sequence in the README is short and uses real commands. Clone with git clone https://github.com/Warma10032/cyber-doctor.git, or the SSH form git clone git@github.com:Warma10032/cyber-doctor.git. Copy .env.example to .env and fill in the API configuration there; the README lists Zhipu AI, Doubao, SiliconFlow, DeepSeek and Qwen as OpenAI-SDK-compatible options, plus Ollama for a local API. Then edit config/config-web.yaml. The README does not enumerate the keys in that file, which is the largest documentation gap in the setup path: you will be reading the file and the source to learn what is configurable. Create the environment with conda create --name myenv python=3.10 and conda activate myenv, then pip install -r requirements.txt. Python 3.10 or newer is required. Launch with python app.py and open http://localhost:7860. The knowledge graph is optional and only needed for graph-augmented retrieval. It requires a Neo4j instance, community edition is sufficient per the README, and the credentials go into config/config-web.yaml. To load a graph, stop the service (neo4j stop on Windows, sudo neo4j stop on Linux), then run neo4j-admin database load <database-name> --from-path=/path/to/dump-folder/ --overwrite-destination=true. The README warns that --overwrite-destination replaces existing data. If the load reports the database is not on a supported version, run neo4j-admin database migrate, then start the service again. The recommended graph is the OpenKG household common disease dataset, which the project says it uses and which is said to work without changing the config file.

The feature list is wider than the medical use case

The function table covers image recognition for medical records and drug labels, video generation, image generation, PPT and Word generation, multi-turn conversation with history, retrieval-augmented chat over uploaded files, voice input and output with dialect support, knowledge graph augmentation, knowledge base augmentation, and web search augmentation. Several of these have nothing to do with health. Video generation and slide generation are general model capabilities exposed through the same chat box, which suggests the project is closer to a general agent scaffold with a medical configuration than to a medical product. That is not a defect in itself, and the README says as much when it describes the project as configurable for any domain. But it affects how you evaluate the claim of being a personal doctor. The medical value comes from the graph and the knowledge base, not from the code, and the code is what this repository actually ships. If you need a medical question answering system, the feature table should be read as a list of things the interface can call, not as a list of things that have been validated for clinical accuracy.

Where it breaks: API drift, graph loading, and the missing evaluation

The README's own admission that the team could not test multiple API providers is the most concrete failure mode. The OpenAI SDK is not perfectly uniform across vendors, and the clientfactory pattern means each deviation needs either a new client class or a patch to the generic one. Expect to debug the adapter layer before you debug anything medical. The Neo4j path has a second sharp edge. The load command demands a dump whose format matches your server version, and the README documents the migrate fallback precisely because this mismatch happens. The overwrite flag is destructive by default. A third constraint is environmental: the graph path needs a running Neo4j service, so a single-machine deployment is really two services, and the README gives separate Windows and Linux service commands rather than a container recipe, though it links to a Docker deployment article. The largest gap is evaluation. No releases were retrieved, and the material contains no accuracy figures, no test suite description and no benchmark for diagnosis or record analysis. For a project whose headline use case is medical, the absence of any measured answer quality is the thing that should slow a serious adopter down. Treat the output as a draft for a human to check, and treat the project as infrastructure rather than a diagnostic authority.

What a graph-augmented agent gives you that a plain RAG chatbot does not

The natural comparison is a straightforward retrieval-augmented chatbot built on Langchain and a vector store, which is what most projects in this space are. cyber-doctor includes that path, since the knowledge base feature accepts files in multiple formats, but it also exposes Neo4j and Cypher as a second retrieval source. The difference in approach is structural. A vector store retrieves passages that are textually similar to the query, which works well for prose documents such as guidelines or drug labels. A knowledge graph retrieves by traversing typed relationships, so a question about a disease, its symptoms and its treatments can be answered by following edges rather than by hoping the right paragraph was embedded. For medical content, where entities and relations are the point, that is a meaningful distinction, and it is why the project ships a specific OpenKG graph as its default. The cost is operational: you now maintain a database, a dump import process and Cypher queries, and the quality of answers depends on the graph you load. A team with no Neo4j experience should weigh whether the file-based knowledge base alone is enough for their use case before taking on the graph.

Licence, maintenance and what upgrading actually costs

The project is GPL-3.0. If you distribute a modified version or a product built on it, the copyleft terms apply to the combined work, so this is not a licence to drop into a closed-source commercial product without reading it carefully. That is a statement about the licence text, not legal advice. On maintenance, the material shows a last push in August 2026 and no retrieved releases, which means there is no versioned artifact to pin and no changelog to read before upgrading. Your upgrade path is git pull against main. Because the README documents .env and config/config-web.yaml as the two places operators make changes, a pull that touches either of those files or the client factory is the one to review before restarting. The dependency surface is also broad: PyTorch, Transformers, Gradio, Langchain, whisper and edge-tts, plus the Neo4j driver. Each of those moves independently, and Gradio in particular has changed its API across major versions, so a requirements.txt that is not pinned to compatible versions is a real risk when you rebuild the environment months later. Check whether the file pins versions before you rely on a reproducible install.

Editorial conclusion

Adopt cyber-doctor if you already run an OpenAI-compatible endpoint or Ollama and you want a working Gradio shell for graph-augmented medical question answering, and you accept that the README is the specification. Do not adopt it as a clinical tool or as a library to build on: there are no releases, no tests described, and no published evaluation of answer quality. Before committing, verify three things in the repository yourself: which config keys config/config-web.yaml actually reads, whether the clientfactory abstraction covers your provider without a patch, and whether the Neo4j dump you intend to load matches the format the neo4j-admin database load command expects.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. ZeroTang05/cyber-doctor on GitHub