Simone Pellicci

The Architecture of Knowledge: My No-RAG Approach to Corporate Know-How

An on-premise system that transforms documentation into a navigable semantic network, keeping intellectual property strictly under lock and key.

The Problem: Data Sovereignty

In complex industrial realities, know-how is the true strategic asset. The idea of taking technical manuals, machine operating logic, or bills of materials and giving them to an external cloud API has always made me shudder. At the same time, the classic RAG (Retrieval-Augmented Generation) that the market sells as a panacea often limits itself to chopping documents into anonymous fragments scattered in a vector database, losing the general picture. That's why I designed a different architecture, based on a concept of absolute digital sovereignty.

A Custom Pipeline, Not a Ready-Made Package

We're not talking about a pre-packaged solution that installs with two clicks. I developed a custom pipeline capable of taking gigabytes of raw material, from old PDFs to Word files, and transforming them into a structured ecosystem. The engine behind it is an LLM that runs strictly locally, which I "taught" to analyze, deduce, and create semantic connections between files, exactly like an expert technician who connects the dots.

The Engineering Behind the Scenes

Making a model reason about these masses of data, orchestrating connections in the background without losing direction, requires a non-trivial level of engineering and automation. It required proprietary scripts, ironclad classification logic, and surgical hardware tuning. To give you an idea, for the sole phase of massive indexing and structure generation, I had to squeeze every last clock cycle out of an RTX 3090, strictly in undervolt to maintain stability and efficiency under extreme stress.

Daily Use

But the real return on investment and proof that the system works emerge in daily use. Today, if I need to update the knowledge base, I just upload the new document to the chat: the system reads it, understands where it needs to be archived, and generates links to the rest of the corporate network.

Sustainability: Runs on a Normal Office PC

It seems like science fiction or something from American server farms, but the real challenge won is sustainability. If the extreme computational effort – and the skills to manage it – are necessary to build the architecture, for daily use in various departments, a normal office PC is enough. Zero outgoing data, zero cloud subscriptions, zero hallucinations from poorly configured RAG.

Tissue Project: Building an Infrastructure for AI Training

Artificial Intelligence is often seen as a purely software entity, but its true power is expressed when it interacts with the real world. With the "Tissue Project", I am taking a step back towards hardware, building from scratch a physical Proof of Concept to test the integration logic between tangible machines and artificial intelligence models.

Currently in the midst of the design and manufacturing phase, this project represents my personal laboratory for experimenting with the entire data pipeline, from physical structure to future neural processing.

1. The Current Phase: 3D Printing and Modular Design

The starting point is purely hardware. I am designing and printing in 3D (FDM technology) the various components of a modular model.

The challenge I am focusing on today is creating a solid and scalable architecture: I am calculating assembly tolerances and optimizing the pieces for printing, with an eye on structural flexibility. The structure is not an end in itself, but is being prepared from the outset with housings and supports that will later host the visual acquisition modules (cameras).

2. The Next Step: Data Generation and Computer Vision

Once the model assembly is complete, the hardware will become a real "input generator". Having a physical environment at my disposal will allow me to solve the main problem in AI development: the availability of quality datasets.

The goal will be to install cameras on the infrastructure to collect and structure highly specific visual datasets. These raw data flows will become the starting material for training Machine Learning models. This second phase will allow me to test the entire Data Engineering pipeline: from real image acquisition to algorithmic processing.

3. The Next Technical Challenges

The Tissue Project is an open and continuously evolving construction site. Interfacing physical components in development with future AI data flows brings with it several practical challenges that I am already planning:

• Hardware Completion: completing the 3D modeling and FDM printing of all necessary modules to ensure the stability of the infrastructure.
• Dataset Management (future project): planning how to manage the lighting and backgrounds of the test environment, to avoid "contaminating" future visual acquisitions and not transferring bias to the AI model.
• Agnostic Architecture: conceptually designing the system so that, once operational, it can interface flexibly with various automation logics and standard protocols.

It is a 360-degree technical experiment, born to "get my hands dirty" by building the physical foundations necessary to explore Computer Vision and data-driven innovation.

ELIA: an Experimental Assistant for English Study

Studying on online platforms like EF English Live, or practicing pure conversation on apps like Sesame, I realized I was missing unified feedback. Each platform has its strengths, but none can tell you exactly where you're going wrong in the overall picture, contextualizing errors in real-time.

