I built a RAG platform because I was tired of spending 15 minutes searching for team docs

joungminsung — Sat, 28 Mar 2026 06:58:41 +0000

It Started with a Simple Frustration

During a project, when a teammate asked "Where's the deployment process documented?", I couldn't answer right away either. Was it in the GitHub Wiki? Notion? Or Confluence?

I ended up spending over 10 minutes finding and sending the link, and I realized I was repeating this every time. The docs were definitely somewhere, but the process of finding them was incredibly inefficient.

So I started building it myself.

OpenDocuments

In one line: a tool that connects documents scattered across multiple places and answers natural language questions with sources.

GitHub repos ──┐
Notion pages ──┤    ┌──────────┐
Google Drive ──┤──► │ Parse    │    "How does auth work?"
Confluence   ──┤    │ Chunk    │           │
S3 buckets   ──┤    │ Embed    │           ▼
Local files  ──┘    └────┬─────┘    ┌──────────┐
                         │          │ RAG      │
                   ┌─────┴─────┐    │ Search   │
                   │ SQLite    │◄───│ Rerank   │
                   │ LanceDB   │    │ Generate │
                   └───────────┘    └────┬─────┘
                                         │
                                    "It's JWT-based and
                                     uses a refresh flow.
                                     [Source: auth.md]"

Connectors

I built these around the tools teams actually use.

GitHub, Notion, Google Drive, S3, Confluence, Swagger, web crawler, and even Tavily web search. Local files work of course, and you can drag-and-drop upload through the web UI.

File Formats

This is where I honestly spent a lot of time yak-shaving. It supports 12 formats: PDF, DOCX, Excel, HTML, Jupyter Notebooks, email (.eml), source code, PPTX, JSON/YAML, and more.

If a parser fails, a fallback chain automatically tries the next one. For example, if the PDF parser fails, the OCR parser takes over.

Local LLM

This is personally what I consider the most important part.

Through Ollama, you can run Qwen 3.5, Llama 4, DeepSeek V3.2, Gemma 3, EXAONE, and others locally. Running opendocuments init checks your RAM and GPU and recommends a model.

docker compose --profile with-ollama up -d
# LLM, embeddings, vector search, web UI — all local

Since no data leaves your machine, even security-conscious teams can adopt it. Of course, cloud models like OpenAI, Claude, Gemini, and Grok are also supported.

Cross-Language Search (Korean/English)

Ask in Korean and it finds English documents, and vice versa. I think this will be quite useful for multilingual teams.

opendocuments ask "What's the remote work policy for the Tokyo office?" --profile precise

RAG Pipeline

It doesn't just do embedding search — I added several more stages:

Intent Classification — Classifies whether it's a code question, conceptual question, or comparison
Query Decomposition — Queries like "Compare v2 and v3 specs" get split into sub-queries
Hybrid Search — Combines vector search + FTS5 keyword search using RRF
Reranking — Re-orders search results
Hallucination Guard — Verifies each sentence in the answer is grounded in actual sources
3-Tier Caching — Query (5 min), embedding (24 hrs), web search (1 hr)

Honestly, there's still a lot to improve, but the basic pipeline is in place.

MCP Server

Many of you are probably using Claude Code or Cursor these days — connecting via the MCP server lets you search internal docs right while coding.

{
  "mcpServers": {
    "opendocuments": {
      "command": "opendocuments",
      "args": ["start", "--mcp-only"]
    }
  }
}

How to Use

There are three ways:

Web UI — Chat, document management, admin dashboard (http://localhost:3000)
CLI — 17 commands with pipe support for scripting
TypeScript SDK — For integrating with other services

Tech Stack

It grew quite a bit as I built it. Roughly:

Turborepo monorepo, TypeScript
Server: Hono, Frontend: React + Vite + Tailwind
Storage: SQLite + LanceDB
51 test suites with around 300 tests
Plugins: 9 parsers, 8 connectors, 5 models

Getting Started

npm install -g @opendocuments/cli
opendocuments init
opendocuments start

init runs an interactive wizard that detects your hardware, recommends a model, and generates the config file.

Plugins

If you need a custom parser or connector, you can build your own:

opendocuments plugin create my-parser --type parser

There are four types — parser, connector, model, and middleware — with type interfaces and lifecycle hooks provided.

Wrapping Up

There are surely still many shortcomings, but I'll actively incorporate any feedback. It's MIT licensed, and Stars, Issues, and PRs are all welcome.

GitHub: https://github.com/joungminsung/OpenDocuments

DEV Community: joungminsung