Knowledge Base on KnightLi Blog

OpenKB: Compiling Documents into a Continuously Updated LLM Knowledge Base

Sun, 17 May 2026 17:15:08 +0800

OpenKB is an open-source LLM knowledge base tool from VectifyAI.

It is not a traditional RAG system that chunks documents, vectorizes them, and then stitches context back together at query time. Instead, it first compiles raw documents into a structured wiki: document summaries, concept pages, cross-references, follow-up queries, and lint checks. In other words, it feels more like a knowledge-base CLI that keeps organizing your material over time.

Project link: https://github.com/VectifyAI/OpenKB

The Short Version

OpenKB is worth watching for three reasons:

It outputs the knowledge base as ordinary Markdown files instead of locking it inside a dedicated database.
It uses PageIndex for long PDFs, focusing on vector-database-free retrieval for long documents.
It emphasizes “knowledge compilation”: the LLM generates summaries, concept pages, and cross-links instead of retrieving from scratch on every question.

That makes OpenKB better suited to long-term knowledge accumulation: paper reading, project documentation, internal company materials, technical standards, product research, and personal knowledge bases.

It is not a universal replacement. If you need high-concurrency online Q&A, complex permissions, a web admin console, enterprise audit trails, or large-scale multi-tenancy, OpenKB currently looks more like a developer tool and knowledge-base prototype than a complete enterprise knowledge platform.

What OpenKB Is

OpenKB stands for Open Knowledge Base.

It works as a CLI: it converts, organizes, summarizes, and writes documents into a set of wiki files. The official README describes it directly: OpenKB uses LLMs to compile raw documents into a structured, interlinked wiki-style knowledge base, with PageIndex providing vectorless long-document retrieval.

Supported input formats include:

PDF
Word
Markdown
PowerPoint
HTML
Excel
Plain text
Other formats that markitdown can convert

The generated knowledge base lives under wiki/ and mainly includes:

index.md: knowledge base overview
log.md: operation timeline
AGENTS.md: knowledge base structure and maintenance instructions
sources/: converted source text
summaries/: summaries for each document
concepts/: cross-document concept pages
explorations/: saved query results
reports/: lint reports

The biggest benefit of this design is transparency. You can open the Markdown files directly instead of only receiving answers through a black-box retrieval interface.

How It Differs from Traditional RAG

A typical traditional RAG pipeline looks like this:

Chunk the documents.
Generate embeddings.
Store them in a vector database.
Retrieve relevant chunks at query time.
Feed those chunks to the LLM to generate an answer.

That workflow is mature and works well for Q&A systems. But it has one problem: the knowledge itself does not really accumulate. Every question repeats the work of finding chunks, assembling context, and generating an answer.

OpenKB is closer to “organize first, ask later”:

Documents enter raw/.
Short documents are converted to Markdown with markitdown.
Long PDFs go through PageIndex to produce tree indexes and summaries.
The LLM generates document summaries.
The LLM reads existing concept pages and creates or updates cross-document concepts.
The knowledge base index, log, and cross-links are updated.

As a result, adding one document does more than create another searchable file. It may update a dozen wiki pages. Knowledge is written into concept pages and connected to existing material.

This is closer to how humans maintain knowledge bases: when new material arrives, you do not just archive it; you update topic pages, summarize differences, and add references.

What PageIndex Solves

Long documents have always been difficult for RAG and LLM knowledge bases.

If you simply split a long PDF into many chunks, several problems appear:

Chapter relationships are lost.
Tables, images, and footnotes are hard to handle.
Retrieved snippets are too fragmented, so answers lack global structure.
Even a large context window is not ideal for stuffing an entire document into the prompt.
Long summary chains can compress away important details.

OpenKB uses PageIndex for long PDFs. According to the project description, PageIndex builds tree indexes and summaries for long documents, letting the LLM reason over the document tree instead of reading the whole document directly.

The focus is not “the few text snippets with the highest vector similarity.” It is about helping the model use document hierarchy to find relevant content. For research reports, papers, manuals, prospectuses, and compliance documents, this direction makes a lot of sense.

OpenKB can use the open-source PageIndex locally by default. If you need OCR, complex PDF handling, or faster structure generation, you can configure PAGEINDEX_API_KEY to use PageIndex Cloud.

Install and Quick Start

Install OpenKB with pip:

`1`	`pip install openkb`

Or install the latest GitHub version:

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

For editable source installation:

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

Create a knowledge base directory:

