RAG on KnightLi Blog

What Is PageIndex? A Reasoning-Based RAG Document Index Without Vector Databases

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex is an interesting RAG project. Instead of starting with “build another vector database,” it first organizes long documents into a tree structure similar to a table of contents, then lets an LLM perform reasoning-based retrieval along that tree.

Project link: VectifyAI/PageIndex

At the time of writing, the GitHub page shows about 31.8k stars and 2.7k forks, with an MIT license. The README positions it as Vectorless, Reasoning-based RAG: RAG without a vector database, based on reasoning.

What Problem It Tries to Solve

The common path for traditional RAG is: chunk the document, vectorize the chunks, store them in a vector database, then retrieve passages by similarity search. This approach is simple, general, and mature, but it often runs into several problems with long professional documents:

Similarity is not the same as true relevance.
Document structure is broken apart by chunking, and section relationships are lost.
Retrieval results are hard to explain, making it difficult to say why a passage was selected.
For financial reports, regulatory filings, legal documents, and technical manuals, questions often require reasoning across sections.

PageIndex takes the opposite route: first organize the document into a semantic tree, then let the model search it like a human reading a table of contents, jumping into sections, and narrowing down to details.

The Basic PageIndex Workflow

The README describes PageIndex retrieval in two steps:

Generate a Table-of-Contents-like tree index for the document.
Perform reasoning-based retrieval through tree search.

This tree is not just a file directory. It is a document structure designed for LLM use. Nodes can contain titles, page ranges, summaries, child nodes, and other metadata. When answering a question, the model does not need to face a pile of fragmented chunks immediately. It can first decide which section to enter, then continue searching downward.

This method is better suited to documents that are well structured but very long, such as:

Financial reports and SEC filings.
Regulatory and compliance documents.
Academic textbooks and papers.
Legal documents.
Technical manuals and product documentation.
Large PDFs that exceed the model context window.

How It Differs From Traditional Vector RAG

PageIndex’s main selling points can be summarized in five areas.

First, it does not require a Vector DB. It relies on document structure and LLM reasoning to locate content, rather than only using vector similarity search.

Second, it does not use traditional chunking. Documents are organized by natural sections instead of fixed-length text fragments.

Third, explainability is stronger. The retrieval path can map back to pages, sections, and tree nodes, making it easier to trace than “this text was hit by vector similarity.”

Fourth, retrieval is context-aware. The question, conversation history, and domain background can all affect the tree search path.

Fifth, it is closer to how human experts read documents. People usually do not cut an entire document into small chunks and calculate similarity; they first inspect the table of contents, locate sections, and then read details.

This does not mean vector databases have no value. A more accurate view is that PageIndex fits scenarios where “semantic similarity is not enough, and structure plus reasoning need to participate” in long-document retrieval.

How to Run It Locally

The README provides a local self-hosting path. First install dependencies:

`1`	`pip3 install --upgrade -r requirements.txt`

Then create a .env file in the project root and write your LLM API key. The project supports multiple models through LiteLLM:

`1`	`OPENAI_API_KEY=your_openai_key_here`

Generate a PageIndex structure for a PDF:

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

Markdown is also supported:

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

Common optional parameters include:

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

The README also notes that the local open-source version uses standard PDF parsing. For complex PDFs, the project’s cloud service provides enhanced OCR, tree building, and retrieval pipelines.

Agentic Vectorless RAG Example

The project also provides an agentic vectorless RAG example using self-hosted PageIndex and OpenAI Agents SDK. Install the optional dependency and run it:

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

The value of this example is that it pushes PageIndex from “generate a document tree” to “let an Agent use the document tree for retrieval.” If you are building an enterprise knowledge base, financial report Q&A, regulatory Q&A, or technical documentation Agent, this example is more worth running than only reading the README.

Cloud Service, MCP, and API

PageIndex is not just a GitHub repo. The project page also lists several entry points:

Self-hosting: run the open-source code locally, suitable for experiments and controlled deployments.
Chat Platform: a ChatGPT-style document analysis platform.
MCP / API: useful for integrating with existing Agents or automation workflows.
Enterprise: for private or on-premises deployment.

This shows that its positioning is not a simple demo. It aims to turn “reasoning-based document retrieval” into an integrable document intelligence infrastructure.

Suitable Scenarios

PageIndex is suitable for tasks such as:

Long PDF Q&A.
Financial reports, annual reports, prospectuses, and regulatory filing analysis.
Legal and compliance document retrieval.
Technical manual Q&A.
Multi-section textbook or paper retrieval.
Enterprise knowledge bases that need explainable retrieval paths.
Providing structured document context to Agents.

