JBang AI Knowledge Base System

JBang AI serves education teams that need more than a place to upload files. Teachers and operations teams needed a system that could organize course materials, ingest them reliably, and make them available to downstream assistants for retrieval and question answering.

The key business shift was moving from passive document storage to an active knowledge workflow. A file only became valuable after it was categorized, parsed, chunked, embedded, and connected to the right bot. That meant the product had to support both day-to-day content management and the longer system path from upload to searchable knowledge.

I worked on the back-end and workflow pieces that made the knowledge base usable in daily operations instead of leaving it as a static file repository.

• Delivered category management and document record modules so knowledge assets could be tracked in a structured way.
• Implemented bot-to-knowledge-base binding so different assistants could target different document collections.
• Participated in the ingestion pipeline from upload metadata to parsing, chunking, vector preparation, and downstream storage.

The upload path could not be tied to the full ingestion workload

Parsing files, extracting text, splitting content, and preparing vectors were all long-running steps. If the product handled that work directly inside the upload request, users would face slow feedback, fragile retries, and an unclear failure surface.

Structured business data and semantic retrieval had different storage shapes

The system had to track categories, document records, tenant boundaries, and bot bindings while also supporting semantic search over processed document chunks. The access patterns were different enough that one storage model would not serve both responsibilities well.

Operators needed visible progress for background work

For non-technical users, a long-running task without status updates feels indistinguishable from a stuck task. The ingestion flow had to show whether work was queued, processing, completed, or failed so teams could trust the system while waiting.

I separated upload acceptance from ingestion execution

The upload request focused on validation, metadata persistence, and task creation. The heavier document processing steps then ran asynchronously in the background. That split kept the UI responsive, reduced the pressure on the request path, and made retries and task handling easier to reason about.

I used MySQL and Milvus for clearly separated responsibilities

MySQL stored the structured business layer: document records, categories, binding relationships, and task metadata. Milvus handled the semantic retrieval layer over processed chunks. This separation matched how the product was used and helped keep management logic distinct from search infrastructure.

I exposed task progress through SSE updates

Instead of forcing operators to refresh or guess what the system was doing, the front end received live task updates through SSE. That made background work more legible: the product could show whether ingestion was waiting, running, or completed, which reduced uncertainty around long jobs.

The workflow I helped implement followed this sequence:

1. Users upload a document and assign it to a category.
2. The system stores metadata and creates an ingestion task.
3. Background processing extracts text, splits content into chunks, and prepares vectors.
4. Structured business data is persisted in MySQL, while vectorized retrieval data is written to Milvus.
5. The front end subscribes to task progress updates through SSE and reflects the current ingestion state in real time.

The biggest lesson from this project was that the value of an AI feature often depends less on the model itself than on the reliability of ingestion, the clarity of system boundaries, and whether users can see the system progressing in a trustworthy way.