LM+Embedding构建问答系统的局限性及优化方案

原文:LLM+Embedding构建问答系统的局限性及优化方案 - 知乎

近期 LangChain + LLM 方案高速发展,降低了知识问答等下游应用的开发门槛。但随着业务深入,一些局限性也日渐显露,比如:LLM意图识别准确性较低,交互链路长导致时间开销大;Embedding 不适合多词条聚合匹配等。本文结合实际案例,分析上述问题存在的根源,并提出基于传统 NLP 技术的解决思路。

背景

笔者在基于大语言模型构建知识问答系统一文中描述了,以 LLM 为基础的知识问答系统构建方法,核心在于:

  • 将用户问题和本地知识进行 Embedding,通过向量相似度(Vector Similarity)实现召回;
  • 通过 LLM 对用户问题进行意图识别;并对原始答案加工整合。

原文通过 OpenAI API 和ChatGPT 交互,缺陷也很明显:

  • 上层应用和模型基座绑死。切换模型基座时,上层逻辑不得不大量修改。在 LLM 蓬勃发展的当下,无论是处于成本、License、研究热点还是性能等各方面考虑,基座变更几乎不可避免。
  • 处理环节不完善,开发成本高。比如:向量存储和搜索,LLM 提示词生成,数据链路(导入、分片、加工)等等。如果全部手撸,成本过高。
  • 缺少标准化。轮子不但要丰富还要标准化,以结合场景灵活编排。一个粗浅的比喻是——我们需要 “乐高” 。

LangChain 的诞生就是解决这些问题的,它抽象了业务应用和LLM 交互的方式,内置通用环节实现,标准化工具链交互接口,极大提升开发效率。LangChain 的大致结构如下所示:

LangChain 应用示意图

基于LangChain + LLM 的组合,下游应用在:“场景拓展” 和 “效能提升”方面取得长足进步,但垂直领域一些深层问题也逐渐暴露出来。本文就开发问答系统时遇到的实际案例,说明上述方式的局限性,并提出解决方案。

局限性分析

问题简介

首当其冲的是:多知识点聚合处理场景下,Embedding-Search 召回精度较低 的问题。典型应用范式是:

  • 一个仓库有 N 条记录,每个记录有 M 个属性;
  • 用户希望对 x 条记录的y 个属性进行查询、对比、统计等处理。

这种场景在游戏攻略问答中很常见,以体育游戏 NBA2K Online2 为例:

# 多知识点——简单查询
Q: 皮蓬、英格利什和布兰德的身高、体重各是多少?

# 多知识点——筛选过滤
Q: 皮蓬、英格利什和布兰德谁的第一位置是 PF?

# 多知识点——求最值
Q: 皮蓬、英格利什和布兰德谁的金徽章数最多?

Embedding 缺陷

原始的 Embedding Search在面对多知识点聚合处理时,存在几个问题:

1. 本地知识建立索引时,通常对单个知识点进行 Embedding;不会也不可能,为不同知识点的排列组合分别制作索引。不难想象,不同记录和属性的组合方式有 C⋅ANx⋅AMy (C问题数,如过滤,查询,最值;A 即排列),所有组合都建立索引的开销是巨大的。

2. 原始问题直接 Embedding ,和单条知识点的向量相似度比较低。为了避免召回结果有遗漏,就需要 **降低** 相似度评分下限(vector similarity score threshold),同时提高召回结果数量上限(top k)。并产生不好的副效应:

  • 召回结果,有效信息密度大幅降低;score threshold 过高或 top k 过低,会导致某些有效知识点无法命中;反之,很多无效知识点或噪声会被引入。且由于总 token 数量的限制,导致本地知识点被截断,遗漏相似度较低但有效的知识点。
  • 召回结果的膨胀,增加了和 LLM 交互的 token 开销;增加了 LLM 处理的时间复杂度。再直白点:既慢又花钱。
  • 更糟糕的是,给 LLM 的分析处理带来额外噪声,影响最终答案的正确性。

下面给出一个示例:

  • 问题是:*皮蓬、英格利什和布兰德谁的推荐位置是什么?* 这句话中的关键词是:三个球员“姓名”和属性“位置”。
  • 召回结果如下所示:按照相似度降序排列。依次是:姓名、位置单词条命中;多姓名同时命中;位置命中。实际上,中部信息是冗余的。

