Kasen-Sabo GraphRAG MVP

An experimental platform that structures Japan's River & Sediment Control Technical Standards (Survey / Planning / Design / Maintenance editions) into a Neo4j knowledge graph and compares the performance of GPT-OSS Swallow 20B with and without GraphRAG.

v0.6 — 2026-03-03
Best model: Swallow-8B-Instruct QLoRA FT (n=715) — Judge avg 2.92 / 3 on 100-question benchmark
Baseline comparison: GPT-OSS Swallow 20B RL v0.1 (Tokyo Tech × AIST / Apache 2.0)

🇯🇵 Japanese version: README_JP.md

---

Verified Configuration (v0.6)

---

Knowledge Graph Schema

Node & Relation Map

flowchart LR
    subgraph Structural["Structural Nodes"]
        STD(["Standard x7"])
        CH(["Chapter x76"])
        SEC(["Section x33"])
        ITEM(["Item x25"])
    end

    subgraph Domain["Domain Nodes"]
        FAC(["FacilityType x20"])
        HAZ(["HazardType x8"])
        TC(["TechnicalConcept x22"])
        REQ(["RequirementType x5"])
        PROC(["ProcessConcept x4"])
    end

    STD -->|HAS_CHAPTER| CH
    CH  -->|HAS_SECTION| SEC
    SEC -->|HAS_ITEM| ITEM

    FAC -->|DESCRIBED_IN| CH
    FAC -->|DESCRIBED_IN| SEC
    FAC -->|SUBJECT_TO| HAZ
    FAC -->|MITIGATES| HAZ
    FAC -->|REQUIRES| TC

    TC  -->|DEFINED_IN| CH
    TC  -->|DEFINED_IN| SEC
    TC  -->|USED_IN| PROC
    PROC -->|PRECEDES| PROC

    HAZ -->|AFFECTS| FAC

Relation Summary (268 total)

---

GraphRAG Algorithm Flow

flowchart TD
    Q(["User Question"]) --> KW

    subgraph Retrieval["Graph Retrieval"]
        KW["extract_keywords"]
        KW --> FTS["1. fulltext keyword_search"]
        KW --> FAC2["2. facility_context"]
        KW --> HAZ2["3. hazard_facility_map"]
        KW --> MC["4. maintenance_cycle_query"]
        KW --> CF["5. compare_facilities"]
        FTS --> DEDUP
        FAC2 --> DEDUP
        HAZ2 --> DEDUP
        MC --> DEDUP
        CF --> DEDUP
        DEDUP["deduplicate"]
        DEDUP --> HITS{"graph_hits >= 25?"}
        HITS -->|No| RETRY["Adaptive Retry: TOP_K x2 + broad_section_search"]
        RETRY --> MERGE["merge and deduplicate"]
        HITS -->|Yes| RANK
        MERGE --> RANK
    end

    subgraph Ranking["Re-ranking"]
        RANK["_score_record: fulltext=neo4j_score x10, others=keyword match"]
        RANK --> SORT["sort descending, keep top 80%"]
        SORT --> CTX["build_context_text max_chars=2000"]
    end

    subgraph Generation["LLM Generation"]
        CTX --> CLLM["Case C: GraphRAG LLM - GPT-OSS Swallow 20B"]
        Q   --> ALLM["Case A: Plain LLM - GPT-OSS Swallow 20B"]
    end

    subgraph Evaluation["LLM-as-Judge"]
        CLLM --> JUDGE["Qwen2.5:14B Judge - 0 to 3 point scoring"]
        ALLM --> JUDGE
    end

    JUDGE --> OUT[("JSONL result + Markdown report")]

Key Design Points

---

Directory Structure

