SOF'CHAT — Local AI Assistant

An assistant that knows when to quote, when to write and when to ask, running entirely on a company workstation

Context: Internship · Sofrecom Tunisie (Orange group)
Role: AI Engineering Intern: design, development, evaluation and deployment
Period: Jul–Aug 2026
Gallery: Applied AI Systems

98.6%of 1,943 stored questions answered word for word

99.96%of 2,235 misspelled variants answered

0answers drawn from the wrong entry

343automated tests, runnable without a model or network

SOF'CHAT in under two minutes: official answers quoted, misspellings understood, a vague question met with a question, the directory, written answers with their sources, then an answer edited in the admin and live in the app on the next question, and the admin's feedback, directory, settings and knowledge base · 1:50

The problem

The company's old chatbot only understood the exact sentences it had been taught. Employees type questions their own way, and on internal rules a wrong answer costs more than no answer at all. The new assistant aims to enhance the work experience, while no internal data leaves the building.

What I built

A fully local retrieval-augmented assistant: model, index and data stay on the workstation.
Every question ends one of three ways: the official answer quoted word for word, an answer written from cited documents, or a clarifying question.
Content is filtered by clearance level before anything is retrieved; organisation questions are computed directly from the HR directory.
A separate admin web interface lets business teams maintain the content, with changes live in under two seconds.

Inside the decisions

Quote, write, or ask

We put quoting first, and not only for trust: on a CPU a written answer takes about twenty seconds, a quoted one about 0.3. When no stored question matches, the assistant writes from validated documents and shows its sources.

The hard part was knowing when not to answer. A query like “le truc pour la chose” still returns twelve results, and the best of twelve poor results can look like an answer. Taken apart, vagueness has a shape in the scores: a real question has a high best match that clearly leads the next one; a vague one gives several mediocre, near-tied results. Requiring both signals flags 89% of vague queries and 2% of real ones, and a real one flagged by mistake gets a question back, never a refusal.

Clean data before tuning

Search quality starts with the phrasings attached to each FAQ entry. Generated by a language model, they had picked up the same office jargon across entries (l'exemple de "booker une room" sat in 89 of 378), pulling unrelated answers together.

I had to build a protection layer so every phrasing passes a five-rule quality gate, whoever writes it, checked in the same vector space as the search. The cut-off, 0.45, is the lowest value that rejects every known polluted case. 3,912 phrasings became 1,564. Fewer and more precise.

Similarity chart: polluted phrasings average 0.13 with 90% below 0.32, legitimate ones average 0.59; a 0.40 cut-off would let 1% of polluted cases through, the chosen 0.45 rejects all of them.

Measured Naturalistic Efficiency

People don't type the way FAQ entries are written, and to actually sit and write all the different possible phrasings, it didn't look optimal. To see how quoting holds up, I wrote a generator of realistic mistakes, 13 kinds from missing accents and SMS abbreviations to neighbouring keys on an AZERTY keyboard, and ran it over every stored question. Sorting the misses by kind showed where to act: greetings before the question, typos, office jargon, misspelled names.

Each got its own answer: greetings set aside before the search, typos tolerated with a Damerau–Levenshtein distance scaled to word length, jargon and abbreviations mapped to canonical words, and a lexical fallback when a misspelled name throws the vector off. In the final evaluation, 99.96% of 2,235 misspelled forms got an answer and 98.6% of the 1,943 stored questions got the official answer word for word, with none drawn from the wrong entry.

Final evaluation: 99.96% of 2,235 misspelled forms answered, 98.6% of 1,943 stored questions answered with the official text word for word, and no answer from the wrong entry.

No pressure, but keep production in mind

From the start, we wanted something the team could keep alive after I left: the core logic depends only on contracts; every external system sits behind one as a replaceable adapter. Access to the live HR database opened on the internship's last day, and the directory was connected through a new implementation of its contract without touching the core or either interface.

Search results are cached with the asker's clearance levels in the key, so a result fetched for one employee can never be served to another, and repeated searches drop from about 600 ms to 0.1 ms. It ships as two Windows installers: one for everyone, offline and without admin rights, with the model trimmed from 6.3 GB to 2.02 GB by reading its manifest; one for administrators only, because whatever they edit becomes the official answer for everyone.

Layered architecture: desktop app and admin interface on top, core logic with eight modules, shared contracts, then replaceable adapters for the local model, vector index, SQLite, HR directory and document ingestion.

The outcome

Every requirement was met except code signing, which belonged to the IT department. The final version, connected to the live HR database, was installed on the workstation of the engineer taking it over, with a production rollout under consideration.

What would come next

A server with a GPU, so written answers stop taking twenty seconds.
Single sign-on instead of name-and-ID login.
A second, independent access check on the answer itself, not only on the search.
Turning collected feedback into corpus improvements, with a model-as-judge to rank answer pairs.
Continuous integration, so the suite runs on every release.