So I decided to use Artificial Intelligence to build a prototype of a personal "tutor": ELIA (English Learning Intelligence Assistant).

How it Works: Providing Context to AI

The idea is to provide an AI model with the necessary information to understand exactly what I'm doing at that moment, acting as an external observer. I structured a web app that, using browser APIs, manages two data streams in the background while I study:

• Screen Capture for visual context: captures screenshots of the page to give the AI information on the grammar or reading exercise I'm working on (e.g., on EF English Live).
• Audio Capture for pronunciation: records my microphone input, essential for analyzing fluency, stumbles, and sentence construction during spoken exercises.

Data Analysis

The collected data is sent to multimodal LLM models. The goal of this proof-of-concept is to create a study companion that can deduce information like: "In the screenshot, I see that the exercise requires the Past Perfect. From your audio, I noticed you hesitated and used the Simple Past. Here's a targeted review."

Work in Progress and Open Challenges

Being a project born to experiment and get hands-on with AI integration, the system is a work in progress and presents several architectural challenges I'm addressing:

• Latency and synchronization: sending both audio streams and heavy screenshots to the LLM sometimes generates a few seconds of delay. Occasionally, I've moved on to the next exercise, but the AI is still processing the previous image, generating out-of-context advice.
• Analysis of fast voice sessions (e.g., Sesame): this is an area I'm working on heavily, and it's definitely in need of improvement. When using pure voice conversation platforms (like Sesame), ELIA still struggles to process the audio and provide useful feedback in a timely manner without interrupting the fast-paced rhythm of the voice bot I'm speaking with.
• Aggressive browser permission management: when I switch tabs or leave the session in the background for a break, Chrome's screen capture permissions often time out, forcing me to reload the streams.

Beyond the practical help with English, ELIA remains an excellent testing ground. Addressing these small integration bugs and learning to manage unstructured data streams to AI model APIs is a practical demonstration of how I like to approach technology: building, testing, breaking, and improving.

How can the effectiveness of an Artificial Intelligence training be objectively measured? Theory suggests testing it on an unknown domain, but engineering practice has taught me the opposite: to validate a model's analytical capabilities, you must first train it on an environment you know perfectly. Only then can you have a ground truth to measure whether the AI is truly reasoning or just hallucinating data.

For this test, I chose a familiar but technically challenging terrain: the closed ecosystem of a private Metin2 server. The goal was to combine my skills in system administration, data engineering, and AI to "open" the black box of the server and transform raw data into a true strategic decision support tool.

1. Extraction: bypassing the anti-cheat

The first obstacle was data acquisition. The server was shielded by anti-cheat protections that prevented data mining on traditional client files.

To bypass the block, I adopted a low-level approach: direct extraction from RAM. By intercepting running processes, I generated an 820MB memory dump. A monolith of fragmented and unstructured data, which hid the server's DNA within.

2. Data Cleaning: building the agent's "mind" with Python

A memory dump is just "noise" for an LLM without a massive processing pipeline. I designed a series of Python scripts to scan dynamically allocated memory, isolate relevant patterns, and discard the rest.

This data engineering phase produced a surgically clean dataset of over 150,000 rows. Inside were the keys to the kingdom:

• Mathematical formulas for exact damage calculation.
• Probability tables (drop rate) for each item.
• Complete statistics, progression mechanics, and hidden balances.

3. Local training: from database to strategist

With the dataset ready, I moved on to the crucial phase: fine-tuning. Consistent with my development philosophy focused on local deployment and data sovereignty, I managed training entirely on my infrastructure.

Using my RTX 3090, I subjected a base model to 3 epochs of training. The goal was not to create a simple search engine for monster statistics: I wanted an agent capable of understanding the "physics" of the game.

The result: a decision support system

The resulting model exceeded expectations. Knowing the original mechanics inside out, I could validate the AI's responses, finding that it didn't just return numbers, but generated genuine insights.

The AI became a Decision Support System (DSS) for the game environment: by querying it, it could calculate the return on investment (ROI) of specific actions, suggest statistically efficient progression paths, and optimize strategies for competitive scenarios.

This project was the field test I was looking for. It concretely demonstrated how a well-structured pipeline — from low-level extraction (system administration) to data cleaning (Python) to fine-tuning (AI) — can transform a chaotic flow of bytes into a "counselor" capable of guiding complex strategic decisions in competitive scenarios. And the applications of this method, outside of gaming, are endless.