HyperMemory

Final memory-enhanced AI knowledge system combining RAG, Agent, Wiki, GBrain, and hyper memory.

Quick Start | Operations | Architecture | Production Gaps | Maintenance | Bot Integration | References

Architecture Framework

This image is an ImageGen-rendered visual architecture map. The Mermaid diagram and OpenAPI docs remain the exact engineering contract.

Position

HyperMemory is the final repository in the Campus QA family. It keeps the useful ideas from RAG, Agent, LLM Wiki, GBrain, and hyper memory in one runnable project while making the remaining production gaps explicit.

Repository	Role
Harzva/CampusRAG-QA	Baseline RAG + Wiki mode.
Harzva/CampusAgent-QA	Agent tools, Wiki memory, and GBrain skills.
Harzva/HyperMemory	Final memory-enhanced system.

What Changed In This Cleanup

Before	Now
Demo-like frontend title and layout	Product-specific workbench with real mode names.
Hardcoded Agent FAQ answers	Agent relies on retrieval tools for knowledge answers.
Wiki mode dumped stored pages first	Wiki mode queries the shared retrieval core first.
Duplicated interim/final memory layers	HyperMemory is the single conversation-memory aggregation layer.
Placeholder GBrain console examples	Deterministic inspection skills with structured names.
README described production as if finished	README and production review separate what is done from what remains.

Modes

Mode	Endpoint	Purpose
RAG	/api/chat	Direct grounded QA over retrieved chunks.
Agent	/api/agent/chat	Tool-using QA over the same retrieval core.
LLM Wiki	/api/wiki/chat	Wiki-style memory over retrieved chunks.
GBrain	/api/gbrain/chat	Skill layer over wiki memory.
Hyper	/api/hyper/chat	Final conversation-memory aggregation over wiki context.
Bot Gateway	/api/bot/{channel}/callback	Routes normalized Feishu, DingTalk, and WeChat messages.

Visual Walkthrough

Six README-owned screenshots show the runnable workbench across final memory modes, production readiness, and mobile layout.

Dashboard	Hyper mode	Agent mode

GBrain conversation	Production readiness	Mobile

Architecture

flowchart LR
    User["Browser"] --> UI["Vue 3 Workbench"]
    Bot["Feishu / DingTalk / WeChat"] --> Gateway["Bot Gateway"]
    UI --> API["Spring Boot API"]
    Gateway --> API
    API --> RAG["RAG Service"]
    API --> Agent["Agent Service"]
    API --> Wiki["Wiki Facade"]
    API --> GBrain["GBrain Service"]
    API --> Hyper["Hyper Memory"]
    RAG --> Retrieval["Retrieval Context Service"]
    Agent --> Retrieval
    Wiki --> Retrieval
    GBrain --> Wiki
    Hyper --> Wiki
    Retrieval --> Milvus[("Milvus vectors")]
    Retrieval --> MySQL[("MySQL chunks")]
    API --> MinIO[("MinIO files")]
    API --> Model["OpenAI-compatible models"]

Loading

Quick Start

cp .env.example .env
docker compose up -d --build

Open:

• Frontend: http://localhost:3000
• Backend health: http://localhost:8080/actuator/health
• MinIO console: http://localhost:9001

Set OPENAI_API_KEY in .env before expecting model-backed answers.

Repository Layout

backend/              Spring Boot API and memory services
frontend/             Vue 3 workbench
docs/assets/          README screenshots
docs/OPERATIONS.md    Runtime and endpoint notes
docs/PRODUCTION-ARCHITECTURE.md
docs/PRODUCTION-GAPS.md
docs/MAINTENANCE.md
docs/BOT-INTEGRATION.md
docs/SCREENSHOTS.md
docs/openapi/          API contract templates
deploy/k8s/            Kubernetes deployment template
docs/PRODUCTION-REVIEW.md
SECURITY.md            Security policy and secret-handling notes
docker-compose.yml    Full local runtime stack
.env.example          Runtime configuration template

Production Readiness

See Production Review and Production Gaps for the detailed audit. The largest remaining decisions are durable HyperMemory persistence, tenant isolation, Bot idempotency, and whether final retrieval should collapse to SQLite-only or keep the current MySQL/Milvus/MinIO stack.