kasendam_graph_rag/
├── app/
│   ├── main.py                  # FastAPI entry point & routing
│   ├── graph_rag.py             # GraphRAG orchestrator (retrieval + ranking)
│   ├── neo4j_client.py          # Neo4j connection & Cypher query library
│   ├── llm_client.py            # LLM client (Ollama native /api/generate)
│   └── config.py                # Settings & environment variables
│
├── scripts/
│   ├── 01_extract_entities.py   # MD → entity extraction via LLM
│   ├── 02_load_neo4j.py         # CSV → Neo4j MERGE loader
│   ├── 03_generate_lora_qa.py   # LoRA training QA pair generation
│   ├── 04_evaluate.py           # GraphRAG vs Plain LLM auto-evaluation
│   └── cypher/
│       └── init_schema.cypher   # Neo4j schema initialisation
│
├── data/
│   ├── kasen-dam-sabo_Train_set/   # Technical standard Markdown sources
│   ├── neo4j/                      # CSV files for Neo4j load
│   │   ├── nodes_standard.csv
│   │   ├── nodes_chapter_section_item.csv
│   │   ├── nodes_domain.csv
│   │   ├── relations.csv
│   │   └── extracted/              # Output of 01_extract_entities.py
│   └── eval/
│       ├── test_questions_100.json # 100-question test set
│       └── results/                # Output of 04_evaluate.py
│
├── .env.example
├── Modelfile.swallow
├── requirements.txt
├── README.md        ← English (this file)
└── README_JP.md     ← Japanese original

---

Setup

1. Ollama + GPT-OSS Swallow

ollama pull hf.co/mmnga-o/GPT-OSS-Swallow-20B-RL-v0.1-gguf:Q4_K_M

Quantisation options (if VRAM is limited)

File	Size	Note
Q4_K_M	15.8 GB	Recommended (quality/speed balance)
Q4_K_S	14.7 GB	Slightly smaller
Q4_0	12.1 GB	Memory-first

Important — GPT-OSS chat template
GPT-OSS models use special channel tokens (<|channel|>final etc.).
Ollama's OpenAI-compatible endpoint (/v1/chat/completions) returns empty content.
llm_client.py bypasses this by calling /api/generate with raw=True and a manually built template:

<|start|>system<|message|>{system}<|end|>
<|start|>user<|message|>{user}<|end|>
<|start|>assistant<|channel|>final<|message|>

2. Python Environment

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt

3. Environment Variables

copy .env.example .env
# Edit .env

Minimum .env:

OPENAI_API_KEY=ollama          # Dummy value for Ollama
LLM_BASE_URL=http://localhost:11434/v1
LLM_MODEL=hf.co/mmnga-o/GPT-OSS-Swallow-20B-RL-v0.1-gguf:Q4_K_M
NEO4J_URI=bolt://localhost:7687
NEO4J_USER=neo4j
NEO4J_PASSWORD=your_password

# GraphRAG tuning
GRAPH_TOP_K=20            # Neo4j search width per sub-query
GRAPH_RERANK_RATIO=0.8    # Keep top 80% of score > 0 records
LLM_TEMP=0.2

# LLM-as-Judge
JUDGE_MODEL=qwen2.5:14b

4. Neo4j Setup

Start Neo4j Desktop and ensure the database is RUNNING, then:

# Reset DB and load all CSVs (schema init runs automatically)
python scripts/02_load_neo4j.py --reset
# → 184 nodes · 268 relations

5. Start GraphRAG API

python -m uvicorn app.main:app --port 8080

Swagger UI: http://localhost:8080/docs

---

Running the Pipeline

# Step 1: Extract entities from Technical Standard Markdown
python scripts/01_extract_entities.py

# Step 2: Load into Neo4j
python scripts/02_load_neo4j.py --mode all

# Step 3: (Optional) Generate LoRA training data
python scripts/03_generate_lora_qa.py

# Step 4: Evaluate — start FastAPI server first, then:
python scripts/04_evaluate.py                              # All 100 questions (~3–5 h)
python scripts/04_evaluate.py --start 1 --end 5            # Quick test (5 questions)
python scripts/04_evaluate.py --no-judge                   # Collect answers only (fast)
python scripts/04_evaluate.py --judge-only results.jsonl   # Re-judge existing results

Output:

• data/eval/results/results_<timestamp>.jsonl — per-question details (streamed)
• data/eval/results/results_<timestamp>.md — category summary report

---

API Usage

