基于智能搜索和大模型知识库 – 实战篇

背景

在过去的数月中，亚马逊云科技已经推出了多篇 Blog，来介绍如何在亚马逊云科技上构建基于 MVP（LLM+Vector+Prompt）架构打造企业下一代知识库。

为了帮助客户快速、安全地在亚马逊云科技上构建、部署和管理应用程序，众多合作伙伴与亚马逊云科技紧密合作。他们提供各种各样的服务、深入的技术知识、最佳实践和解决方案，包括基础设施迁移、应用程序现代化、安全和合规性、数据分析、机器学习、人工智能、云托管、DevOps、咨询和培训。

最近，亚马逊云科技核心级服务合作伙伴 eCloudrover（伊克罗德） 推出了基于智能搜索和大模型的知识库解决方案——Askture，既拥有经过广泛验证且易于部署的先进 MVP 架构，又提供丰富且高性价比的亚马逊云端资源以优化成本，旨在帮助制造、游戏、电商、客服、教育、法律、医疗等行业快速构建智能企业知识库，打造 AI 时代的领先生产力。

本文主要分享我们在帮助客户使用 Askture 时总结的实战经验和最佳实践。

Askture 架构

Askture 方案架构以及工作流程介绍：

用户划分为三类角色——

• 知识库管理员将通过专用的管理平台进行语料清洗、上传以及资料库管理等操作，可支持的数据格式包括 word、excel、ppt、pdf 等格式。

• 企业内部售前、售后人员等其他角色通过内部搜索平台发起提问，以查询 IT/HR 等企业内部信息。搜索请求将由 Amazon API Gateway 接收，传送至 Amazon OpenSearch 或 Amazon Kendra 向量知识库进行搜索。搜索返回的结果，会通过部署在 AWS Lambda 上的 LangChain 进行提示词工程的处理，再由部署于 Amazon SageMaker 的大语言模型最终产生答案，并返回给用户。

• 对于 C 端用户与客服人员，则可将原有客服系统与 Askture 智问方案融合，用户提出问题时可先由 Askture 进行接管，如遇 Askture 无法解答的提问则可引导客户接入人工客服，据此以简化客服流程，优化客服成本。

Askture 方案先进性

• 架构先进易部署：不用更改脚本和代码，只需重新部署即可更换语言模型和子向量模型，快速、低成本、高灵活构建问答知识库系统。使用 CDK 一键部署，仅需 2-3 天即可上线使用。
• 成本优化：使用 LLM+向量数据库+提示词工程的方案，达到与直接微调 LLM 媲美的效果，降低 90% 左右的研发成本。
• 知识库数据安全隐秘：向量库采用亚马逊云环境的 Amazon OpenSearch，Embedding 和 LLM 模型私有化部署在亚马逊云环境中，用户知识库数据和 LLM 模型交互完全在亚马逊云 VPC 环境中，避免用户知识库数据泄漏给非私有化环境中 LLM 模型，用作其训练资料或者其它用途。
• 答复精准：根据用户输入问题通过精准匹配到数据库中存储的语料片段，再给到大模型处理后，最终给出客户具体的答案和参考文档。
• 良好交互：LLM 理解用户的自然语言输入，与 VDB 交互后返回的搜索结果会由 LLM 进行理解后转述，给予用户贴近自然语言对话的使用体验。

实战

客户背景：

某客户为电子巨头企业，销售的产品包括平面彩电、数码相机、笔记本电脑、耳机、游戏机等，目前在国内的电子业务规模到已经达到 50 亿美元。

客户挑战：

1. 客户现有自动客服系统对话逻辑固定，无法真正理解用户问题意图并做出解答。
2. 企业大量产品使用、维护、售后手册等原始语料无法与现有客服系统整合，售前、售后团队学习原始材料需要较高成本。
3. 客户希望构建能够自然语言对话的智能客服系统，以及可面向企业内部售前、售后人员使用的智能助理系统。

Askture 解决方案：

