LinkedIn SQL Bot 如何支撑企业取数

虽然为文本到SQL工具创建概念验证很简单，但挑战在于导航复杂的企业数据仓库，以识别能够准确回答用户问题的权威数据源。在这篇文章中，我们分享了关键策略，这些策略使我们能够部署实用的文本到SQL解决方案，目前已被LinkedIn不同业务部门的数百名员工使用。

策略1：高质量的表元数据和个性化检索

文本到SQL通常被构建为检索增强生成（RAG）应用，其中检索表模式、示例查询和其他领域知识等上下文，并将其传递给大型语言模型（LLM）来回答问题。

我们使用基于嵌入的检索（EBR）来检索与用户问题语义相关的上下文。检索表和字段的一个挑战是描述经常缺失或不完整。为了解决这个问题，我们启动了数据集认证工作，为数百个重要的表收集全面描述。领域专家确定其领域内的关键表，并提供必填的表描述和可选的字段描述。这些描述通过基于现有文档和Slack讨论的AI生成注释进行增强，进一步提高了我们检索正确表并在查询中正确使用它们的能力。

另一个挑战是表的数量庞大——在LinkedIn，表数量达到数百万——以及用户问题中隐含的上下文。通过查看访问流行度，我们可以快速将表数量缩小到几千个。然而，处理隐含上下文更为微妙。例如，问题“昨天的平均点击率是多少？”应根据员工对电子邮件通知、广告或搜索质量感兴趣的不同而给出不同的答案。为了解决这个问题，我们根据组织结构图推断用户的默认数据集。我们还对用户-数据集访问历史应用独立成分分析（ICA），以开发对应于不同业务用例的成分（数据集集合）。通过使用与每个用户相关的顶级成分来个性化结果。如果需要，用户可以更改默认过滤器值。

在实践中，表字段会随时间被弃用或添加。一个表通常使用几年，然后被另一个性能、模式或逻辑更好的表所取代。因此，回答问题的真相来源可能会改变。为了自动化选择新表的过程，我们自动将流行的查询表摄入向量存储中。数据枢纽作为我们的元数据搜索和发现工具，它允许用户将数据集和字段标记为已弃用——我们使用这个信号自动卸载数据集和字段。

策略2：知识图谱和LLM用于排名、编写、自我修正

第一个策略的输出是通过过滤和EBR选择的候选表列表。在本节中，我们概述了一些帮助我们生成准确查询的方法。