If your material is short, has little structure, or is just a normal FAQ, traditional embedding + vector DB may already be enough. PageIndex’s advantages are more likely to appear in long documents, strong structure, professional domains, and questions that require reasoning.

Things to Watch

First, PageIndex still depends on LLMs. Tree building, summaries, and retrieval quality are affected by model capability, prompts, and document parsing quality.

Second, the local version uses standard PDF parsing. Complex scanned documents, chart-heavy PDFs, or messy layouts may require OCR and stronger preprocessing.

Third, vectorless does not mean zero cost. Tree building itself also consumes model calls and time, especially for large-scale document collections.

Fourth, PageIndex is more like a document structure indexing and reasoning retrieval framework. It does not directly replace every RAG stack. In production, it may also be combined with vector retrieval, keyword retrieval, permission control, caching, and audit systems.

Summary

What makes PageIndex interesting is that it shifts RAG from “text similarity retrieval” toward “document structure + LLM reasoning.” For long and professional documents, this direction is worth watching.

If you are building enterprise document Q&A, financial report analysis, regulatory retrieval, or technical manual Agents, PageIndex is a new RAG architecture reference: give documents structure first, then let the model reason along that structure, instead of breaking everything into chunks and putting it all into a vector database from the beginning.

References:

GitHub: VectifyAI/PageIndex

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:

Computer Terms in Plain Language: What TTS, STT, API, RAG, and Agent Really Mean

Tue, 12 May 2026 22:15:34 +0800

Computer science has many terms that sound advanced the first time you hear them. But once translated into plain language, many of them describe everyday actions.

For example, when AI can speak, it is called TTS; when AI can listen to you, it is called STT. It sounds like a complex system, but the simple version is “read text aloud” and “write down speech.”

Reference link: https://www.zhihu.com/question/267978646/answer/2035405228460201515

This article strings together several common terms from that angle: keep the terms themselves, but explain them in plain language.

TTS and STT: Converting Between Text and Speech

TTS means Text-to-Speech. It converts a piece of text into playable audio. Navigation announcements, audiobook reading, AI customer service voices, and voice assistants all use this kind of capability.

STT means Speech-to-Text. It does the reverse: it turns spoken audio into text, then passes that text to the next program. Voice input, meeting transcription, automatic subtitles, and smart speakers all rely on STT.

Many voice AI products are basically this pipeline:

STT: convert what you said into text.
LLM: generate a reply from that text.
TTS: read the reply aloud.

So it may feel like a natural conversation, but underneath, several modules are handing work to one another.

OCR: Copying Text Out of Images

OCR means Optical Character Recognition.

In plain language, it copies text out of images. Taking a photo of an invoice, scanning a page from a book, or reading a name and ID number from an identity document are all OCR tasks.

Early OCR was closer to “guess the character shape.” Modern OCR uses deep learning and is more tolerant of messy backgrounds, tilted text, handwriting, and blurry images. But the core question remains simple: what words are in the image?

NLP and LLM: Letting Machines Handle Human Language

NLP means Natural Language Processing. It deals with human language: tokenization, translation, summarization, sentiment analysis, question answering, classification, and more.

LLM means Large Language Model. It can understand and generate text, so many NLP tasks today are handled by LLMs.

Plain-language version:

NLP: make machines process what people say and write.
LLM: a larger text model that can handle many language tasks.

When you ask AI to summarize an article, write an email, polish a title, or explain code, it all belongs to this broad direction.

API and SDK: One Is an Interface, the Other Is a Toolkit

API means Application Programming Interface.

In plain language, someone exposes an entry point for you to call a capability. A weather API takes a city and returns weather; a payment API takes an order and returns a payment result.

SDK means Software Development Kit.

In plain language, the official team packages common code, types, examples, and tools so you can call the API more easily. An API is like the restaurant counter; an SDK is like the ordering app. You can talk to the counter directly, or use the app to make ordering easier.

CRUD: Create, Read, Update, Delete

CRUD means Create, Read, Update, and Delete.

In plain language: add, view, edit, and delete.

Many admin systems, management systems, and database operations revolve around CRUD. User management, article management, order management, and inventory management may look like different businesses, but underneath they are often forms plus create/read/update/delete operations.

That is why programmers say they wrote “another CRUD.” It is not necessarily dismissive; it is simply very common.

Cache: Keep a Copy So You Do Not Recompute Every Time

Cache means caching.

In plain language, keep frequently used things close by so you can grab them directly next time instead of searching, computing, or requesting them again.

Web pages can cache images and scripts; slow database queries can put hot results in Redis; expensive model inference can cache answers to repeated questions.

