Why LLMs behave the way they do?
Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses
LLMs are great at summarization, but summaries are not great for learning
Many engineers, across all levels, have started relying solely on summaries generated by LLMs to understand any concept. But it does more harm than good.
Learning from summaries is quick and easy. It makes you think that you understood the concept, but one probing question and you will realize how surface-level your understanding was.
Summaries are lossy, which means there is a loss of information (crucial details) when your favorite LLM is summarizing stuff for you. Uncovering that information requires you to ask deep questions to yourself and subsequently to LLMs.
Asking tough questions is tougher, and it requires you to have a deeper understanding of the subject. Deep understanding cannot be built just by reading summaries, which is the new habit in town. Do you see the cyclic dependency here?
Don't get me wrong, summaries are important as they act as a great starting point, but solely on them is catastrophic. So, whenever you find time, grind it out - read books, blogs, papers, docs, and good codebases. Once in a while build projects and prototype the concept.
The depth of understanding separates the best from the better, the better from the good, and the good from the average.
You can find this post on my LinkedIn and Twitter; do leave a like.
By the way,
Being hands-on is the best way for you to learn. Practice interesting programming challenges like building your own BitTorrent client, Redis, DNS server, and even SQLite from scratch on CodeCrafters.
Sign up, and become a better engineer.
📹 Video I posted this week
This week I posted Architecture deep-dive of a Real-time Analytics Database | Rockset Internals
This week, I kicked off an interesting series on the internals of Rockset - a real-time search and analytics database.
The first video of the series is a deep dive into Rockset's architecture and key design decisions that make it horizontally scalable. I covered their ALT architecture and how they leverage RocksDB as their storage layer.
🧠 Paper I read this week
This week I spent reading The Story of AWS Glue
This week I am doing a deep dive into AWS Glue and going through their paper titled "The Story of AWS Glue". To be honest, I got bored reading the first couple of pages, but things got interesting from the 3rd where they touched upon the implementation nuances.
The paper not only talks about the evolution of a large-scale service and some internal details of DynamicFrame, their architecture, boot time optimization, auto-scaling, storage-compute separation, and so much more. The paper is dense but a fun read.
You can download this and other papers I recommend from my papershelf.
Kafka Zero-copy Writes
Kafka is a message broker, and it accepts messages from the network and writes to the disk, and vice versa. The traditional way of moving data from network to disk involves `read` and `write` system calls, which require data to be moved to and from user space to kernel space.
Kafka leverages `sendfile` system call which copies data from one file descriptor to another within the kernel. Kafka uses this to directly transfer data from the network socket to the file on disk, bypassing unnecessary copies.
If you are interested, just read the man page of `sendfile` system call. In most cases, whenever you see something extracting extreme performance a major chunk of it comes from leveraging the right system call.
ps: I used this zero copy while building Remote Shuffle Service for Apache Spark. It proved pivotal in getting a great performance while moving multi-tb data across machines.
You can find this post on my LinkedIn and Twitter; do leave a like.
📰 Interesting articles I read this week
I read a few engineering blogs almost every single day, and here are the three articles I would recommend you to read.
Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses
I keep sharing no fluff stuff across my socials, so, if you resonate do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.
Any insight related to AGI or how would be the future with AGI development?