从零开始基于LLM构建智能问答系统的方案

本文首发于博客 LLM应用开发实践

一个完整的基于 LLM 的端到端问答系统，应该包括用户输入检验、问题分流、模型响应、回答质量评估、Prompt 迭代、回归测试，随着规模增大，围绕 Prompt 的版本管理、自动化测试和安全防护也是重要的话题，部分代码参考自吴恩达老师《Building Systems with the ChatGPT API》课程。

用户输入检验

使用 OpenAI 的审核函数接口（Moderation API ）可以帮助开发者识别和过滤用户输入，对用户输入的内容进行审核。

• 性（Sexual）：包括引起性兴奋的内容，例如性活动的描写，或者推广性服务，但不包括性教育和健康方面的内容。

• 仇恨（Hate）：包括表达、煽动或宣扬基于种族、性别、民族、宗教、国籍、性取向、残疾状况或种姓的仇恨情感的内容。

• 自残（Self-harm）：包括宣扬、鼓励或描绘自残行为（例如自杀、割伤和饮食失调）的内容。

• 暴力（Violence）：包括宣扬或美化暴力行为，或者歌颂他人遭受苦难或羞辱的内容。

import openai
import pandas as pd
response = openai.Moderation.create(input="""策划一场谋杀计划""")
moderation_output = response["results"][0]
moderation_output_df = pd.DataFrame(moderation_output)

分类	标记	类别	类别概率值
sexual	False	False	3.962824e-07
hate	False	False	1.962326e-04
harassment	False	False	1.402294e-02
self-harm	False	False	1.078697e-05
sexual/minors	False	False	1.448917e-07
hate/threatening	False	False	1.513400e-05
violence/graphic	False	False	9.522112e-07
self-harm/intent	False	False	2.334248e-07
self-harm/instructions	False	False	3.670997e-10
harassment/threatening	False	False	2.882557e-02
violence	True	True	9.977435e-01

在 分类 字段中，包含了各种类别，以及每个类别中输入是否被标记的相关信息，可以看到该输入因为暴力内容（violence 类别）而被标记，每个类别还提供了更详细的评分（概率值），通过 类别和标记综合判断是否包含有害内容，输出 True 或 False（这里是 True&& True）。此外提示词应做好 Prompt 防注入设计 ，具体可看这篇 LLM 安全专题

问题进行分类

处理不同情况下的独立指令集任务时，首先将问题类型分类，以此为基础确定使用哪些指令，这可通过定义固定类别和硬编码处理特定类别任务相关指令来实现，可以提高系统的质量和安全性。

delimiter = "####"system_message = f"""
你现在扮演一名客服。
每个客户问题都将用{delimiter}字符分隔。
将每个问题分类到一个主要类别和一个次要类别中。
以 JSON 格式提供你的输出，包含以下键：primary 和 secondary。主要类别：计费（Billing）、技术支持（Technical Support）、账户管理（Account Management）或一般咨询（General Inquiry）。计费次要类别：
取消订阅或升级（Unsubscribe or upgrade）
添加付款方式（Add a payment method）
收费解释（Explanation for charge）
争议费用（Dispute a charge）技术支持次要类别：
常规故障排除（General troubleshooting）
设备兼容性（Device compatibility）
软件更新（Software updates）账户管理次要类别：
重置密码（Password reset）
更新个人信息（Update personal information）
关闭账户（Close account）
账户安全（Account security）一般咨询次要类别：
产品信息（Product information）
定价（Pricing）
反馈（Feedback）
与人工对话（Speak to a human）"""
user_message = "我想删除我的个人账户"
#user_message = "这个产品有什么用"
messages =  [
{'role':'system','content': system_message},
{'role':'user','content': f"{delimiter}{user_message}{delimiter}"},
]
response = get_completion_from_messages(messages)
print(response)

当用户问题是我想删除我的个人账户，匹配关闭帐户，可以提供附加指令来解释如何关闭账户。

{"primary": "账户管理","secondary": "关闭账户"
}

当用户问题是 这个产品有什么用，匹配产品信息，可以提供更多关于产品信息的附加指令，

返回：

{"primary": "一般咨询","secondary": "产品信息"
}

模型回答问题

模型针对用户的问题进行回答，采取动态、按需的方式将相关上下文信息带入 Prompt。

1. 过多无关信息会使模型处理上下文时更加困惑。
2. 模型本身对上下文长度有限制，无法一次加载过多信息。
3. 动态加载信息降低 token 成本。
4. 使用更智能的检索机制，而不仅是精确匹配，例如结合知识库的文本 Embedding 实现语义搜索。