再看看 LLM( ChatGLM-6B )对召回结果整合后的反馈,耗时 16s 用于处理大量输入,结果让人啼笑皆非:

皮蓬、莺利什和布兰德的推荐位置是前锋/后卫。

几处很明显的错误:英格利什莫名其妙变为莺利什;且三人的位置回答不准确,由于过多冗余信息导致混淆。也许和 LLM 自身的性能有关,但也能说明 Embedding Search 低效且不可靠

方案分析

针对上面的问题重新整理思路,想要更加精准的回答问题,需要从两个层面入手:

1. 问题理解——准确识别用户意图

这是问答系统的基础:通过解析用户问题,精准把握意图后,才能更好的规划后续处理步骤:

  • 根据意图,制定计划,拆分为若干步骤;在每个步骤选择合适的工具进行处理;根据每个步骤返回的结果,动态决定下一步的方案。比如:要分析球员的位置,应按下属步骤拆解:
    • 了解到底有哪些球员
    • 查询这些球员的位置各是什么
    • 对位置信息进行处理:基于召回结果,对用户问题进行推理。
  • 规划生成的单个步骤,做好抽象和封装,明确输入和输出以及执行逻辑。

langchain 中的 Agents 已经对上述步骤提供了标准化接口,它相对于 Chains 一个重要不同在于:结合应用场景,通过提示词引导 LLM和用户多轮交互,摸清在什么时候应该需要选择什么样的工具链进行处理。其中 Plan-and-Execute Agents 用于制定动作计划;Action Agents 决定实施何种动作。

有了 Agents 和 Chains的标准抽象,下面再来看看摸清用户意图的几种方法,这样才能开发合适的工具:

  • Hy_pothetical D_ocument E_mbeddings(HyDE) 。Precise Zero-Shot Dense Retrieval without Relevance Labels 一文面向 zero-shot场景下的稠密检索 ,使用基础模型在训练过程中已经掌握的相关语料,面向用户问题,生成虚构的文档。该文档的作用,不是输出最终结果,而是通过 LLM 对问题的理解能力,生成与之相关的内容。这相当于自动化生成相关性标签,避免外部输入。虚构文档生成后,再使用无监督检索器进行 Embedding;然后将生成的向量在本地知识库中进行相似性检索,寻找最终结果。上述过程在原论文中也提供了示意图:

HyDE 要求与用户问题相关的知识,已经存在于 LLM 基础模型中。但专业领域知识,可能本来就是未联网、未公开的;LLM 生成的虚构文档,可能包含很多噪音,所以效果不一定很明显;另外生成文档的额外交互,进一步增加了时间开销。目前,LangChain 提供了 HyDE Chain,LlamaIndex 也提供了类似的能力;大家有兴趣可以尝试,面对中文可能需要自定义 Prompt Template。

  • 意图识别。通过 命名实体识别 和 槽位填充 实现。概括就是:
    • 在为用户提供服务的预设场景下,细分用户各种意图的类别,定制对应的语义槽,每个槽位可以视为在语义层面体现意图的基本单位。
    • 通过深度学习、统计学习,甚至 LLM ,理解用户问题提取语义槽中需要的内容。在基于大语言模型构建知识问答系统一文中给过例子:通过 System Role 告知LLM 需要提取槽位信息,让 LLM通过多轮对话引导用户给出所有槽位信息。还是以游戏攻略为例,玩家咨询球员的打法,那么必须提供:球员姓名,年代(比如2020/2022 年),比赛模式。对应的语义槽可以定义为:
    "球员打法" : {"球员名称" : ____,"年代" : ____,"比赛模式": ____,}

2. 搜索召回——提升精度

将用户的诉求转化为语义槽后,可以较为准确的体现问答意图,这有助于提升搜索命中精度。原始知识点在建立索引时,除了原始的 Embedding 方法,可以做更多优化:

  • 增加 关键词、主题词检索。主题词由机构定义和发布的规范词,通常是专有名词或名词短语;主题词检索结果包括检索词的近义词、同义词以及同一概念词的不同书写形式等,通过主题词检索可以很大程度降低漏检和误检。关键词由作者自定义或自动分析提取,通常是可以高度概括该文章主题的,使用关键词搜索可搜出更加明确的主题方向的文章。
  • 对相同知识点建立多级索引。同一知识点通常涉及多个维度,建立多级索引可以让其在多维度查询下发挥作用。比如,球员信息涉及:姓名、球队、年龄、进攻、防守、荣誉等多项属性。可以针对多属性分别建立索引,这样可以高效查询指定的属性数据,而不必每次将所有内容全部提取。
  • 把原始知识库转化为知识图谱。知识图谱的三元组:实体、属性和关系。实体表示现实世界中的某个事物或对象,属性表示这个事物或对象的特征或属性,关系表示实体之间的关系。知识三元组可以帮助人们更好地理解和组织知识,并支持推理和问题解决。在问答系统中可以通过提示词引导 LLM 从用户的问题中提取知识三元组,然后在知识图数据库中进行查询。