1
2

mkdir my-kb && cd my-kb
openkb init

Add documents:

1
2

openkb add paper.pdf
openkb add ~/papers/

Ask a question:

`1`	`openkb query "What are the main findings?"`

Start an interactive chat:

`1`	`openkb chat`

If you want OpenKB to process new files automatically, use watch mode:

`1`	`openkb watch`

After that, drop files into raw/, and OpenKB will update the wiki automatically.

LLM Configuration

OpenKB uses LiteLLM to support multiple model providers, including OpenAI, Claude, and Gemini.

You can set the model during initialization, or configure it in .openkb/config.yaml:

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

Model names follow LiteLLM’s provider/model format. OpenAI models can omit the provider prefix:

`1`	`model: gpt-5.4`

Models such as Anthropic and Gemini are usually written like this:

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

Put the API key in .env:

`1`	`LLM_API_KEY=your_llm_api_key`

If you enable PageIndex Cloud, add:

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

Common Commands

OpenKB’s commands are developer-friendly:

openkb init: initialize a knowledge base.
openkb add <file_or_dir>: add a file or directory.
openkb remove <doc>: remove a document and clean up related wiki pages, images, registry entries, and PageIndex state.
openkb query "question": ask a one-off question against the knowledge base.
openkb chat: enter a multi-turn conversation.
openkb watch: monitor raw/ and update automatically.
openkb lint: check knowledge base structure and content health.
openkb list: list indexed documents and concepts.
openkb status: show knowledge base statistics.

openkb chat is better than openkb query for continuous exploration. It supports session resume, session listing, deletion, and slash commands such as /status, /list, /add <path>, /save, and /lint.

Why a Markdown Wiki Matters

Many knowledge-base tools are painful because of migration cost.

Once material enters a proprietary database, index, or format, it becomes hard to inspect, edit, back up, or migrate directly. OpenKB writes the result as ordinary Markdown, which makes it naturally compatible with existing tools.

The most direct use is opening wiki/ in Obsidian:

Summary pages can be read directly.
Concept pages can connect through [[wikilinks]].
Graph view can show relationships between knowledge items.
Query results can be saved to explorations/.
AGENTS.md can define how the knowledge base should be maintained.

That makes OpenKB more than a Q&A tool. It can become a knowledge-organizing pipeline for individuals or teams.

Best-Fit Scenarios

OpenKB is especially useful for:

Reading papers and technical reports.
Organizing project documentation.
Building product research archives.
Creating documentation knowledge bases around open-source projects.
Organizing internal policies, meeting notes, and explanatory documents.
Maintaining a personal Obsidian knowledge base automatically.
Structuring long PDFs, PPTs, Word files, and web materials.

If you often face piles of documents and want more than “ask one question, get one answer,” OpenKB’s direction is a good fit: it gradually turns material into a browsable, reusable, and traceable knowledge base.

What to Watch Out For

First, OpenKB depends on LLM quality.

Summaries, concept pages, and cross-links are generated by models. Stronger models usually produce more stable knowledge compilation; weaker models may struggle with concept extraction, contradiction detection, and cross-document synthesis.

Second, estimate cost early.

If you import many long documents at once, LLM calls may become expensive. Start with a small dataset, check the output structure and quality, and then expand.

Third, the generated wiki still needs human review.

OpenKB can organize material, but it does not automatically guarantee factual correctness. Important knowledge bases still need humans to review summaries, concept pages, and references.

Fourth, be careful with sensitive material.

If you use cloud LLMs or PageIndex Cloud, pay attention to privacy, trade secrets, and compliance requirements. For internal materials, confirm the model provider, data retention policy, and access boundaries first.

Fifth, it is currently more of a CLI tool.

The roadmap mentions a future Web UI, database-backed storage, support for large collections, and hierarchical concept indexing. At this stage, if teammates are not comfortable with the command line, there is still some adoption friction.

Relationship with Obsidian, NotebookLM, and Enterprise RAG

OpenKB and Obsidian are best understood as an “automatic organization layer” plus a “reading and editing layer.”

Obsidian is good for humans to write, edit, browse, and link notes. OpenKB is good for turning raw documents into a wiki that can enter Obsidian.

OpenKB and NotebookLM differ more around local control and open file formats.

NotebookLM is more direct for quickly asking questions and generating summaries after dropping in materials. OpenKB is better for developers who want the organized result to remain in a local directory and continue evolving as Markdown.