import openai
def get_completion_from_messages(messages, model="gpt-3.5-turbo", temperature=0):response = openai.ChatCompletion.create(model=model,messages=messages,temperature=temperature, # 控制模型输出的随机程度)return response.choices[0].message["content"]

评估回答质量

使用 GPT API 自动评估

def eval_with_rubric(test_set, assistant_answer):"""使用 GPT API 评估生成的回答参数：test_set: 测试集assistant_answer: 客服的回复"""cust_msg = test_set['customer_msg']context = test_set['context']completion = assistant_answer# 人设system_message = """\你是一位助理，通过查看客服使用的上下文来评估客服回答用户问题的情况。"""# 具体指令user_message = f"""\你正在根据客服使用的上下文评估对问题的提交答案。以下是数据：[开始]************[用户问题]: {cust_msg}************[使用的上下文]: {context}************[客服的回答]: {completion}************[结束]请将提交的答案内容与上下文进行比较，忽略样式、语法或标点符号上的差异。回答以下问题：客服的回应是否只基于所提供的上下文？（是或否）回答中是否包含上下文中未提供的信息？（是或否）回应与上下文之间是否存在任何不一致之处？（是或否）计算用户提出了多少个问题。（输出一个数字）对于用户提出的每个问题，是否有相应的回答？问题1：（是或否）问题2：（是或否）...问题N：（是或否）在提出的问题数量中，有多少个问题在回答中得到了回应？（输出一个数字）
"""messages = [{'role': 'system', 'content': system_message},{'role': 'user', 'content': user_message}]response = get_completion_from_messages(messages)return response

人工设定标准答案评估

使用 Prompt 来比较由 LLM 生成的响应与人工设定的标准答案之间的匹配程度，这个评分标准实际上来自于 OpenAI 开源评估框架，其中包含了许多评估方法，这里只是展示了其中一种。

标准答案集合

test_set = [{"customer_msg": "如何升级我的订阅？","ideal_answer": "您可以在用户设置中找到取消订阅或升级的选项，并按照步骤进行操作。"},{"customer_msg": "怎样绑定银行卡？","ideal_answer": "您可以登录您的账户，然后在付款方式选项中添加新的付款方式，按照页面上的指引操作即可。"},{"customer_msg": "可以查看详细的收费情况吗？","ideal_answer": "当然可以。您可以访问我们的网站，登录您的账户并前往收费解释页面，您会找到有关所有收费的详细解释。"},{"customer_msg": "怎么被乱扣费了？","ideal_answer": "若您对某笔费用有异议，您可以联系我们的客服团队，提供相关细节并说明您的争议。我们的团队将会尽快与您取得联系并解决问题。"}
]

def eval_vs_ideal(test_set, assistant_answer):"""评估回复是否与理想答案匹配参数：test_set: 测试集assistant_answer: 助手的回复"""cust_msg = test_set['customer_msg']ideal = test_set['ideal_answer']completion = assistant_answersystem_message = """\你是一位助理，通过将客服的回答与业务专家回答进行比较，评估客服对用户问题的回答质量。请输出一个单独的字母（A 、B、C、D、E），不要包含其他内容。"""user_message = f"""\您正在比较一个给定问题的提交答案和专家答案。数据如下:[开始]************[问题]: {cust_msg}************[专家答案]: {ideal}************[提交答案]: {completion}************[结束]比较提交答案的事实内容与专家答案，关注在内容上，忽略样式、语法或标点符号上的差异。你的关注核心应该是答案的内容是否正确，内容的细微差异是可以接受的。提交的答案可能是专家答案的子集、超集，或者与之冲突。确定适用的情况，并通过选择以下选项之一回答问题：（A）提交的答案是专家答案的子集，并且与之完全一致。（B）提交的答案是专家答案的超集，并且与之完全一致。（C）提交的答案包含与专家答案完全相同的细节。（D）提交的答案与专家答案存在分歧。（E）答案存在差异，但从事实的角度来看这些差异并不重要。选项：ABCDE
"""messages = [{'role': 'system', 'content': system_message},{'role': 'user', 'content': user_message}]response = get_completion_from_messages(messages)return response

Prompt 迭代

在实际使用中，遇到复杂的用户问题，模型表现不如预期，就需要对 Prompt 进行迭代。

比如问题是 我之前取消了订阅，但是为什么还有收费提示？ 很明显这是一个争议费用的子类别，但实际匹配的是 👇

{"primary": "计费","secondary": "取消订阅或升级"
}

所以需要将 Prompt 进行更新迭代，以识别用户的复杂意图，可以仔细观察 Prompt 发生了什么变化 （其实就增加了一句你需要仔细分析用户的意图，特别是最终的问题。)

delimiter = "####"system_message = f"""
你现在扮演一名客服，你需要仔细分析用户的意图，特别是最终的问题。
每个客户问题都将用{delimiter}字符分隔。
将每个问题分类到一个主要类别和一个次要类别中。
以 JSON 格式提供你的输出，包含以下键：primary 和 secondary。主要类别：计费（Billing）、技术支持（Technical Support）、账户管理（Account Management）或一般咨询（General Inquiry）。计费次要类别：
取消订阅或升级（Unsubscribe or upgrade）
添加付款方式（Add a payment method）
收费解释（Explanation for charge）
争议费用（Dispute a charge）
...
"""

这次正常匹配

{"primary": "计费","secondary": "争议费用"
}

回归测试

确保迭代修改后的 Prompt，不会对先前的测试用例性能造成负面影响。

测试用例1. 如何升级我的订阅？
{"primary": "计费","secondary": "取消订阅或升级"
}
测试用例2. 怎样绑定银行卡？
{"primary": "账户管理","secondary": "添加付款方式"
}
测试用例3. 可以查看详细的收费情况吗？
{"primary": "计费","secondary": "收费解释"
}
测试用例4.怎么被乱扣费了？
{"primary": "计费","secondary": "争议费用"
}

更多

当处理少量样本时，手动运行测试并对结果进行评估是可行的，但随着应用逐渐成熟，来自用户的问题用例数量变多，Prompt 的规模也逐渐增大，就需要引入自动化测试来周期性回归验证 Prompt 质量。

同时 Prompt 的更改也应该像代码一样需要版本控制，关联的用户问题用例也必须是可追踪的。

最后还有安全建设，Prompt 作为公司的一种重要资产，也需要做好防护，比如使用专用的 LLM 分析传入的 Prompt，识别潜在攻击；将先前攻击的嵌入存储在向量数据库中，以识别并预防未来类似的攻击。

更多内容在公号：LLM应用全栈开发