Advanced physics is difficult not only because of the mathematics. It is difficult because knowledge is distributed across textbooks, research papers, lecture notes, simulations, old exercises, and partially remembered ideas. A learner may understand a derivation today and forget the assumptions behind it six months later. A concept learned in plasma physics may reappear in statistical mechanics under a different vocabulary.
Large language models can help by creating a course adapted to the learner and by managing a growing scientific knowledge base. But this requires more than a chatbot connected to a folder of PDFs. The system needs a database that can store structured knowledge, semantic representations, source references, concept relationships, exercises, and the learner’s progress. It must also allow the LLM to act on that information safely.
The central design choice
For most personal or collaborative physics-learning systems, the best starting point is PostgreSQL with the pgvector extension.
PostgreSQL can store courses, lessons, exercises, documents, notes, citations, learner progress, and relationships between concepts. The pgvector extension adds vector similarity search, allowing the system to retrieve passages and concepts according to meaning rather than exact wording.
The LLM, however, should not receive unrestricted access to the database. It should operate through a controlled tool layer, ideally implemented as a small Model Context Protocol server, or MCP server.
LLM
│
│ typed MCP tool calls
▼
Knowledge service / MCP server
│
├── validation
├── permissions
├── provenance
├── versioning
├── embedding generation
└── audit logging
│
▼
PostgreSQL + pgvector
│
└── object storage for PDFs, notebooks and images
This separation is essential. The model does not “own” the database. It requests specific operations, while the application validates and executes them.
Why a conventional note application is not enough
A conventional note-taking system stores pages. A useful physics-learning system must store several different forms of knowledge at once:
- source documents and research papers;
- small retrievable passages from those documents;
- concepts, equations and definitions;
- assumptions and validity conditions;
- relationships between concepts;
- worked examples and simulations;
- courses, lessons and exercises;
- the learner’s mistakes and mastery level;
- citations and provenance;
- LLM-generated proposals that still require validation.
These objects are related, but they are not identical. A vector database alone is therefore insufficient. It can locate similar passages, but it is not naturally responsible for transactional updates, user permissions, course state, versions, or the difference between an imported source and an unverified model-generated claim.
What PostgreSQL contributes
PostgreSQL provides the structured foundation. A course module can refer to prerequisites. An exercise attempt can be linked to a concept. A note can cite a particular page of a paper. A learner-state record can contain several dimensions of mastery rather than a single score.
Its JSONB fields also make the schema flexible. Physics metadata varies considerably: a paper may include authors and publication dates, a simulation may include numerical parameters and a Git commit, while a derivation may include assumptions, notation, and a symbolic verification result.
PostgreSQL full-text search is valuable for exact scientific terms. This matters because physics questions often contain notation, equation names, author names, abbreviations, or precise phrases that semantic search may blur.
What pgvector contributes
pgvector stores numerical embeddings next to the rest of the application data. The system can then search for notes that are semantically related even when the terminology differs.
For example, a learner might ask:
Where in my notes did I encounter a mechanism similar to phase mixing?
The system could retrieve material on Landau damping, dephasing in coupled oscillators, filamentation in velocity space, and inviscid damping. The LLM could then explain their common structure while citing the retrieved notes.
Another query could combine semantic and structured restrictions:
Find material related to phase mixing, restrict it to plasma physics, exclude unverified LLM-generated notes, and prioritize concepts I have not reviewed for three months.
This is where PostgreSQL and pgvector work particularly well together. The vector search identifies conceptual similarity, while ordinary SQL applies subject, date, ownership, status, and reliability filters.
The LLM should control tools, not SQL
It may appear convenient to give the model a generic execute_sql tool. That would be a poor design.
An unrestricted model could produce an incorrect update, modify too many records, expose data belonging to another user, or follow a malicious instruction embedded in a retrieved document. Even an innocent error in a generated query could damage the integrity of the knowledge base.
The safer approach is to expose narrow, domain-specific operations:
search_knowledge get_concept get_prerequisites create_note update_note propose_concept_relation record_exercise_attempt update_mastery create_course_module get_review_queue archive_note
These tools can be described using JSON schemas. The LLM chooses a tool and supplies arguments, but the server remains responsible for authorization, validation, deduplication, version control, and audit logging.
A practical example: proposing a scientific relationship
Suppose the learner has notes on Landau damping and phase mixing. The LLM identifies a relationship and sends the following request:
{
"tool": "propose_concept_relation",
"arguments": {
"source": "Landau damping",
"target": "phase mixing",
"relation_type": "EXAMPLE_OF",
"explanation": "Macroscopic damping emerges from dephasing in velocity space.",
"source_note_ids": ["note-183", "paper-42"]
}
}The MCP server should not simply insert this claim as established knowledge. It can first verify that both concepts exist, check whether the relation is duplicated, validate the relation type, confirm that the cited sources belong to the user, and store the proposal with a status such as llm_generated or pending_validation.
The learner can then approve, reject, or edit it. This preserves the model’s usefulness without confusing generated interpretation with validated scientific knowledge.
A useful database model
A first implementation does not require hundreds of tables. The following structure is sufficient for a serious prototype.
documents
id
title
source_type
author
publication_date
storage_location
reliability
metadata JSONB
document_chunks
id
document_id
content
section
page_number
embedding VECTOR
search_vector TSVECTOR
concepts
id
name
definition
subject
difficulty
status
embedding VECTOR
concept_relations
source_concept_id
target_concept_id
relation_type
explanation
confidence
created_by
validation_status
notes
id
concept_id
content
source_ids
version
created_by
metadata JSONB
courses
course_modules
lessons
exercises
exercise_attempts
learner_state
user_id
concept_id
recognition_score
explanation_score
derivation_score
application_score
last_reviewed_at
review_queue
audit_log
The concept-relation table can initially represent a knowledge graph without requiring a separate graph database. Useful relation types include:
REQUIRES DERIVED_FROM APPROXIMATION_OF VALID_WHEN CONTRADICTS ANALOGOUS_TO MEASURED_BY SOLVED_USING EXAMPLE_OF
How the database supports a tailored course
The database should not merely answer questions. It should help the LLM decide what the learner should study next.
Consider a learner trying to understand gyrokinetics. The system can inspect the concept graph and identify prerequisites such as guiding-centre motion, magnetic moments, distribution functions, asymptotic ordering, the Vlasov equation, and anisotropic turbulence.
It can compare this dependency graph with the learner-state table. If the learner can explain the Vlasov equation but has repeatedly failed exercises involving ordering assumptions, the LLM can generate a short bridge module on asymptotic reasoning rather than repeating an entire plasma-physics course.
A lesson can then be assembled from several layers:
- a conceptual explanation;
- a mathematical derivation;
- a worked example;
- a simulation or notebook;
- a diagnostic exercise;
- a retrieval question from previous material;
- links to the learner’s own notes and source documents.
The learner’s response is stored as an exercise attempt. The LLM can classify the error, but the original response should remain available. This makes it possible to distinguish a temporary algebraic mistake from a recurring conceptual misconception.
Mastery should be multidimensional
A single progress percentage is misleading in advanced physics. Recognizing a concept is not the same as deriving it or applying it to a new problem.
The learner-state model should therefore separate several abilities:
- Recognition: Can the learner identify the concept?
- Explanation: Can the learner explain it without assistance?
- Derivation: Can the learner reproduce the mathematical argument?
- Application: Can the learner solve a new problem?
- Validity: Can the learner recognize when the model does not apply?
The LLM can use these dimensions when planning the next lesson. Someone may have high recognition and low derivation scores, indicating that more reading would probably create only an illusion of progress. The system should instead request closed-book derivations or unfamiliar exercises.
Hybrid retrieval is essential for physics
Scientific search should combine several methods. Pure vector search is good at conceptual similarity but can be weak when exact symbols, equations, abbreviations, or author names matter. Pure keyword search has the opposite weakness.
A robust retrieval process can therefore follow this sequence:
- Interpret the learner’s question.
- Apply metadata and permission filters.
- Run PostgreSQL full-text search.
- Run pgvector semantic search.
- Merge and rerank the results.
- Retrieve neighbouring chunks and source information.
- Generate an answer grounded in the retrieved material.
- Return citations to the learner.
For example, a query containing the exact form of a dispersion relation should benefit from lexical search, while a query asking for “other mechanisms where a reversible microscopic system produces an apparently damped macroscopic signal” benefits strongly from semantic retrieval.
Should a graph database such as Neo4j be added?
Neo4j becomes attractive when graph traversal itself is a central product feature. Examples include:
Which missing prerequisites prevent me from understanding gyrokinetics, considering dependencies up to four levels deep?
Find the shortest conceptual path connecting Hamiltonian mechanics to quantum field theory.
These are natural graph queries. Neo4j also supports graph visualization and algorithms that may later help identify central concepts, disconnected areas, or alternative learning paths.
It is nevertheless better not to introduce PostgreSQL, pgvector, and Neo4j simultaneously in the first version. Concept relationships can initially be stored in a PostgreSQL table. A graph database should be added only when complex traversal, visualization, or graph algorithms become important enough to justify synchronizing two systems.
When Qdrant becomes useful
Qdrant is a strong option when semantic retrieval becomes a large, specialized workload. It supports vector search, metadata filtering, and hybrid dense-and-sparse retrieval.
For a personal knowledge base or a small learning platform, however, PostgreSQL with pgvector is usually simpler. It avoids maintaining synchronization between a relational database and a separate vector store. Qdrant can be introduced later if the number of vectors, query volume, latency requirements, or retrieval experiments exceed what is comfortable in the primary database.
Provenance is as important as retrieval
Every stored item should indicate where it came from. A simple field can distinguish:
created_by = user | imported_source | llm
A separate validation status can indicate:
draft llm_generated source_extracted user_validated expert_validated deprecated
This distinction prevents a fluent model-generated synthesis from being confused with a statement extracted from a textbook or checked by an expert. It also allows the interface to display confidence and provenance visibly.
Validated notes should be versioned rather than silently overwritten. The LLM may propose a revision, but the previous text, source references, and validation state should remain recoverable.
A practical implementation stack
A realistic first implementation could use:
- PostgreSQL as the authoritative database;
- pgvector for embeddings and semantic retrieval;
- FastAPI for the application API;
- SQLAlchemy or SQLModel for database access;
- Alembic for schema migrations;
- the Python MCP SDK for LLM tools;
- Sentence Transformers or an embedding API;
- MinIO or another S3-compatible store for PDFs and notebooks;
- Jupyter notebooks for numerical demonstrations and verification.
The MCP server can be implemented as a thin layer around the same business services used by FastAPI. This avoids duplicating logic. The web interface, background ingestion pipeline, and LLM tools all call the same validated application functions.
A possible workflow
Imagine that a learner imports a paper on turbulence in magnetized plasmas.
- The document is stored in object storage.
- Its metadata is saved in PostgreSQL.
- The text is divided into meaningful chunks.
- Each chunk receives a full-text search vector and an embedding.
- The LLM extracts candidate concepts, equations, assumptions, and relationships.
- Those extractions are stored as proposals, not validated facts.
- The system compares the paper’s prerequisites with the learner’s current knowledge.
- It creates a short preparatory module for missing concepts.
- The learner completes exercises and explanations.
- The results update the learner-state model and future review queue.
Several weeks later, a new paper may rely on the same ordering assumption. The system can retrieve the old lesson, the learner’s previous mistake, and the original source. The knowledge base becomes useful not because it contains more text, but because it preserves continuity.
The key principle
The most important architectural principle is simple:
Use PostgreSQL with pgvector as the single source of truth, and let the LLM act through narrow, typed MCP tools rather than unrestricted database access.
This design provides semantic retrieval, exact scientific search, course management, learner tracking, provenance, permissions, and concept relationships without introducing unnecessary complexity too early.
The LLM can then do what it does best: connect explanations, generate exercises, propose relationships, reorganize material, and adapt the learning path. The database and tool layer do what they do best: preserve structure, enforce rules, record sources, and prevent a persuasive answer from silently becoming scientific truth.