解决思路

意图识别和召回优化,属于一体两面,均有助于提升问答系统的精度。搜索层面知识图谱相对于 Embedding 方式,加工成本较高。在遵从奥卡姆剃刀的前提下,有没有什么高性价比的方式来解决这个问题?

笔者想到,意图识别和召回,其实有一个共同点:均可用 **关键词/主题词** 表示。那么问题可以转变为:

  • 关键词/主题词提取:
    • 面向知识点,提取的结果作为索引入口。
    • 面向问题,提取的结果作为语义槽内容。
  • 复用 Embedding 框架。从原始问题和知识点直接 Embedding 后的匹配,转化为对两者提取的关键词进行 Embedding 后再进行匹配。

基于关键词Embedding的入库和搜索的流程图如下所示:

这种方式怎么解决原始 Embedding 存在的几个局限呢?

  • 多知识点聚合处理局限。在关键词提取过程中,可以将并列的关键词短语拆分,平铺后分别检索。这样就可以降低 Embedding 的噪音,提高命中精度。最后将生成不同关键词短语召回的结果组合即可。举个例子:
语句:姚明和奥尼尔的内线与三分能力。

关键词提取后,按照从属关系叉乘,得到的结果应该是:
- 姚明内线
- 姚明三分
- 奥尼尔内线
- 奥尼尔三分
  • LLM 过度依赖导致的性能开销。首先通过关键词短语召回已经可以大大提升命中精度,所以不必设置较低的 score threshold 或者较大的 top k,这本来就过滤了很多无关词条。另外,关键词提取如果可以不依赖于 LLM,而是使用传统的 NLP 技术,那么可以避免和 LLM 的多轮交互,节省了响应时间。这样,对于大量的知识点文档,也可以做关键词提取。

带着这样的思路,下文主要描述关键词提取实现方法和效果。

关键词提取

我们的目标是,从无标注文本(零样本)是实现信息抽取(Information Extraction,IE),因为很少涉及人为干预,该问题非常具有挑战性。IE 包含三类任务:

  • 实体关系三元组抽取(RE, Relation Extraction )。三元组(triples)即 (主体, 关系, 客体) ,用英文表示为 (Subject, Relation, Object) 。关系抽取,即实体三元组抽取。涉及两件事:
    • 识别文本中的主体、客体,即实体识别任务。
    • 判断这两个实体属于哪种关系,即关系分类。 
  • 命名实体识别(NER, Name-Entity Recognition)。又称作专名识别、命名实体,是指识别文本中具有特定意义的实体,主要包括人名、地名、机构名、专有名词等,以及时间、数量、货币、比例数值等文字。指的是可以用专有名词(名称)标识的事物,一个命名实体一般代表唯一一个具体事物个体,包括人名、地名等。
  • 事件抽取(EE, Event Extraction)。指的是若干与特定矛盾相关的事物,在某一时空内的运动,从自然语言角度通过“主谓宾”等语义单元体现。事件抽取就是从半结构化、非结构化数据中,识别一个与目标相关的事件的重要元素识别出来。

笔者针对知识问答这样的特定场景,将上述三类任务简化为两个过程:

1. 名词短语提取。即:主语、宾语。通常由名词,和名词的限定词或者修饰词组成。比如:

姚主席如何评价周琦的组织进攻能力?
主语:姚主席
宾语:能力。但真正具有实际意义的是能力的限定修饰词,即“周琦组织进攻能力”。

2. 谓语。体现名词短语之间的事件。比如:评价。在更多场景中是:比较、查询、过滤、统计等,存在动态计算、处理的需求。因此即使忽略谓语,仅通过名词短语的组合也可以获得完备的知识。谓语所代表的事件,可以交给 LLM 处理。