The hard part of caching is not “keeping a copy,” but “knowing when to update it.” If the data changes but the cache does not, users see stale data. That is the root of many cache problems.

Queue: Line Up Tasks and Process Them Slowly

Queue means a queue.

In plain language: too many things are happening, so put them in line and process them one by one.

For example, after a user uploads a video, transcoding may not finish immediately. The system can put the job into a queue and let a background service process it later. Sending SMS messages, emails, reports, and order callbacks also commonly use queues.

Queues solve the problem of not blocking the current request with every slow task. The user gets a response first, and time-consuming work happens later.

Index: A Table of Contents for the Database

Index means an index.

A database index is like a table of contents in a book. Without it, you may need to scan from the first page to the last page; with it, you can locate content much faster.

But more indexes are not always better. Queries may become faster, while writes and updates may become slower, because the index also needs to be maintained when data changes.

That is why database optimization often starts with indexes. But when creating one, you still need to consider query conditions, sorting fields, data volume, and write frequency.

RPC, REST, and Webhook: How Systems Talk to Each Other

RPC means Remote Procedure Call.

In plain language, it lets you call a function on another machine as if it were a local function.

REST is common in Web APIs. It uses URLs and HTTP methods to describe operations on resources, such as GET /users to query users and POST /orders to create orders.

Webhook is a callback in the opposite direction. Instead of constantly asking “is it done?”, the other side calls your URL when something happens.

Simple memory aid:

RPC: call a remote function.
REST: manage resources with HTTP.
Webhook: notify you when something happens.

CDN means Content Delivery Network.

In plain language, put static resources on nodes closer to users. When users access images, videos, CSS, or JS, they do not always have to reach the origin server.

Load Balancing means load balancing.

In plain language, when traffic is too high, do not make one server carry everything; distribute requests across multiple machines.

One is about being closer to users; the other is about not exhausting one machine. Large websites usually use both.

Docker, Container, and Kubernetes: Package, Run, and Schedule

Docker is a common container tool, and Container means container.

In plain language, package the program together with its runtime environment so it can run similarly on another machine. This reduces “it works on my computer but not on the server” problems.

Kubernetes, often written as K8s, is a container orchestration system.

In plain language, when there are many containers, it decides where they run, how to restart them if they fail, how to route traffic, and how to roll out versions.

If you only have one small service, Docker may be enough. If you have many services, machines, and replicas, K8s becomes more useful.

CI/CD: Automated Build and Deployment

CI means Continuous Integration.

In plain language, whenever code is submitted, the system automatically pulls the code, runs tests, and builds it to catch problems early.

CD can mean Continuous Delivery or Continuous Deployment.

In plain language, after the build passes, the code is delivered to testing or production environments in a more stable and automated way.

It does not solve “how to write code”; it solves “how to ship code with fewer mistakes.”

Serialization: Pack Objects Into a Transmittable Format

Serialization means turning objects inside a program into a format that can be saved or transmitted, such as JSON, XML, or Protobuf.

The reverse, Deserialization, turns those formats back into objects the program can use.

When frontend and backend exchange JSON, or services exchange Protobuf, serialization is involved.

Token, Embedding, and Vector DB: Turning Text Into Forms Models Can Process

In large models, Token usually refers to the basic units that text is split into. It is not necessarily one Chinese character or one English word; it is more like the model’s internal granularity for processing text.

Embedding means an embedding vector.

In plain language, it turns text, images, or other content into a sequence of numbers so models can compare similarity.

Vector DB means vector database.

In plain language, it stores those vectors and can quickly find content with similar meaning.

For example, if you ask “how do I reset my router?”, the system may search the vector database for content about “factory reset,” “forgot Wi-Fi password,” or “admin login failure,” then pass related materials back to the model.

RAG: Search First, Then Answer

RAG means Retrieval-Augmented Generation.

In plain language, before the model answers, it first searches a knowledge base and then answers with those materials.

It addresses the problem that large models may make things up from memory. By connecting enterprise documents, knowledge bases, product manuals, or code snippets, the model can refer to your latest materials instead of relying only on training memory.

A typical flow is:

The user asks a question.
The system turns the question into an Embedding.
It searches related documents in a Vector DB.
It sends the document snippets and the question to an LLM.
The model generates an answer.

So RAG sounds advanced, but the essence is: look up the materials first, then organize the answer.

Agent: An Automated Flow That Can Break Down Tasks

In AI contexts, Agent often means an intelligent agent.

In plain language, it does not just answer one message. It can break a goal into steps, call tools, observe results, and decide the next action.

For example, if you ask it to analyze why tests fail in a repository, a regular chat model may only give suggestions. An Agent may read files, run tests, inspect errors, edit code, and run tests again.

