Supreme Court of Korea - E-litigation Search and Analysis
Figures
Open full size
Open full size
Open full size
Open full size
Open full size
Open full size
Open full sizeOverview
The Supreme Court of Korea was replacing its electronic litigation search system. The users are judges, clerks and litigants searching case law, judgments and treaties — a domain where a missed result is not an inconvenience but a consequence for someone's case. I owned the NLP and search layer end to end, from requirements analysis and infrastructure design through deployment and post-launch stabilisation. The role had been scoped for an engineer at assistant-manager grade, which at that company required three years and a track record. I was assigned to it on the day I completed my first year.
Why not a rule-based layer
The common approach in comparable systems was a rule-based chatbot sitting in front of search. That works until a user phrases something the rules did not anticipate, and in a legal corpus that is most of the time. I argued for learned query understanding instead, and built it in two parts: SFX (speech act analysis) with SRL to work out what the user was actually constraining — recency, which court, case context — and a BERT-based NER to pull out the entities that matter in law: case numbers, statute names, party names. Where documents resisted clean categorisation, SRL-derived labels were used as the training signal rather than forcing a category that did not fit.
Routing instead of matching
Once entities are tagged into typed fields at index time, a query does not have to be matched against everything. SFX segments it, each term is routed to the field that actually holds that entity type, and the result comes back without scanning the rest. On top of that, vector search handles query expansion and typo correction, so a slightly wrong case number or an unfamiliar phrasing still lands.
Results
Search latency dropped from over five minutes to eight seconds, a 37× improvement, from rebuilding the Java backend algorithms and the indexing pipeline. Fine-tuning the NER and re-indexing improved extraction quality by 4%+. 375+ previously misanalysed cases were resolved. I also set up the Jenkins CI/CD pipelines on GitLab for unit and integration testing through to production deployment.
The feedback loop
Search logs were mined for related and recommended keywords, which fed back into query expansion and the results UI. Supervised tagging (LKWD) degraded results because of errors in the tagging step, so unsupervised LDA with careful preprocessing was used instead — it performed better in a single pass. I also attempted TF-IDF summarisation and was not satisfied with the quality; it stayed unfinished. Administrators got search analytics dashboards — line, bubble and dendrogram charts — so search quality could be monitored rather than assumed.
What I took from it
Because omissions in a court system affect real trials, "good enough on average" was not an acceptable bar. I kept testing and iterating until omissions were eliminated rather than reduced. That is the same instinct I later formalised in my dissertation, where an aggregate metric turned out to be hiding a failure mode, and it is why evaluation work interests me now.