微信扫码
与创始人交个朋友
我要投稿
在前面三篇文章中,风叔分别介绍了索引(Indexing)、查询转换(Query Translation)和路由(Routing)环节的优化方案。
在这篇文章中,围绕查询构建(Query Construction)环节,如下图黄框所示,风叔详细介绍一下如何将用户输入,转换为精准的数据库查询语言。
查询构建主要是为了将用户自然语言的Query,转化为某种特定软件或机器能理解的语言。因为随着大模型在各行各业的渗透,除文本数据外,诸如表格和图形数据等越来越多的结构化数据正被融入RAG系统。
比如在ChatBI的场景下,就需要将用户的Query内容转化为SQL语句,进行数据库查询,这就是Text-to-SQL。如果是在图数据库场景下,那就是Text-to-Cypher。
下面结合源代码,风叔详细介绍下查询构建的三种高级方法,【元数据筛选器】、【Text-to-SQL】和【Text-to-Cypher】。具体的源代码地址可以在文末获取。
元数据筛选器是一种通过元数据构建筛选器的查询结构,比如增加内容摘要、时间戳、章节引用、文本关键信息、小节标题、段落标签等附加信息来丰富知识库,用于改进知识检索的准确性。这种方法在构建比如知识库助手、智能问答系统时,非常有效。
我们看一下在 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 langchain
title_search: 2023
earliest_publish_date: 2023-01-01
latest_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(\nid character varying(64)NOT NULL,\ncreate_time timestamp(6) without time zone,\nupdate_time timestamp(6) without time zone,\nremark character varying(255) ,\nplan_type integer,\nduty_party character varying(255) ,\npipeline_type character varying(255) ,\nproject_name character varying(255) ,\ndlmc character varying(255) ,\nstart_end_point character varying(255) ,\nssqx character varying(100) ,\ntotal_invest real,\nlength real,\nplan_code character varying(255) ,\nplan_category integer,\nversion integer,\naccept integer,\nverify_status integer,\nrefuse_reason character varying(255) ,\ngeom geometry(Geometry,4326), -- 几何使用 4326 坐标系\nyears character varying(255) ,\ncurrent_progress integer,\nannual_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}---下面写出查询语句:
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-11-23
FastRAG半结构化RAG实现思路及OpenAI O1-long COT蒸馏路线思考
2024-11-23
检索增强生成(RAG):解密AI如何融合记忆与搜索
2024-11-23
如何提高RAG系统准确率?12大常见痛点及巧妙解!
2024-11-23
RAG 2.0性能提升:优化索引与召回机制的策略与实践
2024-11-22
RAG技术在实际应用中的挑战与解决方案
2024-11-22
从普通RAG到RAPTOR,10个最新的RAG框架
2024-11-22
如何使用 RAG 提高 LLM 成绩
2024-11-21
提升RAG性能的全攻略:优化检索增强生成系统的策略大揭秘 | 深度好文
2024-07-18
2024-05-05
2024-07-09
2024-05-19
2024-07-09
2024-06-20
2024-07-07
2024-07-07
2024-07-08
2024-07-09
2024-11-06
2024-11-06
2024-11-05
2024-11-04
2024-10-27
2024-10-25
2024-10-21
2024-10-21