Of course, Agent does not mean guaranteed reliability. It is essentially “model + tool calling + state loop.” Whether it works well depends on tool permissions, task boundaries, error handling, and human confirmation.

Summary

Many computer terms sound impressive because they are wrapped in acronyms, architecture diagrams, and product copy. Once unpacked, many describe very simple actions:

TTS: read text aloud.
STT: write down speech.
OCR: copy text out of images.
API: expose a calling entry point.
SDK: package calling tools.
CRUD: create, read, update, delete.
Cache: keep a copy of common results.
Queue: line tasks up for later processing.
Index: add a table of contents to data.
CDN: put content closer to users.
Load Balancing: distribute requests.
Docker: package the runtime environment.
CI/CD: automate testing and deployment.
Embedding: turn content into numeric vectors.
RAG: search first, then answer.
Agent: let a model use tools step by step.

The terms should be preserved because they make searching, communication, and documentation easier. But you do not need to be intimidated by them. Translate them into plain language first, then return to the technical details; many concepts become much clearer.

Reference

Zhihu answer: https://www.zhihu.com/question/267978646/answer/2035405228460201515

Gemini Embedding 2: Putting Text, Images, Video, and Audio in One Vector Space

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog introduced how to build with Gemini Embedding 2. The model is now generally available through the Gemini API and Gemini Enterprise Agent Platform. The important point is not simply that it is a new embedding model, but that it maps text, images, video, audio, and documents into the same semantic space.

This broadens what retrieval systems can handle. Many RAG pipelines previously had to convert images, video, or audio into text or metadata before indexing them separately. Gemini Embedding 2 can process multimodal inputs directly, making it easier for agents, search systems, and classifiers to work with real business materials.

Original article: Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

Model Capabilities

Gemini Embedding 2 supports more than 100 languages. A single request can process:

Up to 8,192 text tokens
Up to 6 images
Up to 120 seconds of video
Up to 180 seconds of audio
Up to 6 pages of PDF

Its key idea is a unified semantic space. Developers can place content from different modalities into one vector representation system, then use the same retrieval, clustering, or reranking logic to process it.

For example, a text description and an image can be included in the same embedding request:

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

If you want a separate embedding for each input rather than one aggregated vector, you can use the Batch API. The original article also notes that Agent Platform support for this kind of batch workflow is still in progress.

What It Means for RAG

Multimodal embeddings are useful for agentic RAG. An AI agent may need to inspect a code repository, PDFs, screenshots, charts, audio meeting notes, and product images at the same time. If all of these materials can enter the same semantic space, the retrieval pipeline no longer needs a separate entry point for every format.

Google recommends using task prefixes according to the goal of the task, so the embeddings better match the retrieval objective. For example, question answering, fact checking, code retrieval, and search results can use different prefixes:

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

This kind of prefix is suitable for asymmetric retrieval: user queries are often short, while documents are often long. Formatting query and document differently for the task can improve matching between short queries and long documents.

The original article gives two real-world examples:

Harvey saw a 3% increase in Recall@20 precision on legal retrieval benchmarks compared with its previous embeddings.
Supermemory saw a 40% increase in Recall@1 search accuracy and uses it across memory, indexing, search, and Q&A pipelines.

These numbers do not mean every scenario will improve by the same amount, but they show that multimodal embeddings are already producing results in real retrieval products, not only demos.

Visual Search

Gemini Embedding 2 is also suitable for image-to-image search, image-text hybrid search, and product identification. The original article mentions Nuuly, URBN’s clothing rental company, using it to match photos of untagged garments in warehouses against its catalog. Match@20 improved from 60% to nearly 87%, and the overall successful identification rate rose from 74% to over 90%.

The point in this type of scenario is not content generation, but understanding which inventory item, document, or product record is closest to a given image. If your business has many images, video clips, or scanned documents, multimodal embeddings can be more natural than text-only indexing.

Search Reranking

Embeddings can also be used for reranking. A common approach is to first retrieve a set of candidate results, then calculate the similarity between each candidate and the user’s query, pushing more relevant content to the top:

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

The original article also mentions another idea: first ask the model to generate a baseline hypothetical answer from its internal knowledge, embed that answer, and compare it with candidate content to find the most semantically relevant result. This is especially useful for Q&A-style RAG.

Clustering, Classification, and Anomaly Detection

Beyond retrieval, embeddings are also useful for clustering, classification, and anomaly detection. Unlike the asymmetric question-answering retrieval above, these are symmetric tasks, where the same task prefix can be used for both query and document:

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

These tasks can be used for sentiment classification, content moderation, similar asset grouping, and anomaly discovery. They can also help agents organize large amounts of context before moving into later reasoning steps.