# Case C — GraphRAG
curl -X POST http://localhost:8080/query \
  -H "Content-Type: application/json" \
  -d '{"question": "How is a sabo dam inspected?"}'

# Case A — Plain LLM
curl -X POST http://localhost:8080/query/plain \
  -H "Content-Type: application/json" \
  -d '{"question": "How is a sabo dam inspected?"}'

# Graph queries
curl http://localhost:8080/graph/facility/砂防堰堤
curl http://localhost:8080/graph/hazard/土石流
curl http://localhost:8080/graph/maintenance

---

Experiment Cases

LLM-as-Judge Scoring Rubric

Fairness design: Judge uses Qwen2.5:14B (third-party model), separate from the RAG execution model (GPT-OSS Swallow 20B), to eliminate self-scoring bias.

Test-Set Category Breakdown (100 questions)

---

Evaluation Results

v0.3 — 14-Question Benchmark (2026-03-01 / results_20260301_201326.jsonl)

Category: "Maintenance — River" (14 Q: levee×5, revetment×3, groin, bed stabiliser, weir/flap×2, pump station, cycle-type)

v0.2 → v0.3 Delta

Remaining Issues

---

v0.4 — 100-Question Full Benchmark (2026-03-02 / results_20260301_210818.jsonl)

All 8 categories: Survey / Planning / Design / Maintenance (River+Dam+Sabo) / Hazard / Cross-domain

Score Distribution

C-A = +0.33  |  C > A: 36 Q  |  A > C: 17 Q  |  Tie: 47 Q

By Category

graph_hits Statistics

Key Findings (v0.4)

Latency Comparison

C is faster in 96/100 questions — graph context constrains the LLM's output space, reducing token generation time despite the extra Neo4j query overhead.

---

v0.6 — Case B 100-Question Benchmark (2026-03-02 / results_b_20260302_214650.md)

Model: swallow8b-lora-n715 — Swallow-8B-Instruct QLoRA fine-tuned on 715 graph-derived QA pairs
Endpoint: POST /query/plain (same as Case A, but with LoRA FT model loaded)

A / B / C Three-way Comparison

Key finding: Case B (8B + LoRA FT) achieves +0.63 over Case A and +0.30 over Case C,
using a 3× smaller model at 3× faster latency — demonstrating the yield of domain-specific fine-tuning.

Case B Score Distribution

Case B by Category

| graph_hits vs C latency (Pearson r) | 0.085 — no significant correlation |

By Category

---

Lessons Learned — A / B / C Comparison

Four visualisations summarising the key findings from the three-way A/B/C comparison.

---

① Approach Trade-off — Inference Speed vs Answer Quality

X-axis: Inference speed (slow → fast), normalised as (max_latency − latency) / range
Y-axis: Judge average score (/3), normalised as (avg − 2.0) / 1.0

Lesson ① — Case B (LoRA FT) sits alone in the upper-right ideal zone.
Domain-specific fine-tuning of a small 8B model outperforms the combination of a large 20B model + external graph retrieval (GraphRAG) on both speed and accuracy axes.

---

② Judge Score Comparison

Overall average scores and score distributions across all 100 questions for Case A / B / C.

Lesson ② — LoRA fine-tuning achieves a score +0.30 above GraphRAG using a model 3× smaller at 3× faster latency.
Fine-tuning proves to be an effective alternative — or complementary — strategy to knowledge retrieval (RAG).

---

③ Architecture Comparison (Flowchart)

Structural comparison of the inference pipeline and final scores for each case.

flowchart LR
    Q[/"100 Questions"/]

    subgraph A["Case A — Baseline"]
        A1["GPT-OSS Swallow 20B<br/>General-purpose"]
        A2["Score: 2.29/3<br/>Latency: 42.2 s"]
    end

    subgraph B["Case B — LoRA FT  (Best)"]
        B1["Swallow-8B<br/>QLoRA n=715"]
        B2["Score: 2.92/3<br/>Latency: 14.2 s"]
    end

    subgraph C["Case C — GraphRAG"]
        C1["Neo4j<br/>Knowledge Graph"]
        C2["GPT-OSS Swallow 20B<br/>+ Graph Context"]
        C3["Score: 2.62/3<br/>Latency: 31.1 s"]
    end

    Q --> A1 --> A2
    Q --> B1 --> B2
    Q --> C1 --> C2 --> C3

