尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證Production-oriented clinical RAG backend: hybrid retrieval, citation-grounded generation, abstention gates, multi-provider routing, and a 229-question evaluation suite.
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
A production-oriented clinical RAG backend for evidence-grounded Korean medicine decision support.
CureAgent turns 63 clinical-guideline PDFs into 7,154 searchable evidence chunks, retrieves and
reranks the most relevant passages, and streams answers with source-linked citations. Its safety
path is evaluated against 229 questions—including 44 deliberately unanswerable cases—and abstains
when the available evidence cannot support an answer. The system also includes multi-provider LLM
routing, production observability, and failure recovery.檢視完整 README ↗English · 한국어
A production-oriented clinical RAG backend for evidence-grounded Korean medicine decision support.
CureAgent turns 63 clinical-guideline PDFs into 7,154 searchable evidence chunks, retrieves and reranks the most relevant passages, and streams answers with source-linked citations. Its safety path is evaluated against 229 questions—including 44 deliberately unanswerable cases—and abstains when the available evidence cannot support an answer. The system also includes multi-provider LLM routing, production observability, and failure recovery.
Live Demo · Frontend · API Docs
pg_trgm character n-gram
similarity.[n] markers to the source URL, section path, and supporting quote.User → Hybrid Retrieval → LLM Reranking → Grounded LLM → Citation / Abstention → SSE
The backend is a domain-oriented NestJS modular monolith backed by PostgreSQL and Redis. See the architecture document for the complete system design and step specifications for implementation-level decisions. These documents remain the source of truth; the README intentionally stays at system-overview level.
NestJS 11 · TypeScript 5 · Drizzle ORM · PostgreSQL 17 (pgvector exact cosine search + pg_trgm) ·
Redis 7 · SSE · OpenAPI · Prometheus · Jest + Testcontainers · Docker
The offline evaluation uses a production-corpus snapshot rather than synthetic retrieval fixtures,
and runs the deployed policy (hybrid-rrf60-top30x2-bm2575-cut0.48-score9-v6 with the qa-v6
generation prompt).
| Scope | Size |
|---|---|
| Clinical-guideline documents surveyed | 87 PDFs |
| Ingested into the searchable corpus | 63 PDFs |
| Indexed evidence corpus | 7,154 active chunks |
| Evaluation questions | 229 total |
| Answerable / expected-abstention split | 185 / 44 |
Representative results:
| Metric | Result |
|---|---|
| Hybrid candidate coverage | 100.0% |
| Keyword-arm Recall@30 | 100.0% |
| Reranked Recall@5 | 98.9% |
| Reranked MRR@5 | 0.942 |
| Out-of-scope questions answered (leakage) | 0 / 44 |
| Answerable questions answered | 185 / 185 |
| Claim-level support rate | 91.8% |
Abstention is reported end to end, because the layered gates only compose at the end. At the deployed relevance cutoff the retrieval-stage gates abstain on 41 of the 44 out-of-scope questions (93.2% abstention recall) and the generation-stage answerability gate catches the remaining 3, so none is answered; no answerable question is abstained (0.0% over-abstention). Retrieval-stage abstention recall is counted before the generation gate, which makes it an upper bound on leakage rather than the safety result itself.
Retrieval and abstention results come from the 2026-09-10 policy run; claim support comes from the qa-v5 groundedness run, measured under the preceding generation prompt. The 229-question set also informed cutoff selection, so these are diagnostic policy metrics—not an independent held-out generalization benchmark, and on the 44-question abstention axis repeated runs of one configuration move by one to two questions. See all evaluation reports for prompts, failure cases, distribution sweeps, and limitations.
Prerequisites: Node.js 22+, pnpm 10+, and Docker.
pnpm install
cp .env.example .env # Configure required secrets and at least one OAuth provider
docker compose up -d # PostgreSQL + pgvector and Redis
pnpm db:migrate # Apply Drizzle migrations
pnpm start:dev # API: http://localhost:3000/api/v1
# Swagger: http://localhost:3000/api/docs
Run the verification suites:
pnpm lint && pnpm test # Lint and unit tests
pnpm test:e2e # Testcontainers e2e; Docker required
OPENAI_API_KEY and ANTHROPIC_API_KEY are optional. Without them, deterministic fake LLM,
embedding, reranking, and guidance providers keep local and CI flows testable. Authentication still
requires at least one configured Google, Kakao, or Naver OAuth client ID; see
.env.example for every setting.
Each increment starts with a one-page specification. Acceptance e2e tests are derived independently before implementation, reviewed, and frozen; implementation must satisfy them without changing the test oracle. Hooks prevent edits to frozen tests, while a commit-based diff audit catches bypass attempts. The delivery pipeline then automates the path from dev PR and CI through the production deployment PR and CD.
See Specification-Driven Development for the enforcement model, automation harness, and a traceable production example.