Argela Technologies
Istanbul, Turkiye
During my placement at Argela Technologies, I worked in the AI & Software Research team on making the company's AI chat systems faster and more reliable. Modern AI assistants can be slow or inconsistent, especially when many people use them at once or when conversations get long. My job was to measure why this happens and build tools to help the team understand and improve it. I built a live chat tool that shows AI responses appearing word-by-word in real time, then used it to run experiments: testing how response speed changes with longer questions, longer conversations, and multiple users at once, and checking how reliably the AI follows formatting instructions. Building on these findings, I designed and built my own project: a research assistant that answers questions using a company knowledge base, and automatically shows which source backs up each part of its answer, similar to citations in an essay. This makes the AI's answers checkable rather than something you just have to trust, which matters for a tool used internally to support real decisions. Beyond the technical work, this placement gave me real experience of working in a professional research team: presenting findings to colleagues weekly, explaining technical results to non-technical audiences, and taking a project from idea to finished tool on my own initiative. It has shaped my interest in a career between AI research and real-world engineering.
I joined the AI & Software Research team as an intern, researching and presenting core AI topics to the team before taking ownership of my own independent work. I led a connected set of experiments studying how the company's AI system behaves under real-world conditions: how quickly it starts responding, how performance changes as a conversation grows longer, how it copes when many users query it at once, and how reliably it follows formatting instructions. I scoped each experiment myself, built the tools needed to measure it, and presented the results to the team as short demos, so the findings could feed directly into infrastructure decisions. The contribution I am most proud of is a project I proposed and built independently, beyond my original brief: a research assistant that retrieves relevant information from a company knowledge base and automatically shows which source supports each part of its answer. I was responsible for the full journey, from the initial idea, through design and implementation, to presenting a working tool to the team. Throughout, I worked closely with full-time researchers and fellow interns, sharing tools and findings so others could build on my work, and drawing on their insights to interpret my own results. I also took part in daily standups, flagging progress and blockers, which shaped how I communicate as part of a team.
Python (async/await, FastAPI, WebSocket/SSE) for building real-time streaming clients and internal tooling. Working directly with a production LLM inference system, including designing and running latency/throughput benchmarks, measuring time-to-first-token, and testing behaviour under concurrent load. Retrieval-augmented generation (RAG): vector databases (Qdrant), embeddings, and cosine-similarity search to retrieve relevant context for an LLM. Prompt engineering and structured-output design, including validating JSON outputs and testing instruction-following reliability. Building an automated claim-evidence mapping and citation system to make LLM answers traceable to their sources. Data analysis and visualisation to turn raw benchmark results into clear, presentable findings. Technical communication: translating systems-level concepts into clear presentations for both technical and non-technical audiences.
This placement developed my ability to scope work independently, learning to define a measurable hypothesis and plan an experiment before writing any code, rather than diving straight into implementation. Weekly presentations pushed me to communicate quantitative results clearly to a technically sophisticated audience, while explaining the same work to non-technical stakeholders taught me to anchor explanations in observable outcomes rather than underlying mechanisms. I also grew more comfortable working autonomously within a team, taking ownership of my own experiments while staying connected to colleagues through shared infrastructure and regular review. Daily standups built a habit of articulating progress concisely and flagging blockers early, and I learned the value of sharing tools and findings for others to build on, while drawing on colleagues' insights to interpret my own results. Proposing and delivering a project beyond my original brief, from idea through to a finished, presented tool, strengthened my initiative and my ability to manage time and priorities across ongoing experiments and presentation deadlines.