笔者在经过对多种业务场景的分析后,最终萌生出下面的 关键词提取方式

  • 关键词只考虑名词短语,将其作为知识点的索引用于召回。
  • 事件体现的是不同知识点的关系。重点在于事件关联者,获取事件关联者对应的语料后,通过 LLM 理解事件进行处理:
    • 知识点通常不是按照事件组织的,而是按实体。因此索引建立和关键词抽取,应该以名词短语为主要目标。
    • 主语、宾语之间存在并列和限定关系。将限定关系按级联方式处理,同一名词短语内如果存在并列关系则与其他部分叉乘。

将该思路应用到上面的例子中:

如图所示,使用 NLU 的基本处理流程,分析原始问句:

1. 分词

2. 词性标注(Part-Of-Speech Tagging, Penn Chinese Treebank),用于识别名词短语。比如:NR 表示人名、机构、地名等专有名词;NT 表示时间名词,NOI表示汉字顺序颠倒产生的噪声,NN 表示其它类型名词。

3. NER 识别。比如姚,周琦等。

4. 然后还需要考虑语义间的依存关系,确定名词间的关系,比如:

  • 并列
  • 修饰。比如:“组织进攻能力”
  • 从属、限定等等。比如:["周琦", "组织进攻能力"]

这样不难得到应该搜索的关键词列表:['姚主席', '周琦', '组织进攻能力']。下面来看看这种思路究竟如何实现,还是分为两大类:LLM、传统 NLP。

基于 LLM 提取

LLM已经天然具备 NLU 和 NLG 的能力,所以做名词短语提取按道理应该手到擒来。业界已经有尝试,比如《Zero-Shot Information Extraction via Chatting with ChatGPT》一文,提出两阶段多轮问答信息提取方式:

在该思想的启发下,笔者使用 langchain 开发了信息提取 Chain,LLM 使用的是 ChatGLM-6B本地部署,提取部分测试片段如下所示:

发现问题了吗:明明是分析张三丰;结果李四和王五怎么冒出来了。要知道,Prompt 已经添加了“不要编造内容”的说明,但无济于事。总体而言,使用 LLM 提取信息效果如下:

  • 可以支持部分程度的 NER;对非专业名词、或业务自定义术语识别不好,需要Fine-Tuning。
  • 可以提取名词短语,但无法做精确的语义分析,大量测试案例下总是存在不少偏差。
  • 即使明确了输出格式,但还是频繁出错。
  • 耗时较长。提取 6 条测试案例耗时 12s。

简单而言:不是不能做,但对 LLM 的要求较高;结果不准确、开销也大。

传统 NLP 方法提取

在 LLM 做信息提取,效果不尽如人意的情况下,转而尝试传统 NLP 技术。前面提到的:分词、词性标注、NER 等,业界已经有不少传统 NLP 工具可以使用。

  • spacy,测试结果较差,很多语句识别不出来,比如:
“请比较詹姆斯和麦迪的属性”
—— 无法识别任何人名
“詹姆斯、字母哥和杰林.布朗的金徽章有何差异?”
—— 只能识别出布朗,且将 "杰林" 抛弃
  • CoreNLP 和 HanLP 均可正确识别。

经过测试后最终选择 HanLP作为基础工具,原因在于:

  • 对中文支持好
  • 依赖少,开箱即用
  • 基础工具完备,接口整洁,便于二次开发

下面基于 HanLP,看看究竟如何解决前文提出的:多知识点聚合查询问题?其核心点在于三步:

  1. 词性标注
  2. 名词短语关系分析:修饰、限定、并列等
  3. 名词短语重新组织:修饰、限定关系级联;并列关系与其他部分叉乘。

名词短语提取与整合

举一个更加复杂的例子,在主语和宾语中添加:并列和修饰关系。首先分词,然后添加词性标注,结果如下:

依存分析