Lesson ③ — Case B achieves the highest accuracy with the simplest pipeline (no external DB at inference time).
It is superior in every operational dimension: cost, latency, and number of component dependencies.

---

④ Evolution of Approaches

Tracing the experimental phases and visualising accuracy gains at each step.

Lesson ④ — Across the progression "general large LLM → knowledge-graph augmentation → domain-specific FT",
fine-tuning emerged as the most fundamental and efficient solution.

---

Summary — Three Key Lessons

Next experiment candidate (Case D): Does 8B LoRA FT + GraphRAG exceed Case B?
A hybrid strategy: embed domain knowledge via FT, supplement with graph retrieval for the latest detail.

---

Qualitative Analysis — 10 Representative Questions

Full answer texts → docs/qa_comparison_10q.md

Score Pattern Summary

Key Qualitative Findings

① Case A (Qwen2.5-14B vanilla) — catastrophic failure on open-ended questions

Questions Q5, Q24, Q82 received score 0 from the judge. Symptom: the model repeated the same phrase hundreds of times (e.g. ＝長寿命化 × 300+ tokens), producing zero useful content. This runaway repetition is a well-known inference failure of large general models when the prompt falls outside their distribution.

② Case B (Swallow-8B LoRA FT) — concise, domain-aligned, consistent

Case B answered the same questions with 200–400 characters of clear, structured prose. Score 3/3 was awarded 63 out of 100 times (vs Case A: 55/100, Case C: 52/100). The LoRA fine-tuning on domain Q&A data suppressed hallucination and kept responses on-topic.

③ Case C (Swallow-8B vanilla) — bimodal quality

Strong on well-structured, retrievable information (e.g. Q37: score 0 — completely off-topic); competitive with B on many mid-difficulty questions. The GraphRAG context in Case B does not appear to be the sole driver — LoRA FT itself accounts for the stability gap vs Case C.

④ Cases where A outperforms B (Q26, Q52, Q95)

All three are short, factual recall questions with a single correct answer (formula, criterion value, definition). The 14B parameter capacity of Qwen2.5 gives it an edge on memorised facts even without domain FT. Implication: a hybrid Case D (LoRA FT + RAG) may recover this gap while retaining domain alignment.

⑤ Case B latency advantage persists across Q types

Average elapsed time: A = 42.2 s, B = 14.2 s, C = 31.1 s. Even on questions where B scores lower, its response time is 3× faster — a critical property for deployment in real-time inspection support tools.

---

Case B — LoRA Fine-tuning Setup

Environment

注意 — triton バージョン固定
unsloth は triton-windows==3.2.0.post21 を 固定 してください。
pip install "unsloth[cu124-ampere]" で自動インストールされる 3.6.x は
AttrsDescriptor API の廃止により torch._inductor のインポートエラーが発生します。

pip install "unsloth[cu124-ampere]" trl transformers datasets accelerate
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124
pip install "triton-windows==3.2.0.post21"  # 3.5/3.6 系を上書きダウングレード

QLoRA Hyperparameters (scripts/05_train_lora_unsloth.py)

Prompt Format (Llama-3 Instruct)

<|begin_of_text|>
<|start_header_id|>system<|end_header_id|>

あなたは河川砂防技術基準（調査・計画・設計・維持管理）を熟知した専門家です。正確で実務的な回答をしてください。<|eot_id|>
<|start_header_id|>user<|end_header_id|>

{question}<|eot_id|>
<|start_header_id|>assistant<|end_header_id|>

{answer}<|eot_id|>

Training Data & Subsets

データは scripts/04a_make_subsets.py で生成。rel_type 割合を各段階で保持（seed=42）。
テスト 100 問との独立性は文字 bigram Jaccard < 0.45 でフィルタ済み。

Running Training

# 動作確認（subset=100、約 10〜20 分）
python scripts/05_train_lora_unsloth.py --subset 100

