The question a portfolio visitor has in mind is rarely written in one place on the page: "Which projects used RAG?", "Where does he work now?", "Does he know Elasticsearch?". The answer is spread across the CV, the project pages and the experience rows. Handing this to a general-purpose chatbot brings a different risk: the model can confidently make things up about topics it does not know. On a portfolio, wrong information is worse than none.

I built the "Ask Göktuğ" assistant for the bottom-right corner of this site on a RAG (Retrieval-Augmented Generation) architecture. Before answering, the assistant searched a knowledge base about me and answered only from the passages it found. When the knowledge base had nothing on a question, it said it did not know, and it showed the source each answer was based on.

It answered in Turkish and English and was embedded in the site with a single <script> tag.

SQLite instead of Elasticsearch. The knowledge base was only 29 passages; Elasticsearch alone would need about 1.5 GB of memory. Instead I combined two searches inside SQLite:

1. FTS5 + BM25 — keyword search, with a light stemming step for Turkish
2. Vector search — semantic similarity with a multilingual embedding model
3. Reciprocal Rank Fusion — merges the two rankings into one result list

Exact terms such as "ELK" and questions phrased in different words both found the right passage.

Search local, answers in the cloud. In the first version a local language model on the server generated the answers too, but on a 4-core CPU the first word took 25–50 seconds. After measuring, I moved answer generation to MiniMax through an OpenAI-compatible API, while search and the embedding model stayed on the server. The first word dropped to about 4 seconds on average, and answers streamed at about 54 tokens per second. I filtered the model's "thinking" text out of the stream, so visitors saw only the answer. I wrote about this switch in a separate post.

Measure first. To see what breaks when the knowledge base changes, I wrote a 40-question accuracy test. The latest run passed 39 of 40. Instead of loosening the questions or hard-coding answers to pass, I only improved the knowledge base and the system prompt.

Safe deployment on a shared server. The assistant ran on an 8 GB server that also hosts other sites. The API and model service were reachable only from inside the server; the reverse proxy exposed only the chat, session, status and widget paths, and Prometheus metrics stayed private. Per-visitor and daily global question limits capped both abuse and cloud cost.

Observability. Time to first word, speed and errors for every answer were collected as Prometheus metrics; the latest accuracy test result and live service health were shown on a public status page.

Instead of searching across pages, visitors asked their question directly and got a sourced answer within a few seconds. How accurate the assistant was is not a guess: it was the result of a test rerun after every knowledge-base change.

Even after the speed-up, the assistant still held about 1 GB of memory on the shared server. In October 2026 I shut it down to leave that memory to other work; the code and knowledge base are still there and it can be brought back when resources allow.