词性有了,下面需要进一步提取句子中单词与单词之间的语法关系,即 依存句法分析;笔者采取 Stanford Dependencies Chinese (SDC) 标准进行分析,并且为了清晰展示,将分析结果转化为 Pandas DataFrame 的形式,如下图所示:

  • dep_tok_id,表示当前分词所依赖的中心词的id。比如:“指导” 的中心词 ID是 5。
  • dep_rel,表示当前分词和中心词的关系。比如:“指导”和中心词“主席”的关系是 conj ,根据 SDC 标准其含义为“连接”,即指导和主席属于并列关系。类似的,“詹姆斯”、“约基奇”和“张伯伦”都属于并列关系;但是“张伯伦”的中心词是“能力”,关系为 assmod ,即关联关系(修饰限定)。
  • sdp_tok_ids 和 sdp_rel。是在依存句法分析的基础上,进一步提供 语义依存分析,旨在分析一个句子中单词与单词之间的语义关系(sdp_rel),并将其表示为图结构的任务。不同于依存句法分析的地方是:图结构中每个节点可以有任意个目标节点。在本例当中,特别需要关注的是:Agt(施事者),Poss(领事者),eCoo(并列关系)等。

根据 DataFrame 中提供的依赖关系,可以直观地获取名词短语:

  • 主体:并列关系 [张指导, 姚主席]
  • 客体:[三分能力],三分和能力是修饰关系
  • 客体还存在三个并列的领事关系(所属关系):[詹姆斯, 约基奇, 张伯伦]

所以实际的客体,应该将并列的领事关系和本体叉乘后平铺,结果就是:

['詹姆斯三分能力', '约基奇三分能力', '张伯伦三分能力']

用这三个关键词,Embedding 后去本地知识库搜索就可大大提升命中精度。不过大家如果细心的话可以发现:语义依存分析的结果其实 不准确,比如:

  • “指导”一词的 sdp_rel 为 root,即被识别为动词作为语义树的根部
  • “和”与“主席”被识别为领事关系

这种语义偏差的原因在于:同一个分词的语义容易产生混淆。比如“指导”既可以作为名词,也可以作为动词。中文多义词和语境比较复杂,导致语义依存分析有不小的概率会出现误判。那么怎么解决这个问题呢?一定要使用有监督训练方式,对基础语义依存分析模型进行 Fine-Tuning吗?一旦涉及有监督,成本就不容小区了。不过幸好:词性标注和依存句法分析,相对语义依存分析,准确率是更高的,所以笔者想到另外一种方式:

基于正确的词性标注,构建出语法树,从 语法角度提取名词短语。

成分句法分析

分析一个句子在语法上的递归构成,在 NLU 领域是经典的 成分句法分析 问题。下面罗列 Chinese Treebank 标准片段,描述对分词单元类型的定义,请大家关注蓝色背景内容。

再次回顾我们要解决的多知识点聚合处理的目标:

  • 名词短语(Noun Phrase)提取。即提取 NP;
  • 处理好修饰名词短语间的修饰限定问题。比如:DNP 等
  • 处理好并列、连接关系。比如:CC 等
  • 将修饰关系的名词短语级联;将并列关系的NP和修饰关系的NP 叉乘。

基于该思路,上文提到实例,可以转化为下面的成分句法分析树:

这是典型的树结构:

  • 顶层的 NP 有两个:分别是主体和客体。客体是 VP(动词短语),表示主体的施事对象,和施事行为。
  • 每个 NP 是一颗子树。变种很多,但核心有三种形式:
    • 并列。比如:['张指导', '姚主席']通过明确的连接词 "和" 建立关系;['詹姆斯', '约基奇', '张伯伦'] 则通过非终结的标点服务建立关系。
    • 堆叠。由修饰词和名词联合形成一个名词短语。
    • 从属。通过"的"这样 DEG 词性的结构,明确表示前后两个短语间的从属关系。比如:"三分及抢断",隶属于"詹姆斯"。

这样来看,NP 的提取非常简单,通过递归方式对三种基础形式的树结构进行识别即可,提取时注意区分:

  • 主体、客体。
  • NP 子树中各个单元的组织关系。并列单元在和其它单元组合时,需要叉乘输出;其它邻接单元直接合并即可。

在上述算法下,样例中提取的名词短语列表最终如下所示:

  • 第一个列表为主语列表
  • 第二个列表为平铺后的宾语列表
  • 在性能方面,单条语句处理方式是 5ms;之前基于 LLM 的方式处理 6 条语句,需要 12s;性能相差数百倍。

至此,已经介绍完笔者关于关键词提取的基本思路,完整的处理流程如下图所示:

应用效果

关键词提取实现后,配合前文提到的召回方法,应用到文章开始的几个示例问题,结果如下所示:

最后汇总笔者提出的解决多知识点聚合处理问题的方案:

  • 基于传统 NLP 的成分句法分析,提取名词短语;再通过短语间的依存关系,生成关键词列表
  • 从完整语句的 Embedding,切换为关键词 Embedding:
    • 知识库构建时。基于单知识点入库,入库时提取关键词列表进行 Embedding,用于检索。
    • 查询时。对用户的问题提取关键词列表进行 Embedding 后,从本地知识库命中多条记录。
  • 将单问句中的多知识点拆解后检索,将召回的多条记录交付给 LLM 整合。

该方法的优势在于:

  • 相比传统 Embedding,大幅提升召回精准度。
  • 支持单次交互,对多知识点进行聚合处理。而不必让用户,手动分别查询单个知识点,然后让 LLM 对会话历史中的单个知识点进行汇总。
  • 使用传统 NLP 在专项问题处理上,相比 LLM 提供更好的精度和性能。
  • 减少了对 LLM 的交互频次;提升了交付给 LLM 的有效信息密度;大大提升问答系统的交互速度。

总结

LLM 的出现,推动下游应用激烈变革,各种探索如火如荼地展开。但在热潮背后,我们还有一些细节问题需要仔细对待。LLM 的未来是伟大的,甚至可能是迈向 AGI 的重要里程碑;但现在并不能宣判传统 NLP 技术的死亡。

本文提供了传统 NLP 和 LLM 结合的一种可能,通过用户问题和本地知识库关键词提取,能较好的解决 Embedding 精度缺失,以及 HyDE、LLM NLU的精度和性能问题。实现单轮对话,对多知识点的聚合处理。后续将继续探索 LLM 和传统技术的角色分工,进一步提升综合收益。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/48163.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Segment Anything CV界的GPT—prompt-based里程碑式研究成果

一、计算机视觉界的里程碑式研究成果 - SAM与SA-1B综述 Segment Anything受chatGPT式的prompt-based思路启发,训练数据集涵盖10亿masks,根据提供的图片注释实时产生不同的mask分割结果,试用效果惊人。 Segment Anything之于Computer Vision&…

更快地分割任何事物:面向移动应用的轻量级Sam

文章目录 摘要1、简介2、相关工作3、适合移动设备的SAM3.1、背景和项目目标3.2、提出方法4、实验4.1、实验设置4.2、MobileSAM的性能与原版SAM相当4.3、MobileSAM优于FastSAM5、结论摘要 https://arxiv.org/pdf/2306.14289v2.pdf 分割任何事物模型(SAM)因其令人印象深刻的零样本…

基于自然语言处理的多模态模型_综述

A Survey on Multimodal Large Language Models; 论文链接:https://arxiv.org/pdf/2306.13549.pdf 项目链接(实时更新最新论文,已获1.8K Stars):https://github.com/BradyFU/Awesome-Multimodal-Large-Language-Models 研究背景 …

AI向百万薪资 高级原画师开刀?!爆Midjourney入局3D模型生成

来源 SoulofArt | ID Soul_Art 现在AI向高级原画师和3D开刀了? 网传爆料AI已入局3D模型生成... 这进化速度放在整个行业都十分炸裂 4月,Midjourney进一步宣布推出Niji-journey V5 这是MJ针对二次元动漫风格预训练好的模型 可在其中添加提示词直接调…

Java 20 正式发布,超神了。。

出品 | OSC开源社区(ID:oschina2013) ChatGPT王炸更新!终于解封了... 老铁们,JDK 20 / Java 20 正式发布了,这版本号简直超神了。。 JDK 20 是一个短期维护版本,将获得六个月的支持。尽管如此,但…

JDK 20 正式发布, JDK 21 最新动态来了

点击“开发者技术前线”,选择“星标” 让一部分开发者看到未来 来自 infoQ | OSC开源社区(ID:oschina2013) JDK 20 是自 JDK 17, 以来的第三个非长期支持(LTS)版本,正如甲骨文 Java 平台组的首席架构师 Ma…

Ubuntu安装spark时遇到的问题及解决方案

伪分布式模式配置: 安装SSH: 问题一:安装openssh-server时出现以下报错 Package openssh-server has no installation candidate 出错原因: 一开始以为是apt命令没更新,apt-get update之后发现还是安装不了,可能是 文件/etc/apt…

ERROR Error: command failed: pnpm install --reporter silent --shamefully-hoist 错误解决办法

