待翻译:Different hats I wear as an AI Engineer
AI 服务暂时不可用,以下为来源摘要,待恢复后补全翻译:Hitika Aug 17, 2026 The more I worked with AI systems, the more I noticed a familiar pattern in my own learning: exposure, feedback, mistakes, adjustment, and repetition. Over the past month, I have been interning at a…
AI 服务暂时不可用,以下为来源正文,待恢复后补全翻译。
Hitika Aug 17, 2026 The more I worked with AI systems, the more I noticed a familiar pattern in my own learning: exposure, feedback, mistakes, adjustment, and repetition. Over the past month, I have been interning at a US-based startup as an AI engineer, where I worked across multiple aspects of AI engineering. I got to experience being a beginner again while working on a self-hosted system, which meant fine-tuning my brain on topics like graph databases, Linux-based systems, guardrails, and vLLM. Hat 1: Data Engineer - Finding the Source of Truth To make an AI reduce hallucinations and retrieve information efficiently, it is essential to find the right data sources for training. There are a vast number of public APIs you can pull data from, and each project comes with its own set of decisions: what format to store the data in, whether web scraping is required, what cadence to pull data on, which database to use, and how to manage memory as the source of truth when multiple systems reference the same data. I explored multiple database management systems, understood different schema architectures, and tested several SQL and NoSQL databases, which was a fun problem to solve. Reading documentation and building a small test environment to gauge the feasibility of scaling the system led me down multiple rabbit holes in the open-source world. Turns out graphs are a great way to upgrade your AI to work faster and better. Nodes are the data points, which consist of properties, and edges are the links connecting nodes; they establish relationships between nodes, and since they use hops instead of joins. Graphs are really cool because they don’t have a rigid schema, but for the same reason, they have multiple ways to be stored, which can make them confusing to build. Hat 2: Security and Network Engineer When working on a self-hosted system, you need to ensure that the database, API keys, and the way you log into the server are secured. I worked in a complete Linux-based environment, setting up SSH keys and understanding how public and private key access works when connecting to a server. Setting up a firewall was a first for me. I made sure my SSH port was allowed through the firewall rules before enabling it, so that I would not lock myself out the moment it went live a small step, but one that made me double-check my work before hitting enter. I spent time reading through file permissions using ls-la and learning what chmod 600 and chmod 644 actually mean, realizing that these commands control exactly who can read, write, or execute a file, which helped me configure the .env files while testing the app. I also learned how to work with coding tools such that passwords and API keys don’t end up in the cloud, and reading about how easily secrets can leak into a repo or a log was enough to make me paranoid about making such mistakes. Hat 3: AI practitioner I used Langfuse to track tool usage and debug where an AI agent went wrong, why one query took longer than another, and whether changes to the prompt actually improved context and task performance. Working across local models I found that the mixture-of-experts model with a higher parameter count looked faster but was more prone to hallucination, while the dense model with fewer parameters was slower but beat it on accuracy. This was a useful reminder that parameter count is not a proxy for quality. The model that looked faster during inference was not necessarily the model I wanted for my task. Running models locally also meant understanding GPU memory, RAM allocation, and concepts like KV cache, where previously computed key-value states are stored during generation to reduce repeated computation and speed up inference at the cost of additional memory. Instead of fumbling between dashboards, databases, and documentation, I started using MCP-connected tools to let an agent interact with those systems directly. I also used a Postgres MCP to work across multiple schemas and pull accurate data analytics. As I continue this internship in the fall, I am looking forward to taking up more roles and building on this experience. If you have similar experience working across roles, drop a comment or let’s connect!