Let’s face it, tech conferences are usually a bunch of polished success stories, where everything works out. But one of the presentations at the AWS Community Day Kochi on December 20, 2025 took a refreshing turn.
The event had many fantastic sessions but the one which really stole the show for me was Tech Session provided by Sandeep Kumar Prakash. The title alone was a hook: “LamRAG: 800GB, AI, And Lessons From A Project We Couldn’t Complete.”
It was a masterclass in what happens when big AI dreams run into the hard realities of big data pipelines. If you’ve ever tried to design a generative AI application and felt like you were running into a brick wall, this story is for you.
The Hackathon Dream: Managing a Valorant Roster
The project started off as a hackathon focused on Valorant. In case you don't know, Valorant is a very competitive online multiplayer First Person Shooter (FPS). It’s a 5v5 team arrangement where players can select from 28 different agents and fight on 12 different maps. The stakes are high, with 13 rounds in each game and one life per round for players.
The team's mission sounded simple enough on paper. They wanted to play the role of a team manager. The goal was to construct a chatbot that could develop plans and manage league or region based team identification.
To do this, they needed data. Lots of it.
Data Infrastructure: When Big Data Fights Back
To begin, the team collected three years of data from Valorant games from three separate leagues, for a total of 7,357 individual games. So, all these files were stored by the Amazon S3. They were organised in directories like “vct-challengers”, “vct-international” and “game-changers”.
At start, the total size of the S3 bucket was 101.2 GB, compressed data. That sounds straightforward, right?
The problem with data is that it can be misleading. When they decompress the files, the 101 GB of compressed data increased to an awesome 800 GB of uncompressed data.
They instantly ran into a big barrier. The raw data came in the form of very thick json files. Speaker offered showed a single JSON file with 8.3 million lines of code filled with complex server info and metadata. Trying to open these enormous files locally absolutely crashed their development environments.
The team had to pivot their work flow totally to remedy this. They eliminated local processing and went with amazon lightsail. Amazon Lightsail and VS Code’s Remote-SSH features allowed them to finally get back to a functional and pleasant developer experience without their PCs exploding into flames.
From Raw Data to Strategy: Finding the Signal in the Noise
The team rapidly learned a critical lesson: “Volume!= Value”. The fact that you have 800GB of data does not indicate that it is all valuable to an AI model.
Imagine you are searching for a certain recipe in a huge library. If you just pick up every single book and throw it on your desk you are going to feel overwhelmed. You need an index.
To tackle this, they implemented a data sampling method with Amazon EC2. They started moving data from their ‘raw’ folders to ‘sampling’ folders by year: 2022, 2023, 2024.
Rather than sending the complete game logs into an AI, they started to separate and characterise the data. They isolated some states of the game, including "GAME_STARTED", "ROUND_STARTING", "IN_ROUND" and "GAME_ENDED". After some careful parsing, this chaotic 800GB mess was turned into highly organised, focussed datasets with unambiguous names like map_agent_rounds_stats.json and top_3_combinations_per_map.json.
The data was finally clean, it was structured, it was ready. But as speaker challenged the audience, “Data is ready but how do we use it?
The Knowledge Base Attempt: Why Default RAG Failed
The logical next step for most developers is Retrieval-Augmented Generation (RAG).
So the team turned to Amazon Bedrock to develop a Knowledge Base by connecting straight to their S3 data-source called valorant-player-agent-map-data. They had to decide how to “chunk” or break up the text for the AI. They compare a "Default Chunking" method with a "No Chunking" method, where the data is chunked into vector records of 300 tokens while in the other a complete file is supplied as a single vector record.
They booted up the Claude 3.5 Sonnet base model to try out their bright new Knowledge Base. The prompt was simple: 'make the best squad depending on combat score'.
Now this is were it gets interesting. The AI went crazy.
The reply said there was a player named Meteor with a fighting score of 112,861. Another player, Lakia, was reported to have scored 68,939. Any Valorant player knows these figures are mathematically insane.
The Culprits: Context Hallucination and Numeric Drift
So why did a super powerful AI fail fundamental statistics? Speaker set out two big ideas that all AI developers need to know:
Context Hallucination: Traditional embedding models drop context. The AI didn't understand what a "combat score" actually meant in terms of "damage given". It basically searched for text strings that lived nearby in the database.
Numeric Drift: Vectorising numbers makes them lose their arithmetic value. The numbers are stored only according to their logical context and not their numerical weight.
It was just treating " 112,861 " as if it were a word in a sentence , not a number that should be sorted or calculated.
The Pivot to Agents and Function Calling
Since classic RAG couldn’t handle maths, the team asked a new challenge, “How do we let AI use all the metrics?”
The answer? Function Calling.
Instead of making the LLM read static text, they constructed an Amazon Bedrock Agent called valorant-l4-fn-calling. Again, they used Claude 3.5 Sonnet, but this time they gave it clear instructions that defined the player’s identification (handle, first name, last name) and core metrics (Assists, CombatScore, Games_played). They also formed specific “Action groups” for assignments.
The architecture was fully changed to a much more dynamic system:
Amazon Bedrock acts as the brain.
The LLM invokes an AWS Lambda function with a produced DSL (Domain Specific Language) Query.
AWS Lambda runs the same DSL query against an Amazon OpenSearch database.
OpenSearch returns the hard, calculated data back to Lambda.
Lambda cleans up the data and sends it back to the LLM to format into a human readable answer.
Suppose you order some meals on Swiggy. You’re not asking the app to prepare the food (conventional RAG tries to do the maths). You utilise the app to send a structured request (Function Call) to a restaurant (OpenSearch) and the delivery driver (Lambda) returns the identical result to you.
Cognitive Overload: The Final Roadblock
The architecture was magnificent, but the team ran across one final, impenetrable obstacle.
They were asking the LLM to accomplish far too much at once. The task was to locate the best characters for N maps, then find the best players for these characters, take 5 players and match them to characters on maps, and finally build a strategy.
Speaker called this "Cognitive Overload".
The technical problems came thick and fast:
The Action Group answers could not be more than 25 KB, they had a strict limit.
The system was calling functions many times in the same loop.
Sometimes, the LLM created invalid OpenSearch searches.
Eventually this resulted in a “Frozen” LLM that just hung up and stopped responding altogether.
As the presentation very well concluded, “Everything worked until it worked together.”
Key Takeaways
If you are planning to construct a generative AI application, here are the lessons to learn the most:
Volume does not equal value: 800GB of raw JSON at a problem won’t solve it. You have to clean, sample and format your data before the artificial intelligence can use it efficiently.
Standard RAG can't do math: The point of embedding models is logical similarity, not mathematical accuracy. If you need to sort numbers or discover a “highest score”, by default vector search will likely hallucinate due to numeric drift.
Function calling is your bridge: Instead of having the LLM read a database, employ tools like AWS Lambda and OpenSearch to allow the LLM to query the database.
Beware of cognitive overload: Asking an AI to do complex filtering, matching and generating all in one single command will ruin your system. Divide complicated work into smaller, manageable chunks.
Conclusion
This was a tremendous eye-opener of a session toward the conclusion of the day. We generally prefer to conceive of AI as a sort of magic wand that we can wave over unstructured data and obtain accurate outcomes.
The biggest lesson Sandeep presented was “The Slap On The Face: Don’t teach an LLM what it already knows. If you’re creating AI apps, don’t make a language model do significant statistical calculations or analyse raw databases. Allow the LLM to do what it is best at reasoning and language and leverage function calls to offload the heavy job to your traditional databases.
It was an extraordinary experience to observe the rough, unfinished, and incredibly informative side of building on AWS." Sometimes the tasks we don’t get to finish teach us much more than the ones that go perfectly.
About the Author
As an AWS Community Builder, I enjoy sharing the things I've learned through my own experiences and events, and I like to help others on their path. If you found this helpful or have any questions, don't hesitate to get in touch! 🚀
🔗 Connect with me on LinkedIn
References
Event: AWS Community Day Kochi
Topic: LamRAG: 800GB, AI, And Lessons From A Project We Couldn't Complete
Date: December 20, 2025
Top comments (0)