Storage and Cost

Gemini Embedding 2 outputs 3,072-dimensional vectors by default. It uses Matryoshka Representation Learning, so vectors can be truncated to smaller dimensions with output_dimensionality. Google recommends 1,536 or 768 dimensions when efficiency is the priority:

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

Vectors can be stored in Agent Platform Vector Search, Pinecone, Weaviate, Qdrant, ChromaDB, and similar systems. For cost, the original article notes that the Batch API provides higher throughput and reaches 50% of the default embedding price.

How Developers Can Use It

If you already have text-based RAG, you can start with two incremental upgrades:

Put PDFs, screenshots, image descriptions, and text documents into the same index, then test whether retrieval recall becomes more stable.
Add task prefixes for different tasks, such as question answering, fact checking, code retrieval, and product search. Do not process all content with the same embedding format.

If you are building a new product, consider these directions first:

Enterprise knowledge bases: retrieve documents, charts, presentation screenshots, and meeting materials together.
Visual search: use images, text, or mixed inputs to find products, assets, design drafts, and archives.
Agent toolchains: let coding agents, research agents, or customer support agents retrieve business materials in multiple formats.
Content governance: classify, cluster, and detect anomalies across text, images, and video clips.

The value of Gemini Embedding 2 is that it turns multimodal materials into one searchable asset system. For developers, this reduces the need for an intermediate “convert to text, then retrieve” layer and makes RAG systems closer to the shape of real-world data.

How to Choose Common Embedding Models: OpenAI vs BGE vs E5 vs GTE vs Jina

Thu, 23 Apr 2026 15:23:47 +0800

When people start building RAG systems, semantic search, or knowledge base retrieval, they often get stuck on the same question: there are so many embedding models, so which one should you choose?

Common options can roughly be split into two groups. One group is general-purpose text embeddings that cover Chinese, English, and multilingual tasks. The other group is better suited to Chinese scenarios, especially Chinese retrieval, Chinese QA, and Chinese knowledge bases.

If you want the short version first, this is a practical way to think about it:

If you want the easiest path and prefer using an API directly: text-embedding-3-small or text-embedding-3-large
If you want Chinese retrieval and prefer open-source models you can self-host: bge-base-zh-v1.5, bge-m3, gte-large-zh
If you need multilingual support: multilingual-e5-base, multilingual-e5-large, jina-embeddings-v3
If you want to keep costs down in Chinese scenarios: bge-small-zh-v1.5, gte-base-zh

1. First, Look at Them by Category

1. OpenAI Series

text-embedding-3-small
text-embedding-3-large

The main strengths of these models are simplicity and stability. They are a good fit if you want to call an API directly for retrieval, RAG, classification, and similarity matching. Their advantage is not that they dominate one specific Chinese leaderboard, but that the overall experience is complete: low integration cost, stable quality, and low engineering overhead.

If your team does not want to host models or maintain inference services, OpenAI is usually the most time-saving option.

2. BGE Series

BAAI/bge-small-zh-v1.5
BAAI/bge-base-zh-v1.5
bge-m3

BGE is one of the most common families used in Chinese retrieval. bge-small-zh-v1.5 and bge-base-zh-v1.5 lean more toward Chinese monolingual tasks, making them suitable for Chinese semantic search, knowledge base retrieval, and FAQ matching. bge-m3 is more general-purpose and can cover multilingual, multi-granularity, and more complex retrieval scenarios.

If most of your data is Chinese text, BGE is often one of the easiest families to put on the shortlist.

3. E5 Series

intfloat/multilingual-e5-base
multilingual-e5-large

The strength of the E5 family is more balanced multilingual capability. It works well for mixed Chinese-English data, cross-lingual retrieval, and internationalized content libraries. It is not focused only on Chinese. Instead, it is built around the idea that different languages can live inside one unified retrieval system.

If your corpus is not purely Chinese, but a mix of Chinese, English, Japanese, or even more languages, E5 is usually more reliable than a Chinese-only model.

4. GTE Series

Alibaba-NLP/gte-base-zh
gte-large-zh

GTE is also common in Chinese tasks. Its positioning is similar to BGE: both are practical choices for Chinese retrieval. GTE is usually seen as balanced and easy to use, without much complexity in deployment. It works well for Chinese knowledge bases, site search, and enterprise internal document retrieval.

If you want one more open-source Chinese model family for side-by-side evaluation, GTE is well worth testing.

5. Jina Embeddings

jina-embeddings-v3

Jina is more oriented toward general-purpose and modern engineering scenarios, and often appears in multilingual retrieval, long-text processing, and web content tasks. It is frequently mentioned in discussions around using a single model to cover more task types, so it is a good fit for teams that want one unified embedding layer.