1. 快速构建基于 OpenSearch + 大语言模型的 RAG 知识库方案
2. 定制化开发数据处理管道、多路召回功能模块与 B/C 端 UI 界面
3. 帮助客户进行语料优化、提示词工程与搜索结果排序调优
4. 构建统一 API 接口规范，协助完成与客户原有系统的对接

客户收益：

1. 快速构建并上线基于 OpenSearch +大语言模型的智能助理系统。
2. 快速且精准地实现自然语言问答，人工座席的接入比例下降近 20%。

Askture 解决方案主要云资源配置：

• Amazon OpenSearch：r6g.2xlarge（1 个节点，100G）
• Amazon SageMaker Endpoint：Embedding (1 * ml.g4dn.2xlarge) LLM (1 * ml.p3.2xlarge/ml.g5.4xlarge)

Embedding 向量模型： bge-large-zh-v1.5

初试选择为 text2vec-base-chinese 模型，经过实际测试，此模型对中文的分词和检索效果不佳，后续采用最新的 SOTA 模型 BGE 向量模型，选择 bge-large-zh-v1.5，效果明显提高。

LLM 模型：Baichuan-7B-chat

初试选择为 ChatGLM-6B 模型，经过实际测试，此模型准确率较低，后续采用最新的 Baichuan-7B-chat 模型，效果明显提高。

知识召回调优：默认采用向量模型召回

向量模型召回：

• 优势：考虑语义相似性，更加智能，无需考虑复杂的传统倒排的调优手段。
• 劣势：对精准匹配支持不足，难以用专业词汇精准召回，对“多词一义”情况的支持不如倒排召回中的同义词表简单直接，需要更多的计算资源。

倒排召回（传统语义搜索）：

• 优势：发展成熟，易达到非常好的 baseline 性能
• 劣势：没有语义信息，对“一词多义”现象解决的不好

增加倒排召回+向量模型召回功能，由于 Amazon OpenSearch 的倒排召回采用的是 BM25 打分体系跟向量召回评分体系不一样，需要对倒排召回结果和向量召回结果做比较后对倒排召回结果评分取一个权重值；此案例中，经过测试，权重值取 0.8，并取倒排召回 Top3 数据和向量召回数据融合后去重。

选用向量召回方式不能得出正确答案

选用多路召回得到正确答案

大语言模型和向量模型的优化，增加向量搜索+传统搜索多路召回功能，将原有的系统识别不出问题和答案进行重新识别和分析，优化后的系统搜索答案的准确率提高了 20% 左右，解决了客户初期测试遇到 80% 问题。

性能优化

应用流程如下：

1. 网络侧

1.1 用户跟 API GATEWAY 交互（Internet/Intranet）

（检查用户获取响应时间和 API GATEWAY 获取结果时间差距 ）

1.2 API GATEWAY 跟 LAMBDA 交互（Internet/Intranet）

（检查 API GATEWAY 获取结果时间和 LAMBDA 完成时间差距 ）

优化：

• 上述 1.1 推荐用 Intranet 方式和离用户就近区域部署方式
• 上述 1.2 推荐用 VPC 部署方式

* API GATEWAY 获取结果时间可以从 API 日志得到，需要打开 API 的详细日志。

2. LAMBDA 侧

2.1 观察 Lambda 函数日志

关注指标为：

• Memory Size（内存大小）– 分配给函数的内存量。
• Max Memory Used（最大内存使用量）– 函数使用的最大内存量。

（在日志显示分配内存跟最大内存一样，已经表明分配内存不够，分配内存应该大于最大内存）

• Duration（持续时间）– 函数的处理程序方法处理事件所花费的时间。
• Init Duration（初始持续时间）– 对于提供的第一个请求，为运行时在处理程序方法外部加载函数和运行代码所花费的时间。

Lambda 处理时间 = Duration + Init Duration

优化：

• 默认分配内存为 128M，在 Lambda 日志观察最大使用内存为 128M，后续设置成 384-512M 后，观察到分配内存始终大于最大使用内存
• Init Duration 使用预置并发优化延迟，在预置并发最小实例内冷启动缩短为毫秒级别，在日志中没有 Init Duration 这项，根据 Cloudwatch 的 ConcurrentExecutions 指标来设置最优预置并发数值，实际环境中设置为 10-20

