feat(#384): rename ingestion plugin → chunking strategy in lamb-kb-server

[NoveliaYuki]

Purpose

Rename "ingestion plugin" to "chunking strategy" in the new lamb-kb-server and align the surrounding vocabulary.

In standard RAG terminology, ingestion refers to the full pipeline from an external source into a queryable vector store — i.e. import → chunking → embedding → vector storage end-to-end. The plugins currently called "ingestion plugins" in lamb-kb-server implement only the chunking step; embedding and storage already live in separate plugin families (embedding vendor, vector-DB backend). Calling the chunking-only plugin an "ingestion plugin" misnames it and confuses new contributors.

After this rename, the codebase should consistently:

• use "ingestion" only for the full pipeline / workflow (e.g. ingestion pipeline, ingestion endpoint, ingestion job, ingestion worker, library-only ingestion) — those usages stay as they are; and
• use "chunking strategy" for the individual plugin that performs the chunking step.

The thesis already adopts this convention and the codebase should follow.

Acceptance criteria

• Rename the abstract base class (currently IngestionPlugin or equivalent) and its four subclasses (Simple, Parent-Child, By Page, By Section) to use "ChunkingStrategy" naming
• Rename the plugin directory backend/plugins/ingestion/ (or equivalent) to backend/plugins/chunking/
• Update the plugin registry, registration decorators, and discovery walk
• Update internal docstrings, comments, and CLAUDE.md
• Update the README of lamb-kb-server
• Update test names and test descriptions in backend/tests/
• For HTTP routes and request/response schemas that surface "ingestion plugin" terminology, either rename or expose a backward-compatible alias so existing LAMB backend callers do not break
• Coordinate the LAMB backend's knowledge_store_client.py to use the new field/path names once the server change lands
• Confirm that all remaining uses of "ingestion" in the codebase refer to the full pipeline, not to the chunking-only plugin

Author: @NoveliaYuki

[NoveliaYuki]

Splitting this into two separate issues — one per rename — for cleaner scoping and independent rollout. Will link the replacement issues shortly.

[NoveliaYuki]

Reopening — closed in error. Editing this issue down to only the ingestion plugin → chunking strategy rename, and opening a separate issue for the Knowledge Store → Knowledge Base rename.

[granludo]

why ? ingestion is ingestion and chunking strategy suggests a specific knowledge store architecture ... and we can have many kinds, and i am thinking stores without chunking!

[NoveliaYuki]

I've read some websites and papers that refer to RAG strategies, its use, best practices, etc. I think the wording should be changed because the word ingestion refers to the whole pipeline, the process itself, while chunking and embedding refer to a step in the whole ingestion process:

1. Step 1: get document/URL/youtube URL --> get markdown text (and images if applies) --> save raw markdown. This is the import step, and we can import different types of sources depending on the import plugin we are using.
2. Step 2: get raw markdown --> split text into slices (chunks). This is the chunkingstep, and we can set different chunking parameters and strategies which is what we refer to as chunking strategies.
3. Step 3: get chunks --> convert them to vector embeddings. This is the embeddingstep and where we can choose different embedding models depending on the model and provider chosen.
4. Step 4: get embeddings --> save in vector database. This is the store step and in which we can choose the database we want.

As of now in the source code, comments, functions and variable names we have been referring to ingestion as a combination of steps 1 and 2 . Even in meetings we have had we talked about ingestion without talking about the whole process itself but just a few steps. However, in my opinion and according to many papers I've read, using ingestion to refer to the whole process is the right way.

If you think no rename is needed either way, then I will close this issue as there is no real impact in the code's performance and logic.

[granludo]

the idea is the following a knowledge base server can have MULTIPLE implementation strategies , and many implementations do not require chunking nor embeddings ... so LAMB must see INGESTION -> takes an IMPORTED document with its metadata and FEEDS it to the knowledge base ... Each Knowledge base KIND can have specific pipelines and settings... BUT from the point of view of LAMB there's only
CREATE KNOWLEDGE BASE (or whatever name we give it now) with its SETTINGS (kind, chunking strategy (fixed ofr all the KB) , embeddings engine ..... whatever it chages for every KIND of knowledge base we implement or try )
INGEST (document, metadata)
QUERY (string , Top K)

internally we will have chunking, embeddings and whatever we need.

[granludo]

oh, if you are refering to the OLD knowledge base server ... it will be deprecated, so it does not mater.

[NoveliaYuki]

No, I'm not planning anything for the old kb server as it will be deprecated, we can forget it.

What I mean is that given this new implementation we have:

• Ingestion = library manager (import) + knowledge store (chunking, embeddings, store)
• Retrieval: not in the scope of this issue

I'm trying to align with the standard naming but the logic of the code will remain. If you want for the knowledge store we can come up together with another name to refer to it.