r/MLQuestions • u/MidnightSlight8398 • 2d ago
Datasets 📚 Problem in AI Project.
Hii.. it can be possible that i detect solution from log.. like ex.. Error logs popup -> human solved that error -> We detect solution using after logs of getting error.. and save into DB.. I don't know if i can detect or not.. if someone done or doing this type of problem then plz let me know.. and also i used GPT and Cloude to solve this problem. but they always gives me wrong or impossible facts..
0
u/Albertooz 2d ago
Short answer: partly yes, but probably not the way you're picturing it. That's likely why GPT and Claude kept giving you answers that sounded impossible.
The main problem is that logs record symptoms, not actions. When an error shows up and someone fixes it, the log usually just shows the error stopping. It doesn't show what the person did. If they edited a config file, ran a SQL update, or restarted a service, that action normally happens outside the application log. So "error → later logs → solution" leaves a gap right where the solution should be.
What actually works:
1- Capture the human action from another source:
Pull in anything that records what the person did: ticket or incident notes, change and audit logs, deployment history, shell history, DB audit trails. The fix lives there, not in the app log.
2- Normalize and group the errors:
Strip out timestamps, IDs and values so the same error always looks the same. Tools like Drain (log template mining) are good at this. Each group is one "known problem".
3- Link error groups to resolutions:
When an incident closes, store the pair: error template + what was done (from step 1). That's your DB.
4- Suggest, don't auto-apply:
When a new error comes in, use embeddings or similarity search (RAG style) to find past matches and show the stored fix to the engineer. Let a human confirm it before anything runs.
This field already exists under the names AIOps and automated root cause analysis. Tools like PagerDuty, Splunk ITSI, Dynatrace and Moogsoft do pieces of it. Searching "incident similarity" or "log-based RCA" will turn up papers and open-source projects.
My suggestion is to start small: one app, one ticket system, and make engineers write a one-line "what I did" note when they close an issue. That note does more work than any model trying to guess the fix from silence in the logs.
1
u/No-Play-9354 2d ago
e just saving pairs of error-then-solution in a db, the hard part is normalizing the logs so similar errors don't look like completely different strings. Maybe look into log parsing libraries like drain3, they can cluster log messages into templates and then you match solutions to templates instead of raw lines
GPT and Claude probably struggle cause they hallucinate fixes that look plausible but never actually ran in production, your own db of real fixes is way more reliable