Как мы описали 15 000 таблиц за полгода вместо 500 за год и перестали писать документацию вручную
Коротко
- Лучше всего документированы данные DWH; у таблиц аналитиков описания часто неполные, а у сырых данных нередко нет ни документации, ни владельца.
- Для каждого поля Датакаталог сохраняет происхождение описания: ссылку на граф связей, YQL-код, Вики или другой использованный источник.
- При таблицах примерно от 800 колонок или ячейках с крупным JSON контекстное окно переполнялось, поэтому робот уменьшал число строк в образце.
- Качество проверяли отдельной моделью: генератор не оценивал собственный текст, чтобы не завышать семантическое совпадение.
- Следующие этапы — регулярные поставки метаданных, поколоночный lineage и запуск автоописания пользователем прямо из Датакаталога.
Робот на Python собирает путь, схему и образцы таблицы, словари полей, контекст из внутренней Вики, соседние сущности в Memgraph и данные из тех же папок. Затем LLM генерирует заголовок, общее описание и пояснения к полям, причём не сочиняет с нуля: у каждого фрагмента сохраняется источник — граф, YQL, Вики или другие метаданные.
Автоописания используют как черновик для проверки владельцем, как готовую документацию второстепенных сущностей или как способ перенести уже существующий текст из Вики в Датакаталог. Человек больше не начинает с пустой страницы, а редактирует или подтверждает готовый вариант; по оценке команды, это экономит около двух часов на сущность и суммарно дало примерно пять лет рабочего времени аналитиков.
Семантическая сверка показала 92% совпадения с описаниями, проверенными людьми, а 71% полей после валидации оставили без изменений. Для оценки использовали отдельную модель, а на таблицах примерно от 800 колонок или с крупными JSON в ячейках пришлось уменьшать объём выборки, чтобы не переполнять контекстное окно.
FAQ
Зачем Яндексу понадобилось автоматически описывать таблицы, если аналитики и владельцы данных могли делать это вручную?
У многих сырых и аналитических таблиц нет ответственного, а ручное описание не масштабировалось. Метаданные нужны людям для поиска и оценки доверия, а ИИ-агентам — для корректной работы с данными.
Как система снижает риск того, что LLM придумает неверное описание таблицы, её назначения или отдельного поля?
Робот сначала собирает проверяемый контекст из схем, образцов, Вики, YQL и графа связей, а LLM только дополняет его. Для каждого описания сохраняется ссылка на источник.
Читайте также
AI R&D DAY: два трека об исследованиях и продуктизации ИИ- Сначала умрёт интерфейс: что ИИ-агенты сделают с 1С и учётными системами
Чтобы агентная реклама работала, нужно решить, чего ИИ никогда не должен касаться- Бренд-постинг на Reddit и «дофамин» в обмен на данные
OpenAI запускает рекламу в ChatGPT для пользователей Европы
- Заменять написание документации проверкой готового черновика: Для масштабной документации данных эффективнее автоматически создавать первичный текст и просить владельца проверить его, а не начинать с пустой страницы. В кейсе Яндекса такой переход помог увеличить объём с 500 описанных таблиц за год до 15 000 за полгода.
[Процессы документирования]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
#Яндекс
#Россия#Искусственный интеллект#Хабр#AI-агенты#context-engineering#LLM#process-automation#knowledge-graph#context-window#documentation-culture#knowledge-management#graph-db#llm-evaluation#data-engineering#enterprise-llm#data-governance
В Яндексе автоматизировали документацию таблиц: LLM формирует проверяемые черновики из схем, образцов данных, Вики и графа связей, а человек только валидирует результат. За полгода команда описала 15 000 таблиц вместо 500 за предыдущий год.