OpenKB does not replace enterprise RAG; it complements it.

Enterprise RAG cares more about permissions, auditability, service deployment, access isolation, monitoring, and stable throughput. OpenKB is better for building a readable, editable, long-lived knowledge layer. If you later build online Q&A, the wiki generated by OpenKB can also become a higher-quality corpus.

A Recommended Workflow

If you want to try OpenKB, start like this:

Create a test knowledge base directory.
Add 3 to 5 documents on the same topic.
Run openkb add.
Open wiki/ and inspect the summaries and concept pages.
Ask a few specific questions with openkb query.
Run openkb lint to check knowledge-base health.
Open wiki/ in Obsidian and see whether the link graph is meaningful.
Once quality looks good, import a larger document collection.

Do not throw in hundreds of files at the beginning. First see whether it understands your material type well, especially tables, images, long PDFs, and multi-document concept merging.

Summary

OpenKB’s value is that it moves an LLM knowledge base one step earlier than “assemble context at query time”: organize the material into a wiki first, then ask questions, chat, lint, and keep maintaining that wiki.

This direction is not right for every Q&A system, but it is well suited to knowledge work that needs long-term accumulation. Markdown files, Obsidian compatibility, PageIndex long-document handling, multi-model support, and a CLI workflow combine into a useful tool for developers and research-oriented users.

If you have many PDFs, reports, web pages, papers, and project documents, OpenKB is worth trying. It may not immediately replace a mature enterprise knowledge base, but it can become a practical entry point for organizing material: first turn documents into readable, linked, traceable knowledge, then let the LLM work on top of that knowledge.

References:

RAGFlow Project Notes: Features and Usage of an Open-Source RAG Engine

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow is an open-source RAG engine from infiniflow. Its goal is not merely to provide a thin “upload documents and ask questions” shell, but to bring document parsing, chunking, retrieval, reranking, citation tracing, model configuration, agent capabilities, and API integration into one complete workflow.

If you are building an enterprise knowledge base, document Q&A, a support assistant, internal information retrieval, or you want to give an LLM a more reliable context layer, RAGFlow is one of the open-source options worth serious attention.

01 What Problem RAGFlow Solves

Most RAG systems run into three common issues:

Document parsing is unstable, especially for PDFs, scanned files, tables, images, and complex layouts.
Chunking strategy is opaque, so retrieval may look correct while the actual context is incomplete.
Answers lack trustworthy citations, making it hard for users to verify where the response came from.

RAGFlow focuses on exactly these problems. The project README emphasizes Deep document understanding, template-based chunking, chunk visualization, citation grounding, and multi-path retrieval with reranking. In other words, it cares more about “high-quality input leads to high-quality answers” than simply wiring a vector database to a chat UI.

02 Core Features

1. Deep Document Understanding

RAGFlow can extract knowledge from complex unstructured data. The README lists formats such as Word, PPT, Excel, TXT, images, scanned documents, structured data, and web pages.

This matters a lot for enterprise knowledge bases. Real-world material is rarely clean Markdown. It is usually a mix of contracts, reports, tables, scanned PDFs, product manuals, screenshots, and web content. If parsing quality is weak, retrieval and LLM answers will both suffer.

2. Template-Based Chunking

RAGFlow provides template-based chunking. The value here is that chunking is not a black box; different document types can use different strategies.

For example, articles, papers, tables, Q&A documents, image explanations, and contract clauses all need different chunk boundaries and granularity. Template-based chunking helps reduce problems like broken sentences, lost table context, and separated headings and body text.

3. Traceable Citations

RAGFlow emphasizes grounded citations, meaning answers can be traced back to source passages. It also offers chunk visualization, making it easier for people to inspect and adjust parsing and chunking results.

This is especially important in production. Internal enterprise Q&A is not only about producing something that “looks right”; it also has to be verifiable. For policy, compliance, finance, technical documents, and customer support content, citations and traceability are close to mandatory.

4. Automated RAG Workflow

RAGFlow turns the RAG lifecycle into a more complete workflow:

Create a knowledge base
Upload or sync data
Parse documents
Review and adjust chunks
Configure LLM and embedding models
Run multi-path retrieval and reranking
Build chat assistants
Integrate through APIs into business systems

That makes it closer to a RAG platform than a single library. For teams, both the UI and the API matter: non-engineers can maintain the knowledge base, while engineers can integrate the capability into existing systems.

5. Agent, MCP, and Workflow Extensions