* 具体如何设置最优预置并发数值，可以参考下面文档：

https://docs.aws.amazon.com/zh_cn/lambda/latest/dg/provisioned-concurrency.html

优化前测试：（单个用户顺序发 10 个请求）

• 有些请求超过 30 秒 Timeout
• 平均请求响应为 16 秒

优化后测试：（单个用户顺序发 10 个请求）

• 请求全部在 30 秒内完成
• 平均请求响应为 7.8 秒
  

• GPU 使用率为 40% 左右，模型延时在 4 秒左右

优化后测试：（3 个用户并发顺序发 10 个请求）

• 平均请求响应为 12 秒（由于 GPU 使用率达到 97% 以上）
  

• GPU 使用率为 97% 以上，模型延时在 8 秒左右

• 可以使用 Application Auto Scaling 来优化 GPU 使用率，减少模型延时时间，扩展实例时间大概需要 5 分钟左右，需要制定好开始启动时间

下面为一个按计划扩展实例配置，根据用户使用高峰时期来按计划扩展，中国时区每天 10，14 点扩展实例为 3 个，12 点，16 点缩减为 1 个。

import pprint
import boto3
from sagemaker import get_execution_role
import sagemaker
import json

pp = pprint.PrettyPrinter(indent=4, depth=4)
region_name = 'us-east-1'
#role = get_execution_role()
sagemaker_client = boto3.Session().client(service_name='sagemaker',region_name=region_name)
endpoint_name = 'pytorch-inference-llm-v1'
response = sagemaker_client.describe_endpoint(EndpointName=endpoint_name)
pp.pprint(response)

resource_id='endpoint/' + endpoint_name + '/variant/' + 'AllTraffic'

#Let us define a client to play with autoscaling options
client = boto3.client('application-autoscaling') # Common class representing Application Auto Scaling for SageMaker amongst other services

response = client.put_scheduled_action(
    ServiceNamespace='sagemaker', #firstly register
    Schedule='cron(0 10,14 * * ? *)', # 10,14 startup every day
    Timezone='Asia/Shanghai', #china timezone
    ScheduledActionName='ScheduledScalingstartup1',
    ResourceId='endpoint/pytorch-inference-llm-v1/variant/AllTraffic',
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    ScalableTargetAction={
        'MinCapacity': 2,
        'MaxCapacity': 2
    }
)

response = client.put_scheduled_action(
    ServiceNamespace='sagemaker',
    Schedule='cron(0 12,16 * * ? *)', # 12,16 stop every day
    Timezone='Asia/Shanghai', #china timezone
    ScheduledActionName='ScheduledScalingstop1',
    ResourceId='endpoint/pytorch-inference-llm-v1/variant/AllTraffic',
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    ScalableTargetAction={
        'MinCapacity': 1,
        'MaxCapacity': 1
    }
)


client = boto3.client('application-autoscaling') # Common class representing Application Auto Scaling for SageMaker amongst other services

总结

通过采用 Askture 方案，企业可直接通过 API 整合内部知识库，并通过采用优化的 VDB 存储实现 50% 以上的成本节约。通过大语言模型提示词工程，以及 RAG 知识库与关键词搜索功能的结合，企业知识库智能问答准确率可达 90% 以上，降低 20% 的人工坐席介入比例，并提升内部客服与技术支持人员检索时效性。

方案详细介绍可通过伊克罗德官方网站链接获取，方案 Workshop 可通过亚马逊云科技官方链接获取。

参考链接

• Askture（智问）解决方案官网：https://www.ecloudrover.com/askture/
• 基于智能搜索的大语言模型增强方案 Workshop：https://catalog.us-east-1.prod.workshops.aws/workshops/486e5ddd-b414-4e7f-9bfd-3884a89353e3/zh-CN/02preinstall/21preinstall

本篇作者