MWS Data Scout Describes Thousands of Database Tables Using LLMs

⚡ The gist in 5 seconds - The MWS Data Scout service describes database tables using LLMs: 8,180 tables from 7 DBMSs in under 3 days. - The author is Sergey Tretyakov, product owner of the service; the article was published on Habr on October 1 in the MWS Cloud / MTS company blog. - A rigidly fixed output format and attaching documentation degrade the quality of descriptions. ### 🔍 What was found Sergey Tretyakov, product owner of MWS Data Scout, explains how the service describes database tables using large language models. The task was originally done manually: seven employees were assigned to describe the Resource Inventory system. In three months they produced 310 data marts — about two tables per person per day, with up to six hours spent on a single table. The reason is that a column name is just a developer's label: a technical field like status_2 could be a payment status, a delivery status, or a migration flag, and this cannot be deduced directly from the schema. The first attempt — feeding the LLM the data structure: table names, column names, and types — produced disappointing results: the model simply paraphrased the schema. So context layers were assembled: 10 random records per table; table classification (Log, Transactional, Directory, Bridge, Summary); domain affiliation (eTOM for telecom, BIAN for finance) or a custom glossary built from the data; plus a parser for Confluence documentation, git repositories, and PDF, DOCX, XLSX, MD, TXT, and HTML files with fragmentation, along with Elasticsearch and hybrid search. Across 1,048 generations for 93 unique tables from three sources, prompt blocks were evaluated with an automated rater (LLM-as-a-judge + CatBoost on a 1–5 scale), a paired t-test, and regression with fixed effects. The task block gave +0.60 (p<0.001), examples +0.51 (p<0.001), output_format −0.08 (p=0.012), and documentation −0.11 (p=0.020). The best quality came from combining context, examples, and documentation, but adding the task block to that mix lowered the overall score. The result was a prompt matrix: a dedicated version at each intersection of table class and business domain. On MTS production databases, 8,180 tables from 7 DBMSs were fully described in under 3 days, about 25 seconds per table. Roughly 80% of the documentation work has been automated, 95% of descriptions are accepted by analysts without edits, and individual employee productivity grew from 30 to 2,000 tables per month. The system processed 634 tables in 33 hours and 4,653 tables in 1.75 hours; these are pure generation times excluding human review. ### 💡 Why it matters The original task was down-to-earth: help an analyst who spends hours each time figuring out which of forty similar tables holds the up-to-date data. The MWS experience shows that the quality limiter is not the volume of context but its composition: you cannot build a prompt on the "throw in everything we have" principle. A prompt for a financial reference table and a prompt for a log of customer clicks are different entities that evolve independently of each other. ### 🧩 Context MWS Data Scout began with a single experiment. When the work started, AI

🔗 Read on habr.com