# 全 4 段階を順番に実行
python scripts/05_train_lora_unsloth.py --subset all

# 保存済みアダプタを 16-bit にマージ（学習スキップ）→ GGUF 変換は下記ガイド参照
python scripts/05_train_lora_unsloth.py --subset 715 --export_only

出力:

models/lora/swallow8b_n{N}/          ← LoRA アダプタ (safetensors)
models/gguf/swallow8b_lora_n{N}/     ← GGUF Q4_K_M + Modelfile (--export_gguf 時)
data/lora/train_loss_{N}.json        ← 学習ロス履歴

Ollama へのロード (GGUF 変換後):

# 詳細な変換手順は「GGUF Quantize Guide (Windows)」セクションを参照
ollama create swallow8b-lora-n715 -f C:\ollama_import\Modelfile_q4

Convergence Check Plan

Loss monotonically decreases with dataset size → stable convergence confirmed.
Adapter saved to models/lora/swallow8b_n{N}/ (safetensors format).

---

GGUF Quantize Guide (Windows)

Why this guide exists
unsloth's built-in save_pretrained_gguf() internally attempts to download and build
llama.cpp via apt (Linux package manager), which hangs silently on Windows.
The workaround is to use the official llama.cpp Windows release binary directly.

Step 0 — Prerequisites

# Download llama.cpp Windows CPU binary (b8185 or later)
$url = "https://github.com/ggerganov/llama.cpp/releases/download/b8185/llama-b8185-bin-win-cpu-x64.zip"
Invoke-WebRequest -Uri $url -OutFile "C:\llama_cpp\llama-win.zip" -UseBasicParsing
Expand-Archive -Path "C:\llama_cpp\llama-win.zip" -DestinationPath "C:\llama_cpp\" -Force
# Verify
ls C:\llama_cpp\llama-quantize.exe

# Download convert script (match the release tag)
Invoke-WebRequest `
  -Uri "https://raw.githubusercontent.com/ggerganov/llama.cpp/b8185/convert_hf_to_gguf.py" `
  -OutFile "C:\llama_cpp\convert_hf_to_gguf.py" -UseBasicParsing

# Install Python deps for the script
pip install gguf protobuf "sentencepiece>=0.1.98"

Step 1 — Merge adapter → 16-bit safetensors

# --export_only: loads saved adapter, merges into full 16-bit model, skips retraining
python scripts/05_train_lora_unsloth.py --subset 715 --export_only

Output: models/gguf/swallow8b_lora_n715/ (merged safetensors, ~15.3 GB)

Step 2 — Convert to GGUF bf16

python C:\llama_cpp\convert_hf_to_gguf.py `
  C:\ollama_import\swallow8b_lora_n715 `
  --outfile C:\ollama_import\swallow8b_lora_n715\model-bf16.gguf `
  --outtype bf16

Tip: Copy the merged model folder to a path outside the project (e.g. C:\ollama_import\) to avoid
Ollama's "untrusted mount point" path restriction on Windows.

Step 3 — Quantize to Q4_K_M

C:\llama_cpp\llama-quantize.exe `
  C:\ollama_import\swallow8b_lora_n715\model-bf16.gguf `
  C:\ollama_import\swallow8b_lora_n715\model-q4_k_m.gguf `
  Q4_K_M

Elapsed: ~2.3 min on CPU (AMD / Intel AVX2, 16-thread)

Step 4 — Register in Ollama

Create a Modelfile pointing directly to the .gguf file (not a directory):

FROM C:\ollama_import\swallow8b_lora_n715\model-q4_k_m.gguf
SYSTEM "あなたは河川砂防技術基準（調査・計画・設計・維持管理）を熟知した専門家です。正確で実務的な回答をしてください。"
PARAMETER temperature 0.3
PARAMETER repeat_penalty 1.1

ollama create swallow8b-lora-n715 -f C:\ollama_import\Modelfile_q4
ollama list | Select-String "swallow8b-lora"
# → swallow8b-lora-n715:latest    4.9 GB

Step 5 — Smoke test

