AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


RAG实战篇:将用户输入转换为精确的数据库查询语言
发布日期:2024-10-03 20:18:29 浏览次数: 1543


前言

在《RAG实战篇:构建一个最小可行性的Rag系统》中,风叔详细介绍了Rag系统的整体实现框架,以及如何搭建一个最基本的Naive Rag。

在前面三篇文章中,风叔分别介绍了索引(Indexing)、查询转换(Query Translation)和路由(Routing)环节的优化方案。

在这篇文章中,围绕查询构建(Query Construction)环节,如下图黄框所示,风叔详细介绍一下如何将用户输入,转换为精准的数据库查询语言。

查询构建主要是为了将用户自然语言的Query,转化为某种特定软件或机器能理解的语言。因为随着大模型在各行各业的渗透,除文本数据外,诸如表格和图形数据等越来越多的结构化数据正被融入RAG系统。

比如在ChatBI的场景下,就需要将用户的Query内容转化为SQL语句,进行数据库查询,这就是Text-to-SQL。如果是在图数据库场景下,那就是Text-to-Cypher。

下面结合源代码,风叔详细介绍下查询构建的三种高级方法,【元数据筛选器】、【Text-to-SQL】和【Text-to-Cypher】具体的源代码地址可以在文末获取。


1. 元数据筛选器

元数据筛选器是一种通过元数据构建筛选器的查询结构,比如增加内容摘要、时间戳、章节引用、文本关键信息、小节标题、段落标签等附加信息来丰富知识库,用于改进知识检索的准确性。这种方法在构建比如知识库助手、智能问答系统时,非常有效。

有一点需要注意,即元数据是不需要被向量化的。因此可以通过元数据筛选器,从自然语言问题中进行快速过滤,如下图所示

我们看一下在 YouTube 转录数据库中的一些示例元数据。

from langchain_community.document_loaders import YoutubeLoader
docs = YoutubeLoader.from_youtube_url( "https://www.youtube.com/watch?v=pbAd8O1Lvm4", add_video_info=True).load()
docs[0].metadata

输出如下所示,将目标数据的元数据全部提取出来,以结构化方式存储。

{'source': 'pbAd8O1Lvm4', 'title': 'Self-reflective RAG with LangGraph: Self-RAG and CRAG', 'description': 'Unknown', 'view_count': 11922, 'thumbnail_url': 'https://i.ytimg.com/vi/pbAd8O1Lvm4/hq720.jpg', 'publish_date': '2024-02-07 00:00:00', 'length': 1058, 'author': 'LangChain'}


假设我们已经建立了一个索引,通过这个索引我们可以对每个文档的内容和标题进行非结构化搜索,并通过查看次数、发布日期和长度范围进行过滤。我们可以为结构化搜索查询构建一个schema,然后将自然语言转换为结构化搜索查询。

给出Prompt,告诉大模型你是将用户问题转换为数据库查询的专家,给定一个问题,返回一个经过优化的数据库查询,以检索最相关的结果。

system = """You are an expert at converting user questions into database queries. \You have access to a database of tutorial videos about a software library for building LLM-powered applications. \Given a question, return a database query optimized to retrieve the most relevant results.
If there are acronyms or words you are not familiar with, do not try to rephrase them."""
prompt = ChatPromptTemplate.from_messages( [ ("system", system), ("human", "{question}"), ])
llm = ChatOpenAI(model="gpt-3.5-turbo-0125", temperature=0)structured_llm = llm.with_structured_output(TutorialSearch)query_analyzer = prompt | structured_llm


我们来检验一下输出结果,成功地将非结构化的自然语言输入,转化成了结构化的输出。

query_analyzer.invoke(    {"question": "videos on chat langchain published in 2023"}).pretty_print()
"""result:content_search: chat langchaintitle_search: 2023earliest_publish_date: 2023-01-01latest_publish_date: 2024-01-01"""


2. TEXT-to-SQL

当前AI大模型输出的SQL准确性还远远无法达到人类工程师的输出精度。由于自然语言表达本身的歧义性和模糊性,在实际应用中,可能会出现无法理解或者错误理解的情况,比如“谁是本月最厉害的销售?”,AI可能会理解成订单数量最多,而不是订单金额最大。

