01-李卫星-企查查字段血缘的大模型实践.pdf

《01-李卫星-企查查字段血缘的大模型实践.pdf》由会员分享，可在线阅读，更多相关《01-李卫星-企查查字段血缘的大模型实践.pdf（17页珍藏版）》请在三个皮匠报告上搜索。

1、企查查字段血缘的大模型实践企查查字段血缘的大模型实践演讲嘉宾：企查查-李卫星01背景：为何要做字段血缘背景：为何要做字段血缘业务痛点与建设目标02核心架构：大模型赋能的技术蓝图核心架构：大模型赋能的技术蓝图基于LLM的解析方案与技术架构03实践与挑战：落地中的应对实践与挑战：落地中的应对准确率、成本与幻觉的工程化应对04总结与展望：价值回顾与未来演进总结与展望：价值回顾与未来演进当前进展与下一步计划01背景背景为何要做字段血缘为何要做字段血缘三大核心场景三大核心场景场景一：需求变更上线前场景一：需求变更上线前核心问题：变更影响范围评估核心问题：变更影响范围评估字段的修改会波及到下游哪些主题宽表

2、、业务指标以及数据看板？缺乏直观的关联视图。业务痛点：变更风险不可控业务痛点：变更风险不可控变更影响范围难以快速量化，依赖经验判断，容易遗漏关键下游链路。场景二：经营指标异常时场景二：经营指标异常时核心问题：数据波动根因定位核心问题：数据波动根因定位结果指标发生变化，到底是源字段数据错误、中间表加工逻辑Bug，还是最终汇总口径定义不一致？业务痛点：排查效率低下业务痛点：排查效率低下问题排查需要逐个核对代码和配置，链路越长耗时越久，影响问题响应速度。场景三：敏感治理审查时场景三：敏感治理审查时核心问题：敏感数据全链路审计核心问题：敏感数据全链路审计敏感字段从产生到消费，经历了哪些节点的清洗、脱敏

3、、映射处理？最终被哪些下游应用所使用？业务痛点：合规风险高业务痛点：合规风险高缺少敏感字段流转的全链路视图，审计时需人工逐一追溯，效率低且有遗漏风险。内部数据资产的独特挑战内部数据资产的独特挑战数据来源复杂数据来源复杂 多源异构：整合工商、司法、招投标、知识产权、舆情等多领域数据，数据模型差异大、更新频率各异。快速变化：数据源更新频率高，字段状态变化（如企业注销、股权变更）需及时同步到下游。ETL ETL 逻辑复杂逻辑复杂 海量吞吐：面临海量数据处理，ETL任务调度链路长、依赖关系复杂。高开发量：业务清洗与关联规则繁琐，自定义代码（Java/Python）开发占比较高。数据治理痛点数据治理痛点

4、 影响难评估：上游源表变更后，无法快速感知下游资产的受影响范围。溯源沟通难：数据质量问题定位链条长，跨团队协作沟通成本高昂。为何选择大模型？传统方案的局限为何选择大模型？传统方案的局限传统血缘工具的局限性传统血缘工具的局限性默认解析粒度粗默认解析粒度粗多数开源工具默认解析到表级别，字段级血缘需额外开发或商业方案支持。依赖人工补充维护依赖人工补充维护字段映射关系常依赖开发者手动注释维护，维护成本高且易遗漏，难以随代码变更实时同步。无法理解业务语义无法理解业务语义能识别技术层面的依赖关系，但缺乏对字段业务语义的理解，血缘图谱对非技术人员可读性差。以以 Flink Flink 为例的技术困境为例的技

5、术困境Apache Calcite Apache Calcite 解析方案解析方案解析精度较高，但配置复杂、学习曲线陡峭，且在含UDF、动态表名等复杂SQL时解析覆盖率有限。官方官方 Flink Lineage API Flink Lineage API作为原生方案集成度好，但截至我们评估时，字段级血缘覆盖不完整，尤其在DataStream API和窗口算子场景。自定义封装自定义封装+规则抽取规则抽取需针对每种算子编写解析规则，灵活性有限，面对频繁变更的业务逻辑，规则维护成本持续增长。依赖运行时审计日志依赖运行时审计日志依赖作业实际运行后才能捕获血缘，无法在上线前进行静态分析，存在治理空窗期。

6、大模型的机遇：为什么大模型的机遇：为什么LLMLLM适合做字段血缘适合做字段血缘自然语言与代码理解能力自然语言与代码理解能力 理解业务逻辑文档、代码注释与字段命名约定 在缺乏显式注释或映射文档时，根据代码上下文辅助推断字段间的关联关系多语言代码解析能力多语言代码解析能力 支持SQL、Java、Python等语言的代码逻辑解析，能处理传统工具难以覆盖的动态逻辑 提取代码中字段的读、写、变换关系，补齐代码开发场景的解析空白补齐传统工具的盲区补齐传统工具的盲区 覆盖Flink DataStream、自定义UDF等传统解析工具难以覆盖的场景 将代码级字段映射转化为可读的血缘关系，降低跨团队沟通成本 核