ollama run swallow8b-lora-n715 "砂防堰堤の定期点検で確認すべき主な変状を挙げてください。"

Known Issues on Windows

---

Changelog

v0.6 — 2026-03-03

• Case B 100-question evaluation complete (results_b_20260302_214650.md)
  • Evaluated all 100 questions using swallow8b-lora-n715 (Swallow-8B LoRA FT, n=715)
  • Judge avg 2.92/3 — 92 questions at 3 pts, 8 questions at 2 pts, 0 questions at 0–1 pts
  • Highest score among all three cases, surpassing Case A (2.29) and Case C (2.62)
• scripts/04_evaluate.py: Added --case-b flag (calls /query/plain only, labels output as case_b)
• Added generate_summary_b() for Case B dedicated report generation
• scripts/06_plot_abc_comparison.py: matplotlib-based figure generation (A/B/C comparison, JP + EN)
• docs/figures/: Added 6 PNG figures (3 Japanese + 3 English)
• README restructured: Lessons Learned section with 4 figures; README_JP.md added
• scripts/07_compare_qa_table.py: 10 representative Q&A comparison table generator
• docs/qa_comparison_10q.md: Full answer texts for A/B/C on 10 selected questions (qualitative analysis)
• README: Added "Qualitative Analysis — 10 Representative Questions" section (5 key findings)
• README: Added "References" section (14 entries: LoRA, QLoRA, Llama 3, Swallow, GraphRAG, RAG, LLM-as-Judge, etc.) for arXiv paper preparation

v0.5 — 2026-03-02

• Case B LoRA training data preparation complete

  • scripts/03b_generate_lora_qa_graph.py: 268 relations × 3 Q = 715 QA pairs generated
  • scripts/04a_make_subsets.py: 4-stage subsets via rel_type-stratified sampling
  • scripts/05_train_lora_unsloth.py: Swallow-8B-Instruct QLoRA training script

• unsloth environment established (torch 2.6.0+cu124 / triton-windows 3.2.0.post21)

  • Known issue: packing=True hangs in triton JIT → resolved with packing=False + TORCHDYNAMO_DISABLE=1

• 4-stage QLoRA training complete — stable convergence confirmed

  Subset	Loss	Time
  100 Q	0.7958	4.4 min
  250 Q	0.6859	10.2 min
  500 Q	0.6045	20.0 min
  715 Q	0.5565	28.5 min

• n=715 adapter converted to GGUF Q4_K_M and registered in Ollama

  • --export_only flag merges adapter without retraining
  • Windows-specific issues (apt hang / mount-point restriction) documented in GGUF Quantize Guide
  • swallow8b-lora-n715:latest registered (4.9 GB; bf16 15.3 GB → Q4_K_M 4.7 GB)
  • Smoke test passed (domain-specific river-sabo responses confirmed)

v0.4 — 2026-03-02

• 100-question full evaluation across 8 categories (results_20260301_210818.jsonl)
• A avg 2.29 / C avg 2.62 (+0.33 GraphRAG effect confirmed at scale)
• C wins 36 Q (36%), A wins 17 Q (17%), tie 47 Q (47%)
• graph_hits avg 33.8; adaptive retry fired for 8 Q (all recovered to ≥25)
• Latency: C is 11.1 s faster on average (42.2 s → 31.1 s); C faster in 96/100 Q — graph context constrains token generation
• Identified weakness: "Planning" category C < A — over-retrieval of Chapter metadata suspected

v0.3 — 2026-03-01

1. app/llm_client.py — repeat_penalty bug fix (critical)
   repeat_penalty=1.2 and stop tokens were embedded in a comment and never applied. Fixed for both Case A and Case C.

2. app/graph_rag.py — adaptive retry on low graph hits
   Added GRAPH_LOW_HIT_THRESHOLD = 25. Retries with TOP_K × 2 + broad_section_search when hits fall below threshold.

3. app/neo4j_client.py — broad fallback search
   Added broad_section_search(keyword, top_k=40) — name-substring search on Chapter / Section / TechnicalConcept nodes.