虽然我们可以通过Prompt帮助大模型来理解SQL语句,但AI也可能出现对概念不理解导致的错误,比如“分析去年的客户整体流失率?”,AI可能会因为不理解“流失率”这个概念,而无法给出准确的答复。

总之,TEXT-to-SQL是一个非常有挑战性的领域,还存在准确率不高的问题,因此在使用TEXT-to-SQL的场景下,建议一定要加上人工核对。

下面,我们借助一个例子,看看如何通过RAG系统来优化TEXT-to-SQL。

先准备一个ddl.txt,这里面存放的都是业务范围内容的表结构,如下:

CREATE TABLE ai_prj_plan ( duty_party character varying(255) , pipeline_type character varying(255) , ... );CREATE TABLE dtqjln (  xmbh character varying(100), jgsj integer, ...}


再准备一个documentations.txt ,这里存放的是每个字段的详细说明或者注意事项,如下:

ai_prj_plan 表中的字段 id 表示工程计划的主键 id 。ai_prj_plan 表中的字段 create_time 表示工程计划的创建时间。...dtqjln 表中的字段 jsdw 表示地铁线路或者地铁区间的建设单位名称。dtqjln 表中的字段 sjdw 表示地铁线路或者地铁区间的设计单位名称。


接下来再准备question-sql.txt,这里存放的是一些代表性的业务可能涉及到的问题-sql 对样本,如下:

已经投运的管线工程计划总长###select SUM(length::numeric) from ai_prj_plan where current_progress=5 and plan_type in (1,2,3)查10条计划单独施工的工程名字###select project_name as "ai_prj_plan.project_name"  from ai_prj_plan where plan_type=1 limit 10...


这里的三个文件,每一行都作为一个 doc ,然后将每一行使用预先准备的 acge_text_embedding 嵌入模型转化成1024 向量,也就是三个文件一共有多少行,就会有多少个 1024 的向量,然后都存入ChromaDB 向量数据库。

用户提问“2023年入廊管线中前期项目的计划有多少”,会使用预先准备的 acge_text_embedding嵌入模型,将问题转化为一个 1024 向量,将其与ChromaDB 向量数据库 中的所有1024向量进行相似性召回,分别从三个文件中找出最相关的内容,至于召回策略可以自己定义。

根据自定义召回策略,然后将召回的内容和问题进行拼接组成下面的完整的 prompt ,从完整的 prompt 我们可以看到召回了将要使用的表结构 ai_prj_plan 以及相关字段 plan_type 、annual_aim_json 、plan_category 的使用说明,最后找出了两个可能对模型有用的 question-sql对供模型参考。