使用 vue-cli、pnpm创建新项目遇到的错误如下图所示: 在命令行安装pnpm6的版本: npm i pnpm6 -g vue create hello-world还可以直接使用npm安装就不报错了,输入一下代码: vue create hello-world -m npm以上两种方法都是亲测可…

postman 7.3.4 64位的下载、安装与使用

目录 postman的简介 postman下载地址及安装 postman的使用 postman 一、postman的简介 postman是一款功能强大的网页调试和模拟发送HTTP请求的Chrome插件,支持几乎所有类型的HTTP请求,操作简单且方便。二、postman下载地址及安装 我的postman下载网…

360手机java手机管家软件_360手机管家最新版下载_360手机管家官方下载-太平洋下载中心...

常见问答: 1、360手机管家连接不上手机怎么办? 答:如果发现360手机管家连接不上手机,你可以先检查下自己的数据线是否有问题,尝试连接其它设备看能不能连接。如果检查数据线与其它设备可以正常连接,那说明数据线是没问…

如何删除360奇安信软件

1.事情的缘由 之前待过一家公司,安装了360奇安信安全软件。由于更换了电脑,必须卸载奇安信,可是删除需要输入密码。后来联系了相关的人员,因为软件使用有点久远,没找到密码。 2.在安全模式下卸载 根据网上查询到的资…

Postman下载安装

一、Postman下载 1、Postman64位安装包下载: 链接:https://pan.baidu.com/s/1lInTrSfW9PMmYI6OsUS2tg 提取码:nvbw 2、Postman32位安装包下载: 链接:https://pan.baidu.com/s/1S_7K9wqyDwuoe-mjQowpKQ 提取码&#xf…

chatgpt赋能Python-python3的下载

Python 3-您在编程路上不可或缺的伙伴 如果您正在寻找一种流行的编程语言,那么Python 3就是一个不错的选择。Python 3作为一种高级编程语言,可以轻松地创建各种应用程序和网站。它是最受欢迎的编程语言之一,就是因为它易于学习和使用。 Pyt…

360安卓_360手机助手下载

360手机助手是手机应用商店软件,拥有丰富的应用资源,你可以随意下载,各种工具免费提供。360手机助手保证所有资源都是绿色可靠的,一键就能使用,需要的朋友可以点击下载! 360手机助手介绍 360手机助手是一款专为安卓手机…

360安卓_360手机助手安卓下载

为广大用户带来360手机助手2020最新版本下载。360手机助手软件为广大用户带来超多应用管理,带来超多手机工具。只需下载一个360手机助手,就可以获得丰富的软件游戏下载渠道。更多精彩好用的游戏软件等着用户上线挑选,是一款手机必备的工具软件…

在电脑上下载360手机助手中的APK文件

现在的游戏安装包都越来越大了,大一点的游戏基本都接近2个G。手机因为网络,下载不稳定,有时看着是下载完成,但安装时提示安装包错误,又给重新下载。这时想到的就是先在电脑上下载后,拷贝到手机再安装。 正常…

Postman官方64位版本下载

简介 Postman是一个接口测试工具,在做接口测试的时候,Postman相当于一个客户端,它可以模拟用户发起的各类HTTP请求,将请求数据发送至服务端,获取对应的响应结果, 从而验证响应中的结果数据是否和预期值相匹配;并确保开发人员能够及时处理接口中的bug,进而保证产品上线之后的稳…

谷歌CEO桑达尔•皮猜坦承“无法理解AI怎么运作”:社会要做好准备

Google CEO皮猜在接受CBS《60分钟》专访时表示,未来AI将影响每家公司的每一种产品,也将取代许多工作,例如作家、会计师、建筑师,讽刺的是甚至包括部分的软件工程师。而AI的治理更是博大精深的问题,在社会一窝蜂的投入A…

产品经理之SOP、SOW等名词解释

一、SOW(Statement of Work)介绍 SOW是对项目提供可交付成果的说明。一份概要,在很高层次上说明项目用途、范围和途径。是客户与供应商间的高层共识。SOW是项目的最初输入,由项目外的发起人或客户提供。 以下是案例 二、SOP&…

产品经理必须要掌握的数据分析能力

此文是转载的,转载了我朋友的。 今天给大家分享一下数据分析基础的一些学习笔记,希望对你有用。 生活中我们总能遇见一些喜欢说“我认为”、“我觉得”的人,不知道你们平时遇到这种人是什么感受呢? 在平时中还好,假如在…