If your content sources are mixed, such as webpages, documents, and multilingual text, Jina is often a strong candidate to test.

2. Which Models Are Most Common in Chinese Scenarios

If we narrow the scope to Chinese use cases, the usual candidates are basically these:

bge-small-zh-v1.5
bge-base-zh-v1.5
bge-m3
gte-base-zh
gte-large-zh
multilingual-e5-base
multilingual-e5-large

Among them, the most useful split is not really “which one is absolutely better,” but these three questions:

Is your data primarily Chinese?
Do you need multilingual support?
Do you care more about quality, cost, or deployment convenience?

3. Put These Models Side by Side

1. If You Only Care About Chinese Performance

For pure Chinese knowledge bases, Chinese QA, and Chinese document retrieval, BGE and GTE are usually the first families to check.

bge-small-zh-v1.5: lighter and better for cost-sensitive scenarios
bge-base-zh-v1.5: usually one of the most balanced options for Chinese use cases
gte-base-zh: similar to lightweight BGE and good for building a baseline first
gte-large-zh: better when retrieval quality matters more
bge-m3: suitable if you want to evaluate Chinese retrieval together with broader capabilities

If your corpus is almost entirely Chinese, E5 can still work, but it often will not be the first priority.

2. If You Need Multilingual Support

The priorities change quite a bit here.

multilingual-e5-base and multilingual-e5-large are better suited to unified multilingual retrieval
jina-embeddings-v3 also fits multilingual and general text tasks
bge-m3 is better than traditional Chinese-only models when you want to expand into multilingual usage
text-embedding-3-small and text-embedding-3-large are good if you want the simplest API-based route

If your corpus contains Chinese, English, product documentation, website copy, and user questions at the same time, multilingual models can save you a lot of future migration work.

3. If You Need to Control Inference and Storage Cost

Lightweight models have the advantage here.

bge-small-zh-v1.5
gte-base-zh
multilingual-e5-base
text-embedding-3-small

These models are usually a better fit when:

You have a large document volume
Data is updated frequently
You need batch vectorization
You are sensitive to latency and cost

If your dataset is large, embedding dimensions, inference speed, and index size will all directly affect total cost. That is why starting with a smaller model as a baseline is often the safer choice.

4. If You Want the Highest Ceiling First

Larger models are usually better suited to complex retrieval or higher-quality recall, for example:

text-embedding-3-large
multilingual-e5-large
gte-large-zh
bge-base-zh-v1.5
bge-m3

But one thing to keep in mind is that a larger model does not automatically lead to a better production experience. In many projects, the real bottleneck is not the model itself, but chunking strategy, recall count, reranking, data cleaning, and evaluation design.

4. What Each Model Is Better At

Model	Better suited for	Quick judgment
`text-embedding-3-small`	General retrieval, RAG, fast integration	Simple API usage and cost-friendly
`text-embedding-3-large`	General retrieval where quality matters more	Quality-first and lowest engineering burden
`bge-small-zh-v1.5`	Lightweight Chinese retrieval	A common entry-level Chinese option
`bge-base-zh-v1.5`	Chinese knowledge bases, FAQ, semantic search	Very balanced in Chinese scenarios
`bge-m3`	Chinese-focused setups that also need more complex retrieval	More extensible
`multilingual-e5-base`	Foundational multilingual retrieval	Common in international products
`multilingual-e5-large`	High-quality multilingual recall	More quality-oriented
`gte-base-zh`	Lightweight Chinese retrieval	Good for building a baseline
`gte-large-zh`	Chinese scenarios that prioritize quality	A good comparison point against BGE
`jina-embeddings-v3`	Multilingual, web, and general text tasks	Worth testing if you want one unified embedding layer

5. A Practical Way to Make the Choice

If you are trying to ship a system rather than write a paper, you can keep the decision process simple.

Scenario 1: Chinese Knowledge Base

Start with these:

bge-base-zh-v1.5
gte-large-zh
bge-small-zh-v1.5

If budget is tight, start from the smaller model first. If retrieval quality matters more, then move upward to larger models.

Scenario 2: Mixed Chinese-English Knowledge Base

Start with:

multilingual-e5-base
multilingual-e5-large
text-embedding-3-small
text-embedding-3-large

If you do not want to self-host, OpenAI is the more direct option. If you want to host the model yourself, E5 is the more common path.

Scenario 3: Mostly Chinese Now, but Possibly Multilingual Later

Start with:

bge-m3
multilingual-e5-base
jina-embeddings-v3

The biggest risk in this kind of setup is optimizing only for Chinese at the beginning and then having to rebuild the whole vector database later.