[   {'role''system''content''您是一名精通 SQL 的专家,用户会提出业务相关的问题,请根据相关信息回答合适的 SQL ,您将仅使用 SQL 代码进行回答,不进行任何解释。        您可以使用以下展示出的表结构作为参考:\n\nCREATE TABLE ai_prj_plan\n(\n    id character varying(64)  NOT NULL,\n    create_time timestamp(6) without time zone,\n    update_time timestamp(6) without time zone,\n    remark character varying(255) ,\n    plan_type integer,\n    duty_party character varying(255) ,\n    pipeline_type character varying(255) ,\n    project_name character varying(255) ,\n    dlmc character varying(255) ,\n    start_end_point character varying(255) ,\n    ssqx character varying(100) ,\n    total_invest real,\n    length real,\n    plan_code character varying(255) ,\n    plan_category integer,\n    version integer,\n    accept integer,\n    verify_status integer,\n    refuse_reason character varying(255) ,\n    geom geometry(Geometry,4326), -- 几何使用 4326 坐标系\n    years character varying(255) ,\n    current_progress integer,\n    annual_aim_json text ,\n)\n\n        您可以使用以下展示出的 documentation 作为参考,每个 documentation 解释了每个表的字段的名字和用法,使用他们以指导您有效准确地回答用户的问题,请务必遵循每个字段的使用方法和注意事项:\n\nai_prj_plan 表中的字段 plan_type 表示工程计划中涵盖的工程类型,我们规定只能枚举整数 1 、 2 、 3 、 4 、 5 ,整数 1 表示单独施工管线计划,整数 2 表示随道路施工管线工程计划,整数 3 表示入廊管线工程计划,整数 4 表示管廊工程计划,整数 5 表示互联互通工程计划,其中将整数 1 、 2 、 3 代表的三种工程计划合并起来统称为“管线工程计划”或者"管线计划"。\n\nai_prj_plan 表中的字段 plan_category 表示工程计划的计划分类,我们规定只能枚举整数 1 和 2 ,整数 1 表示工程计划在计划内,整数 2 表示工程计划在计划外。\n\nai_prj_plan 表中的字段 annual_aim_json 表示工程计划的每年详细计划列表,虽然该字段是字符串内容,但是存储格式是 json 列表。每个 json 中有三个字段 year、planProgress、 planInvest,表示打算计划在某年(year)给该项目一定的投资(planInvest),要将该项目推进到计划的进度(planProgress)。},    {'role': 'user', 'content': '2024年入廊管线中前期项目的计划有多少'},    {'role': 'assistant', 'content': "SELECT COUNT(*) FROM ai_prj_plan, jsonb_array_elements(annual_aim_json::jsonb) AS aim  WHERE (aim->>'planProgress')::integer = 1 AND plan_category = 1 AND plan_type = 3 AND (aim->>'year')::integer = 2024;"},    {'role': 'user', 'content': '2024年入廊管线中已完成的前期项目有多少'},    {'role': 'assistant', 'content': "SELECT COUNT(1) AS cnt FROM ai_prj_plan, jsonb_array_elements(annual_aim_json::jsonb) AS aim WHERE (aim->>'year')::int = 2024  and (aim->>'planProgress')::int <= current_progress and (aim->>'planProgress') is not null  and plan_type  = 3 and current_progress = 1    and plan_category = 1"},    {'role': 'user', 'content': '2023年入廊管线中前期项目的计划有多少'} ]


最终模型也给我们生成了符合要求的 SQL,初步实现了既定的目标。

Sql:SELECT COUNT(*) FROM ai_prj_plan, jsonb_array_elements(annual_aim_json::jsonb) AS aim  WHERE (aim->>'planProgress')::integer = 1 AND plan_category = 1 AND plan_type = 3 AND (aim->>'year')::integer = 2023;


还有一些开源的方案大家也可以参考,比如vanna和chat2DB。vanna的源码可以参考 https://github.com/vanna-ai/vanna


3. TEXT-to-Cypher

Text-to-Cipher的实现原理和Text-to-SQL类似,只是将SQL执行语句替换图数据库的查询语句。

所以,其Prompt基本上如下所示:

你是一位 GraphDB Cypher 专家,请根据给定的图 Schema 和问题,写出查询语句。schema 如下:---{schema}---问题如下:---{question}---下面写出查询语句:

这里先留一个伏笔,详细的RAG结合图数据库的实现方案,风叔将在后续文章中进行介绍。

将用户输入转换为精准查询语言的三种方案就先介绍到这里。关注【风叔云】公众号,回复关键词【查询构建】,获取完整的源代码。

总结

在这篇文章中,风叔介绍了实现查询构建的具体方法,包括元数据筛选器、TEXT-to-SQL和TEXT-to-Cypher。

在下一篇文章中,风叔将重点围绕检索召回(Retrival)环节,介绍如何优化Rag系统召回的结果。


更多精彩文章:

AI大模型实战篇:AI Agent设计模式 - ReAct

AI大模型实战篇:LATS,可能是目前最强的AI Agent设计框架

RAG实战篇:构建一个最小可行性的Rag系统

RAG实战篇:优化索引的四种高级方法

RAG实战篇:优化查询转换的五种高级方法,让大模型真正理解用户意图

RAG实战篇:精准判断用户查询意图,自动选择最佳处理方案

风叔,某互联网大厂产品总监,十多年产品设计和商业化经验,对电商、营销、AI和大数据产品具备丰富的实战经验。风叔将坚持输出自己的总结和思考,希望对你有帮助。


53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询