Recent RAGFlow updates already include Agentic workflow, MCP, Agent Memory, and code execution components. That suggests it is no longer limited to traditional knowledge-base Q&A and is also moving toward agent-oriented scenarios.

A typical pattern is that an agent can use RAGFlow as a reliable enterprise knowledge layer: retrieve from the knowledge base when it needs context, generate answers with citations, and combine that with tools or workflow steps when necessary.

03 Basic Usage Flow

According to the official quickstart documentation, the common usage path for RAGFlow can be summarized in the following steps.

1. Prepare the Environment

The basic requirements listed in the official README are:

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

If you want to use the sandbox for the code executor, you also need gVisor. Another practical note is that the official Docker images mainly target x86 platforms. For ARM64, the project documentation recommends building the image yourself.

2. Clone the Project

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. Check `vm.max_map_count`

RAGFlow deployment depends on components such as Elasticsearch or OpenSearch, so on Linux you usually need to verify:

`1`	`sysctl vm.max_map_count`

If the value is below 262144, you can set it temporarily:

`1`	`sudo sysctl -w vm.max_map_count=262144`

If you want the change to persist after reboot, add it to /etc/sysctl.conf.

4. Start with Docker Compose

You can start the CPU mode directly:

`1`	`docker compose -f docker-compose.yml up -d`

If you want GPU acceleration for DeepDoc tasks, the README shows enabling DEVICE=gpu in .env before startup:

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

Then inspect the logs:

`1`	`docker logs -f docker-ragflow-cpu-1`

Once the services are ready, open the machine address in your browser. Under the default configuration, that is typically:

`1`	`http://IP_OF_YOUR_MACHINE`

5. Configure Model API Keys

RAGFlow needs LLM and embedding model configuration. The README mentions choosing the default LLM factory in service_conf.yaml.template and updating the corresponding API_KEY.

In practice, you need to configure models according to your provider:

Chat model
Embedding model
Rerank model
Multimodal model, if you want to understand images inside PDFs or DOCX files

6. Create the Knowledge Base and Upload Documents

After the service starts, the typical workflow is:

Log in to the Web UI.
Create a dataset or knowledge base.
Upload documents or configure a data source sync.
Wait for parsing to finish.
Inspect chunk results and adjust them when necessary.
Create a chat assistant and attach the knowledge base.
Test answer quality and citation sources.

If you need to integrate with a business system, you can continue with the RAGFlow API or SDK and connect retrieval and chat capabilities to your own application.

04 Suitable Scenarios

RAGFlow fits these kinds of needs:

Enterprise internal knowledge-base Q&A
Product manuals, technical documentation, and FAQ retrieval
Customer support and pre-sales assistants
Traceable Q&A over contracts, reports, and policy documents
Unified handling of multi-format materials
Teams that want both UI-based maintenance and API integration
Systems that want to use RAG as the context layer for agents

It is especially suitable when document formats are complex, citations matter, and people want to inspect or intervene in parsing results.

05 What to Watch Out For

First, RAGFlow is not a lightweight script. It has real infrastructure requirements. The official recommendation is at least 4 CPU cores, 16 GB RAM, and 50 GB disk. If you only want Q&A over a small amount of Markdown, a full platform may be unnecessary.

Second, document quality still matters. RAGFlow can improve parsing and chunking, but it cannot magically make low-quality, outdated, or contradictory source material reliable. Knowledge-base governance still matters before production.

Third, model selection directly affects quality. Embedding, rerank, chat, and multimodal model choices all influence retrieval and answer quality. RAGFlow gives you the workflow, but the final result still depends on data, models, and tuning.

Fourth, production deployments need careful attention to permissions and data security. Enterprise knowledge bases often contain internal documents, so deployment model, access control, logs, API keys, and model-provider data policy all need to be designed in advance.

06 Quick Take

RAGFlow’s strength is that it turns the hardest parts of RAG into platform capabilities: complex document parsing, explainable chunking, citation grounding, multi-path retrieval, reranking, model configuration, Web UI, API access, and agent extensions.

If what you need is a verifiable, maintainable enterprise knowledge base that can connect to business systems, RAGFlow is more complete than a “vector database plus a simple chat UI” setup. On the other hand, if you only need small-scale personal Q&A over simple data, a lighter RAG framework may be more resource-efficient.

GitHub project: https://github.com/infiniflow/ragflow
Official docs: https://ragflow.io/docs/dev/
Online demo: https://cloud.ragflow.io