Structured Logs Are Useful, And GPT Make It Easier
ethe.github.io
ethe.github.io
Something is not right with this thesis. Rather than learning the basic tools of their trade, this article encourages developers to reach for the nearest black-box LLM. This approach will certainly not scale, nor be replicable across any system.
The reason grep, awk, and sed are important to learn is because they are universal. Each of those tools, being decades old, is baked into the core fabric of most operating systems today. If you have access to a shell, you can get extremely far with just those 3 tools.
It's worthwhile to spend a couple hours a night for a week or two and become proficient in each. The dividends it will pay over one's programming career will be astonishing.
And I think Text Embedding + LLM is one of the front-end of this tool. The kernel of the idea is post-extract log analysis + in-process OLAP DB + Python playground, I think add grep + awk as its another frontend is also a good idea.
How do you think about? Hope for your reply, thanks.
In the conclusion, the next steps you described were:
- Automatically detect column types
- Parse datetime
This is pretty easy to do with existing tools for a structured data set. What value is there to having an LLM do these tasks? I'm curious about how you might use an LLM for some more interesting use cases.
If you have a situation where there are a variety of datetime formats in a single field, then I can see where an LLM approach could be interesting. But even then, I think the priority is to migrate all of those values to a unified format. After that, add sanitation and validation on the input side and database to make sure all newly entered datetimes are the same format.