4. scripts/02_load_neo4j.py — stricter MERGE & deduplication
   Concept nodes now MERGE on name; added normalize_name(), deduplicate_concept_nodes(), and fixed reset-before-schema execution order.

v0.2 — 2026-03-01

• 100-question test set; scripts/04_evaluate.py (Case A vs C, LLM-as-Judge)
• Graph re-ranking (_score_record()), repeat_penalty=1.2, num_ctx=8192
• Context capped at 2,000 chars; Qwen2.5:14B as third-party judge

v0.1 — 2026-03-01

• Initial release with GPT-OSS Swallow 20B via Ollama (Q4_K_M)
• Manual Neo4j CSV loaded (184 nodes · 268 relations)
• FastAPI GraphRAG API operational; /api/generate native call to bypass Ollama OpenAI-endpoint limitation

---

References

Key papers cited in support of the arXiv manuscript based on this project.

Foundation Models & Fine-tuning

[1] LoRA — Low-Rank Adaptation
Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., & Chen, W. (2022).
LoRA: Low-Rank Adaptation of Large Language Models.
ICLR 2022. https://arxiv.org/abs/2106.09685

[2] QLoRA — Efficient Fine-tuning with Quantisation
Dettmers, T., Pagnoni, A., Holtzman, A., & Zettlemoyer, L. (2023).
QLoRA: Efficient Finetuning of Quantized LLMs.
NeurIPS 2023. https://arxiv.org/abs/2305.14314

[3] Llama 3 — Base Architecture
Meta AI. (2024).
The Llama 3 Herd of Models.
https://arxiv.org/abs/2407.21783

[4] Swallow — Japanese-Adapted Llama 3
Okazaki, N., Fujii, R., Oshiro, T., Zhao, H., Abe, H., Sakamoto, K., & Takahashi, K. (2024).
Building a Large Japanese Web Corpus for Large Language Models.
LREC-COLING 2024. https://arxiv.org/abs/2404.17733

[5] Unsloth — Efficient QLoRA Training Framework
Han, D., & Han, M. (2023).
Unsloth: 2-5× Faster, 70% Less Memory QLoRA Finetuning.
https://github.com/unslothai/unsloth

Retrieval-Augmented Generation (RAG)

[6] RAG — Retrieval-Augmented Generation
Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., … Kiela, D. (2020).
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
NeurIPS 2020. https://arxiv.org/abs/2005.11401

[7] GraphRAG — From Local to Global
Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., … Larson, J. (2024).
From Local to Global: A Graph RAG Approach to Query-Focused Summarization.
Microsoft Research. https://arxiv.org/abs/2404.16130

[8] Knowledge Graph + LLM Survey
Pan, S., Luo, L., Wang, Y., Chen, C., Wang, J., & Wu, X. (2024).
Unifying Large Language Models and Knowledge Graphs: A Roadmap.
IEEE TKDE 2024. https://arxiv.org/abs/2306.08302

[9] HippoRAG — Neurobiologically-Inspired RAG
Guo, Z., Jorge, J., Shi, T., Corro, A., & Yoon, S. (2024).
HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models.
https://arxiv.org/abs/2405.14831

Evaluation

[10] LLM-as-Judge
Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., … Stoica, I. (2023).
Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
NeurIPS 2023 Datasets & Benchmarks Track. https://arxiv.org/abs/2306.05685

[11] RAGAS — RAG Evaluation Framework
Es, S., James, J., Anke, L. E., & Schockaert, S. (2023).
RAGAS: Automated Evaluation of Retrieval Augmented Generation.
https://arxiv.org/abs/2309.15217

Infrastructure

[12] Neo4j Property Graph
Neo4j, Inc. (2024). Neo4j Graph Database & Analytics.
https://neo4j.com/

[13] Ollama — Local LLM Serving
Ollama (2024). Run large language models locally.
https://ollama.com/

[14] GGUF / llama.cpp Quantisation
Gerganov, G. et al. (2023). llama.cpp.
https://github.com/ggerganov/llama.cpp

---

License

This project is licensed under the Apache License 2.0.

Copyright 2026 tk-yasuno

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.