6. In the End, the Key Is Not “Top of the Leaderboard”

The easiest mistake in embedding model selection is to look only at public benchmark scores and then ship directly to production.

A more reliable process is usually:

Pick 2 to 4 candidate models first
Run embeddings on your own real data
Evaluate one round of retrieval performance
Then make the final decision based on cost, latency, and deployment style

Because in practice, what really determines the result is often not the model name itself, but whether the model matches your corpus, chunking strategy, and query patterns.

Summary

If you only want one practical summary to remember, use this:

Chinese-first: start with bge-base-zh-v1.5 and gte-large-zh
Cost-first: start with bge-small-zh-v1.5, gte-base-zh, and text-embedding-3-small
Multilingual-first: start with multilingual-e5-base, multilingual-e5-large, and jina-embeddings-v3
API-first: start with text-embedding-3-small and text-embedding-3-large
If you want Chinese now and flexibility later: start with bge-m3

There is no single model that fits every project, but for most projects, you can quickly narrow down the first batch of candidates from these few groups.

AI Terms Explained: Agent, MCP, RAG, and Token in Plain Language

Thu, 23 Apr 2026 13:13:40 +0800

When people first get into AI, what pushes them away is often not the models themselves, but the long list of terms that keeps showing up in every discussion. Agent, MCP, RAG, AIGC, and Token all look familiar, but without a simple explanation, many people only recognize the words without really understanding them.

This article follows a common beginner-friendly line of explanation and condenses 10 high-frequency AI terms into a set of meanings that is easier to remember. The goal is not to sound academic. It is to help you build a basic mental model that lets you follow everyday AI conversations.

10 common AI terms and what they mean

1. Agent: an AI that does more than chat

Agent can be understood as an AI assistant that actually gets work done.

A normal chatbot usually works in a simple question-and-answer pattern. An Agent goes a step further. It can break a task into steps, arrange a process, call tools, and return a finished result. If you ask it to organize materials, look something up, or generate a document, it may do more than give advice. It may actually chain those actions together and complete them.

That is why the key point of an Agent is not whether it can talk, but whether it can act.

2. OpenClaw: an AI assistant that stays on your computer

Here, OpenClaw is described as a kind of AI assistant that lives on your computer.

You can think of this type of tool as a more desktop-oriented AI helper. It does not only receive text. It may also observe the interface, call local tools, and execute tasks step by step. Compared with a normal web chat interface, this kind of tool emphasizes operational ability much more.

If Agent is the abstract idea of an execution-oriented AI, this kind of desktop assistant is a more concrete personal-computer version of that idea.

3. Skills: capability packs added to an Agent

Skills can be understood as functional modules or operating instructions for an Agent.

The same Agent can behave very differently depending on which Skills it has. Some may focus on copywriting, some on data organization, and some on code-related work. They are a bit like apps on a phone, and a bit like reusable workflows.

So in many cases, it is not that the model suddenly became smarter. It is that a clearer set of rules, tools, and steps was added behind it.

4. MCP: a unified way for AI to connect to tools

MCP stands for Model Context Protocol.

In everyday terms, it is a bit like a Type-C connector for the AI world. In the past, connecting a model to different tools often meant building separate integrations one by one. With a unified protocol, the way those tools connect becomes more standardized and easier to reuse.

For most users, the most important thing to remember is this: MCP is not about whether a model can answer a question. It is about how a model can connect to external tools and resources in a safe and stable way.

5. Gacha: AI output is inherently random

The term “gacha” often appears in AI image generation, video generation, and creative work.

The idea is simple. Even with the same prompt and the same general direction, the result can still be different each time. Sometimes the output is great. Sometimes it falls apart. That is why people compare repeated generation attempts to pulling gacha in a game.

What this really reminds us is that AI generation is not a fixed formula. It is a probabilistic process with variation.

6. API: the connection between an app and a model

API stands for Application Programming Interface.

You can think of it as the standard entry point through which programs communicate. When you call a model service from your own app, script, or editor, you are essentially using an API to send a request and receive a result.

If you compare a model service to a restaurant, then:

the menu is like the API documentation
placing an order is like making an API request
the kitchen sending back the dish is like the model returning a result

That is why many tools may look different on the surface while still calling some form of API underneath.

7. Multimodality: AI handles more than text

Multimodality means AI no longer only reads and writes text. It can process multiple kinds of input and output.

For example, it may be able to read images, understand voice, interpret video, generate pictures, or even support real-time voice and video interaction. Compared with early text-only models, multimodal models are much closer to having the combined abilities to see, hear, speak, and write.

That is also why many AI products are no longer centered around a single text box.

