Professional Project
Odoo 18 Website Auto-Translation
A locally hosted translation platform for an Odoo 18 university website, powered by Ollama and local models.
Professional Project
OstimGPT
OstimGPT is a Retrieval-Augmented Generation chatbot built for OSTİM Technical University. It collects, processes, retrieves and presents information from university sources, with source citations, session management, monitoring dashboards and a layered set of security controls. I contributed across the retrieval pipeline, the caching and session layers, the operations tooling and the security hardening.
Jump to section
Overview
OstimGPT is a Retrieval-Augmented Generation chatbot developed for OSTİM Technical University. It answers questions using content drawn from the university’s own sources rather than from a general-purpose model’s training data, and it shows where each answer came from.
The system runs on locally hosted infrastructure. Everything from collecting source material to serving an answer happens inside the university’s environment, which shaped almost every technical decision on the project.
I worked on this as a member of the development team inside the Digital Transformation Coordination Office. My contributions concentrated on the data and retrieval pipeline, the caching and session layers, the monitoring and diagnostics tooling, and the security hardening of the public-facing endpoints.
Context
A university publishes a large amount of information across many pages: admissions requirements, academic regulations, departmental details, announcements and procedures. That information is accurate but scattered, and finding a specific answer often means knowing which page to look on in the first place.
The Digital Transformation Coordination Office runs internal software projects for the university. OstimGPT was one of those projects: an assistant that could answer questions in natural language while staying anchored to the university’s published sources.
Problem
A general-purpose chatbot cannot answer institution-specific questions reliably, and a chatbot that answers confidently without evidence is worse than no chatbot at all in an academic setting. The system had to be grounded, traceable and safe to expose.
- Answers had to come from university sources, not from a model’s general knowledge.
- Every answer needed to be traceable back to the source it came from.
- The system had to run on locally hosted infrastructure rather than a third-party API.
- It had to be safe to expose to a public audience, which made input handling and abuse control first-order concerns rather than later additions.
- It had to be operable — the team needed to see what the system was doing without reading raw logs.
My Role
My Role
I developed the web crawler that collected content from the university website, added the validation and cleaning applied to that content, and improved retrieval quality by optimising how documents were divided into chunks. I implemented source citation support in responses and a response confidence indicator. I built the in-memory caching layer, user session management with automated session cleanup, and secure UUID-based session tracking. I created the monitoring and administration dashboards, added a health-check endpoint, and developed structured diagnostics and logging. On the security side I implemented request rate limiting, input validation against SQL injection, HTML sanitisation against cross-site scripting, script-injection blocking and per-IP request controls.
Team Context
Team Context
OstimGPT was built by the software development team inside the university’s Digital Transformation Coordination Office, working in sprints under Scrum with CMMI-aligned process standards. I was one contributor on that team. The work described here is the portion I personally implemented; the surrounding platform, its deployment and its broader direction were the team’s shared work, reviewed collaboratively before merging.
Responsibilities
Data collection and retrieval
- Developed a web crawler for collecting university website data.
- Added data validation and cleaning to the collected content.
- Improved retrieval quality through document chunk optimisation.
Answer quality and transparency
- Implemented source citation support in chatbot responses.
- Implemented a response confidence indicator.
Performance and sessions
- Built an in-memory caching system.
- Added user session management with automated session cleanup.
- Used secure UUID-based session tracking.
Monitoring and operations
- Created monitoring and administration dashboards.
- Added a health-check endpoint.
- Developed structured diagnostics and logging.
Security hardening
- Implemented request rate limiting.
- Added input validation against SQL injection.
- Added HTML sanitisation against cross-site scripting.
- Added script-injection blocking.
- Added per-IP request controls.
Technical Approach
The system follows a standard retrieval-augmented pattern, but most of the engineering effort sat in the parts around the model rather than in the model itself: getting clean source material in, dividing it usefully, returning evidence with the answer, and keeping the endpoint safe and observable.
- Collect: a crawler walks university web sources and captures their content.
- Clean: collected content passes through validation and cleaning before it is stored, so malformed or empty extractions never reach the retrieval layer.
- Chunk: documents are divided into retrievable units. Chunk sizing was tuned deliberately, because it determines whether a retrieved passage carries enough context to answer with and few enough unrelated sentences to stay precise.
- Retrieve: a query pulls the most relevant chunks, and the identity of each source is carried through rather than discarded.
- Generate: the model answers from the retrieved context, and the response is returned with its citations and a confidence indicator.
- Serve: requests pass through validation, sanitisation and rate limiting; sessions are tracked with UUIDs and cleaned up automatically; repeated work is served from an in-memory cache.
- Observe: health checks, structured logs and administration dashboards make the running system inspectable.
Architecture
A request flows through validation and rate limiting into a session-aware retrieval pipeline. University content is crawled, cleaned and chunked ahead of time; at query time the relevant chunks are retrieved and passed to a locally hosted language model, which returns an answer together with its source citations and a confidence indicator. Caching, structured logging and health checks sit alongside the request path and feed the monitoring dashboards.
- Ingestion: the crawler collects university web content.
- Processing: content is validated, cleaned and divided into optimised chunks.
- Storage: processed chunks are stored for retrieval with their source identity intact.
- Request: an incoming question passes input validation, sanitisation, per-IP controls and rate limiting.
- Session: the request is associated with a UUID-tracked session; expired sessions are cleaned up automatically.
- Cache: repeated work is served from the in-memory cache where possible.
- Retrieval: relevant chunks are selected for the question.
- Generation: the locally hosted model produces an answer from the retrieved context.
- Response: the answer is returned with source citations and a confidence indicator.
- Observability: health checks, structured diagnostics and logs feed the monitoring and administration dashboards.
Features
Source citations
Answers carry the sources they were drawn from, so a reader can verify a claim rather than trust it.
Confidence indicator
Responses expose a confidence signal, so a weak answer looks different from a strong one.
Web crawler
Collects university web content as the source material for retrieval.
Validation and cleaning
Collected content is validated and cleaned before it can reach the retrieval layer.
Chunk optimisation
Documents are divided so retrieved passages carry enough context without losing precision.
In-memory caching
Repeated work is served from cache instead of being recomputed.
Session management
UUID-tracked sessions with automated cleanup of expired state.
Monitoring dashboards
Administration and monitoring views make the running system inspectable.
Health checks and diagnostics
A health-check endpoint and structured logging support operational awareness.
Security and Reliability
Security controls
- Input validation against SQL injection.
- HTML sanitisation against cross-site scripting.
- Script-injection blocking.
- Request rate limiting.
- Per-IP request controls.
- Secure UUID-based session tracking.
Reliability and observability
- Health-check endpoint for operational monitoring.
- Structured diagnostics and logging.
- Monitoring and administration dashboards.
- Automated cleanup of expired sessions.
- In-memory caching to avoid repeating identical work.
- Validation and cleaning applied to collected data before storage.
Challenges
Crawled web content arrives inconsistent — navigation fragments, duplicate boilerplate and partial extractions mixed in with the text that actually matters.
I added a validation and cleaning stage between collection and storage, so content is rejected or normalised before it can pollute retrieval. Fixing data quality at ingestion is far cheaper than compensating for it at query time.
Chunk size directly changes answer quality, and neither extreme works: large chunks dilute relevance, small chunks lose the context needed to answer.
I treated chunking as something to tune rather than configure once, adjusting how documents were divided and reviewing what the retrieval step actually returned for representative questions.
A chatbot endpoint accepts free-form text from anyone, which makes it an unusually broad input surface.
I treated input handling as part of the feature rather than a later hardening pass: validation against SQL injection, HTML sanitisation, script-injection blocking, rate limiting and per-IP controls were built into the request path.
Running locally meant there was no vendor dashboard to fall back on when something behaved unexpectedly.
I built the observability the project needed: a health-check endpoint, structured diagnostics and logging, and administration dashboards that made the system’s state visible without reading raw log files.
Decisions and Tradeoffs
| Decision | Alternative considered | Why |
|---|---|---|
| Host the language model locally rather than calling a hosted API. | A commercial model API. | University content stays inside university infrastructure, and the system has no external dependency or per-request cost. The cost is that capacity and model choice are bounded by local hardware. |
| Return source citations with every answer. | Return the answer text alone. | In an academic setting an unverifiable answer has little value. Citations let a reader check the claim, and they make wrong retrieval visible instead of silent. |
| Add a response confidence indicator. | Present every response with the same weight. | Uniform presentation encourages uniform trust. Surfacing a confidence signal lets a reader calibrate, which matters most exactly when retrieval has found little to work with. |
| Use an in-memory cache rather than an external cache service. | A dedicated caching service. | It removed a moving part from a locally hosted deployment and was sufficient for the workload. The trade-off is that cached state does not survive a restart or scale across processes. |
Result
The system answers questions from university sources and shows the sources it used, with a confidence signal attached to each response. Sessions are tracked and cleaned up automatically, and repeated work is served from cache.
The security controls I implemented — input validation, sanitisation, script-injection blocking, rate limiting and per-IP controls — are applied on the request path rather than bolted on afterwards.
The monitoring and administration dashboards, health-check endpoint and structured diagnostics give the team a way to see what the system is doing while it runs.
Lessons Learned
- Most of the quality in a retrieval system is decided before the model is involved. Clean source data and well-sized chunks moved answer quality more than anything I did further down the pipeline.
- Citations are an engineering feature, not a presentation detail. Carrying source identity through the pipeline has to be designed in — it cannot be added convincingly at the end.
- Any endpoint that accepts free text needs its input handling designed alongside the feature. Retrofitting validation and sanitisation is more work and leaves gaps.
- Self-hosted systems need their own observability. Building the health check, structured logs and dashboards early made every later problem faster to understand.
Technology Stack
Language
Backend
AI and retrieval
Practices
Screenshots
The chat widget in use: a question about OSTİM’s founding is answered from university sources, and the session closes itself after a period of inactivity.
Let’s discuss your project
Have a software, AI, RAG, or web application project in mind? Let’s discuss what you need and determine the right technical approach.