Aviation knowledge system
Helping a technical team retrieve answers from documents and training material.
I designed the retrieval workflows, prepared document routes, and built SharePoint synchronization with the technical team.
Keep the document library where the team works
A technician’s answer may be buried in a long manual, inspection record, table, or training item. The Garuda Indonesia technical team wanted a way to search its materials and inspect the source behind a proposed answer. During my AI Engineer internship from November 2025 to May 2026, I designed the Dify and Qwen retrieval workflows, prepared document routes, and built SharePoint synchronization. Teammates owned the Dify infrastructure and the chat website shown in the cover. The project was marked complete on 1 June 2026, after my internship period.
I kept SharePoint as the document entry point. The synchronization path brought changing files into a vector knowledge base so the team did not have to upload each revision into a separate queue. Preparation still required inspection: extracting a PDF, image, spreadsheet, or slide into text can discard the relationship between labels, units, and figures.
Route by material and question
I worked on cleaning, chunking, embedding, and indexing the source material, with separate preparation choices for different file types. A single chunking rule would treat a long manual and a table as if they carried meaning in the same way. OCR and image-aware extraction were explored for scanned material, while tabular files needed care to preserve values with their labels.
The question path had another split. A query against the standing knowledge base depends on indexed documents; a file uploaded with a question belongs to the current interaction. I built routing and retrieval behavior around that distinction, then tuned the Dify workflow and model parameters while checking questions with expected answers.
For complex questions, the route could retrieve relevant passages and pass them to Qwen as context. A separate branch could include a relevant training video when text alone was a poor fit. These branches made the response more useful only if the selected source really answered the question, so I checked mismatches and adjusted preparation and retrieval rather than treating a fluent answer as sufficient.
Give the reader a route back to the source
I designed the workflow through response assembly. It combined model text with source references and, when requested by the route, a formatted video section. The team-built chat UI displayed those results. The cover shows one source-linked answer state; it demonstrates the handoff and interface, not the correctness of every technical statement in the answer.
What the trials can support
In my development trials, I used about 100 documents, roughly 100–500 pages each, and 20 prepared questions per document. I recorded 18–20 answers judged correct out of 20 for a tested document after adjustments. These are my reported trial results, without a held-out corpus or documented scoring rubric. They do not describe general retrieval accuracy or aviation safety.
The trial process did reveal where the work was hardest: preserving meaning during extraction and finding the relevant passage before asking the model to write. A next evaluation would version its questions, document scoring rules and error categories, and have qualified technicians review consequential answers against cited source material. In this setting, the original document and the technician remain the authority; the workflow helps shorten and expose the route to them.