8. RAG: retrieve information first, then generate an answer

RAG stands for Retrieval-Augmented Generation.

It is useful for solving a practical problem: a model’s training data has a time boundary, and it does not automatically know your company’s newest documents, customer-service records, or business rules. The idea behind RAG is to retrieve relevant material from specified sources first, and then generate an answer based on that material.

Its value usually shows up in three ways:

answers are more likely to stay close to real source material
you can trace where the answer came from
new documents can be added and reflected quickly

That is why many enterprise knowledge bases, AI customer-service systems, and internal Q&A tools rely on RAG.

9. AIGC: the general term for AI-generated content

AIGC stands for AI Generated Content.

It is not a single tool. It is a broad label for content produced by AI, including text, images, audio, video, and more. AI writing, AI illustration, AI short-form video generation, and AI voice synthesis all fit under the umbrella of AIGC.

What matters most about this term is that it describes a way of producing content, not one specific model.

10. Token: the unit used to measure model processing

Token can be understood as the basic unit a model uses to process text.

It is not exactly the same as one character or one word, but in practice, you can treat it as the common unit used for model computation and billing. Your input consumes Token, the model’s output consumes Token, and the context kept in memory also takes up Token.

That is why model services keep talking about context length, cost control, and prompt compression. At the core, all of those topics are tied to Token.

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

RAG on KnightLi Blog

What Is PageIndex? A Reasoning-Based RAG Document Index Without Vector Databases

What Problem It Tries to Solve

The Basic PageIndex Workflow

How It Differs From Traditional Vector RAG

How to Run It Locally

Agentic Vectorless RAG Example

Cloud Service, MCP, and API

Suitable Scenarios

Things to Watch

Summary

OpenKB: Compiling Documents into a Continuously Updated LLM Knowledge Base

The Short Version

What OpenKB Is

How It Differs from Traditional RAG

What PageIndex Solves

Install and Quick Start

LLM Configuration

Common Commands

Why a Markdown Wiki Matters

Best-Fit Scenarios

What to Watch Out For

Relationship with Obsidian, NotebookLM, and Enterprise RAG

A Recommended Workflow

Summary

Computer Terms in Plain Language: What TTS, STT, API, RAG, and Agent Really Mean

TTS and STT: Converting Between Text and Speech

OCR: Copying Text Out of Images

NLP and LLM: Letting Machines Handle Human Language

API and SDK: One Is an Interface, the Other Is a Toolkit

CRUD: Create, Read, Update, Delete

Cache: Keep a Copy So You Do Not Recompute Every Time

Queue: Line Up Tasks and Process Them Slowly

Index: A Table of Contents for the Database

RPC, REST, and Webhook: How Systems Talk to Each Other

CDN and Load Balancing: Move Closer and Share the Load

Docker, Container, and Kubernetes: Package, Run, and Schedule

CI/CD: Automated Build and Deployment

Serialization: Pack Objects Into a Transmittable Format

Token, Embedding, and Vector DB: Turning Text Into Forms Models Can Process

RAG: Search First, Then Answer

Agent: An Automated Flow That Can Break Down Tasks

Summary

Reference

Gemini Embedding 2: Putting Text, Images, Video, and Audio in One Vector Space

Model Capabilities

What It Means for RAG

Visual Search

Search Reranking

Clustering, Classification, and Anomaly Detection

Storage and Cost

How Developers Can Use It

How to Choose Common Embedding Models: OpenAI vs BGE vs E5 vs GTE vs Jina

1. First, Look at Them by Category

1. OpenAI Series

2. BGE Series

3. E5 Series

4. GTE Series

5. Jina Embeddings

2. Which Models Are Most Common in Chinese Scenarios

3. Put These Models Side by Side

1. If You Only Care About Chinese Performance

2. If You Need Multilingual Support

3. If You Need to Control Inference and Storage Cost

4. If You Want the Highest Ceiling First

4. What Each Model Is Better At

5. A Practical Way to Make the Choice

Scenario 1: Chinese Knowledge Base

Scenario 2: Mixed Chinese-English Knowledge Base

Scenario 3: Mostly Chinese Now, but Possibly Multilingual Later

6. In the End, the Key Is Not “Top of the Leaderboard”

Summary

AI Terms Explained: Agent, MCP, RAG, and Token in Plain Language

10 common AI terms and what they mean

1. Agent: an AI that does more than chat

2. OpenClaw: an AI assistant that stays on your computer

3. Skills: capability packs added to an Agent

4. MCP: a unified way for AI to connect to tools

5. Gacha: AI output is inherently random

6. API: the connection between an app and a model

3. Check `vm.max_map_count`