大模型应用开发入门:原理、范式与实践

大模型应用开发入门分享:讲解了RAG和ReAct两种重要的大模型范式,以及调优提示词、增加调用次数和模型微调等几种常见的模型使用方法。

原文标题:大模型应用开发入门分享

原文作者:阿里云开发者

冷月清谈:

本文深入浅出地介绍了大模型应用开发的基础知识和核心范式,旨在帮助开发者快速入门并构建高效的LLM应用。文章首先从接口层面剖析了LLM的能力,重点介绍了`messages`和`tools`两个核心参数,阐述了它们在大模型应用中的作用。随后,文章详细讲解了RAG(检索增强生成)和ReAct(Reason+Act)两种重要的大模型范式,并通过实例分析了如何在实际应用中运用这些范式。此外,文章还介绍了调优提示词、增加调用次数和模型微调等几种常见的模型使用方法,并通过一个翻译的例子展示了如何通过提示词工程来优化模型效果。最后,作者结合自身在客服场景的实践经验,分享了对大模型应用的思考,强调了在实际应用中需要结合业务特点和用户需求,才能真正发挥大模型的价值。

怜星夜思:

1、文章提到了提示词工程中的COT(思维链)方法,这种方法在哪些场景下会特别有效?有没有一些反例,即哪些情况下COT反而会降低模型的效果?
2、文章中提到了RAG(检索增强生成)范式,并强调了知识库检索召回的重要性。那么,在实际应用中,有哪些常见的知识库构建和检索策略?它们各自的优缺点是什么?
3、文章提到,现在主流的方式都在慢慢弱化微调,因为费时费力,还不一定起到正向的效果。那么,在哪些情况下,我们仍然应该考虑使用微调?微调的最佳实践有哪些?

原文内容

阿里妹导读


本文是作者给兄弟团队做的大模型入门分享,介绍了基本大模型模式,分享出来希望帮助更多的同学参与到LLM应用建设。

前言

大模型作为新兴领域,不断地冒出来新的专有术语和新的概念,让大家觉得很神秘,捉摸不透。但是大部分复杂性的背后都会有一个极其简单便于理解的模型,本次分享最主要就是大模型的基本范式,通过范式将这些神秘感去除。

大模型虽然很厉害,很神秘,但作为使用人员,门槛是非常非常非常低的。

模型基础

虽然市面上的大型语言模型(LLMs)种类繁多,但在使用层面大家平等的都是API调包侠,因此从接口层面来剖析大模型有哪些能力。LLM的接口通常都遵循或类似于 OpenAI 的规范。这里我们以 OpenAI 的接口为例进行说明。

在与大型模型交互时,除了控制模型输出随机性的参数外,最核心的参数只有两个:messages 和 tools。可以说,市面上各种各样的大模型应用,都是基于这两个参数的基础上设计而来

messages-大模型是怎么实现记忆的?

  • messages是一个对话数组,其中角色主要有:

  • system:代表当前对话的系统指令,一般放提示词

  • user:用户指令

  • assistant:LLM的回复

  • ...:不同厂商会有不同的扩展定义

大模型所谓的对话记忆实际上就是依赖该数组做信息传递,如下图所示,第一轮我告诉我的名字叫屈定,第二轮的时候在问他是谁,他已经知道了我的名字,之所以知道因为我在messages的上下文中传递给了他这个信息。

  • 使用user传递用户的对话





  • 使用system设置系统指令





  • 提示词的不稳定容易被指令注入攻击





三张图看完,先总结下:

  • 大模型为什么能记住之前的对话?

只是因为后台系统给了他之前的对话,并不是他自己记住。大模型的请求调用就是一个无状态的,取决于每次给的对话内容。

  • 大模型的提示词有什么用?

大模型的提示词可以进一步控制(覆盖)模型的行为,具备高优先级,但存在不稳定性

接下来我们就可以来理解第一个重要的大模型范式:检索增强生成,也就是RAG(Retrieval Augmented Generation)

直白的理解为用检索到的知识,来增量生成答案的质量。比如我有一个关于数仓各种问题处理的Q&A,想要做一个问答机器人,这个问答机器人要基于我的Q&A回复用户。这个 检索Q&A -> 基于检索到的Q&A回复用户,这个流程就是一个典型的RAG链路。也显而易见,RAG的最终目标是生成靠谱的答案给到用户。





RAG链路的搭建是很简单,但是效果却很难,从流程里面我们能发现两个关键点:

1.知识库检索召回:这里要解决如何召回最靠谱的答案。

2.LLM基于知识回答:这里要解决的是如何让模型在一堆知识中给出自信准确的回答。

这些都是业界在不断探索的东西,没有所谓的标准答案,只有适合当前业务的最佳方案。

tools-大模型能执行任何工具?

经常有同学会问一些大模型是否能查询odps,或者大模型能够把数仓数据导入到ob之类的问题。这些问题的背后是对LLM存在错误的理解,也就是tools参数的理解。

tools也是一个数组,包含了一堆工具集合,核心为工具的作用描述,和工具需要的参数,如下图天气工具的定义。





接下来就是使用工具,基于工具的回答至少要两次大模型请求调用:

1.将用户的对话和工具一起给到大模型,大模型需要执行的工具以及工具参数;

2.后端系统依据大模型选择结果,去执行对应的工具,拿到结果;

3.再次请求大模型,此时上下文中给到了工具执行结果,大模型基于信息回复;





先总结下:

1.大模型并不能够执行任何工具,但是大模型能够选择接下来要执行的工具。选择后工具由配合的系统来执行获取结果。

接下来我们就可以来理解第二个重要的大模型范式ReAct(Reason+Act)

这里需要强调下,大模型的很多范式都是对生活中人类行为的模拟,因此我们也是从生活中的案例来理解大模型。

案例主题:老板让写一份调研外部大模型框架的报告

工具:互联网搜索,PPT,思维导图

思考 (Reasoning): 需要调研外部大模型框架,明确调研目标是了解行业内的主要框架、特点和应用场景。需要先明确有哪些主流框架,然后针对性地收集资料。

行动 (Acting):

行动: 使用互联网搜索“主流大模型框架 2024/2025”、“开源大模型框架”。

观察 (Observation):

观察: 搜索结果显示:PyTorch、TensorFlow、JAX等是主流框架,还有一些新兴框架如MindSpore、Paddle等。

思考 (Reasoning): 我已经拿到了想要的资料,接下来使用思维导图搭建汇报思路

行动 (Acting):

行动: 使用思维导图工具,搭建报告的初步框架,包括:框架名称、开发语言、主要特点、优势、劣势、应用场景。

观察 (Observation):

观察: 初步框架包括:框架名称、开发语言、主要特点(动态图/静态图、分布式训练支持等)、优势、劣势、应用场景(NLP、CV等)。

思考 (Reasoning): 信息基本收集完毕,需要将所有信息整理成结构化的报告,并使用PPT进行总结和分析。

行动 (Acting):

行动: 使用PPT工具,将思维导图中的内容整理成PPT,并撰写文字说明。

观察 (Observation):

观察: 完成了PPT初稿,内容比较全面,但需要进行排版美化。

这个思考的流程就是ReAct,后面有实际案例,这里先理解这个概念。





模型使用

大模型的应用五花八门,但都离不开上述两个核心参数,接下来围绕上述的参数,我们能利用的现有的模型交互手段主要有以下三种,包括:

  • 调优提示词:大模型工程中的核心,提示词的优秀与否决定了你是否需要链路上做额外的兜底

  • 增加调用次数:将一个任务拆分为多个子任务执行,最后判断结果。这是一种常用的对提示词能力的补充手段,降低单一提示词的复杂性。

  • 模型微调:通过引入特定业务场景案例,让模型能更好地理解用户的意图和需求。

用大模型+提示词做翻译 [提示词调优]

为了更好的评价,我们选择哪吒中的英文台词,然后将英文翻译成中文,看还原度如何?

The prejudice in people's hearts is like a mountain. No matter how hard you try, you can't move it.
Looking back on it, three years isn't that long.
Be quick to obey my command
I'm the captain of my destiny, not heaven.
If you ask me whether people can change their own destiny, I don't know. But defying fate is Nezha's destiny.

方案一直接使用提示词进行翻译

## Role and Goal:
你是一个翻译专家,尤其擅长英文到中文的翻译,接下来我给你多段英文台词,帮我翻译成中文.

Constraints

- 翻译时保持译文格式不变

Background:

原文来自《哪吒》系列电影的第二部中的台词,讲述了天劫之后,哪吒、敖丙的灵魂保住了,但很快会魂飞魄散。太乙真人打算用七色宝莲给二人重塑肉身,但是在重塑肉身的过程中却遇到重重困难,哪吒、敖丙的命运将迎来更多的挑战。

Guidelines:

1. 结合背景将文本直接翻译成中文,保持原始格式,不省略任何信息。

Source:

- The prejudice in people’s hearts is like a mountain. No matter how hard you try, you can’t move it.
- Looking back on it, three years isn’t that long.
- Be quick to obey my command
- I’m the captain of my destiny, not heaven.
- If you ask me whether people can change their own destiny, I don’t know. But defying fate is Nezha’s destiny.

Output:

{译文}

绝大多数情况下,直接使用提示词能做到的效果就已经能达到60%了(现在的模型确实强大了),下方的问题在于一些短的语句翻译不够传神。

模型

方案一翻译结果:

gemini-2.0-flash

  • 人心中的成见就像一座大山,任你怎么努力也无法搬动。

  • 如今想来,三年光阴,也不算长。

  • 还不快快听我号令!

  • 我命由我定,不由天!

  • 要问我人能否改变自己的命运,我不知道。但是,逆天而行,就是哪吒的命。

方案二提示词中引入COTChain-of-Thought

COT被称为思维链,简单点来说是要告诉模型针对问题的思考步骤是什么,引导模型去按照特定思维解决问题。概念很抽象,以翻译为例,我们思考一般人是如何进行翻译的?

1.先直接翻译

2.结合上下文再审视这个翻译是否合理,有哪些改进点

3.针对改进点再斟酌修改

那么我们也让模型按照这个思路来执行翻译。

## Role and Goal:
你是一个翻译专家,尤其擅长英文到中文的翻译,接下来我给你多段英文台词,帮我翻译成中文.

Constraints

- 翻译时保持译文格式不变
- 严格按照output中定义的范式输出

Background:

原文来自《哪吒》系列电影的第二部中的台词,讲述了天劫之后,哪吒、敖丙的灵魂保住了,但很快会魂飞魄散。太乙真人打算用七色宝莲给二人重塑肉身,但是在重塑肉身的过程中却遇到重重困难,哪吒、敖丙的命运将迎来更多的挑战。

Guidelines:

翻译的过程分为三部分:
1. 直译:结合背景将文本直接翻译成中文,保持原始格式,不省略任何信息。
2. 评估和反思:结合背景道教封神,主人公对命运反抗,识别直接翻译中的具体问题,例如:
- 非母语常用的中文表达,
- 笨拙的措辞
- 过于口语化的表达
- 等等
提供解释,但不要添加或省略内容或格式。
3. 意译:根据字面翻译和已识别的问题,重新解释翻译,确保它保持与原始输入格式一致,不要删除任何内容。

Source:

- The prejudice in people’s hearts is like a mountain. No matter how hard you try, you can’t move it.
- Looking back on it, three years isn’t that long.
- Be quick to obey my command
- I’m the captain of my destiny, not heaven.
- If you ask me whether people can change their own destiny, I don’t know. But defying fate is Nezha’s destiny.

Output:

直译

{直译}


评估和反思

{评估和反思}


意译

{意译}

该方案取得了意想不到的效果,针对长句翻译成短句组合形式, 相比官方的来看,更像是修道者的口吻,但针对一些特殊短句用法,仍然不够理想。

模型

方案一翻译结果:

方案二翻译结果:

gemini2.0 flash

  • 人心中的成见就像一座大山,任你怎么努力也无法搬动。

  • 如今想来,三年光阴,也不算长。

  • 还不快快听我号令!

  • 我命由我定,不由天!

  • 要问我人能否改变自己的命运,我不知道。但是,逆天而行,就是哪吒的命。

  • 人心存偏见,如山岳难移。纵使竭尽全力,亦不可撼动分毫。

  • 如今想来,三年光阴,弹指一挥间。

  • 奉我号令,不得有误!

  • 我命由我不由天!

  • 若问世人能否逆天改命,吾不得而知。然,抗争宿命,乃哪吒之命也。

方案三引入动态few shot

few shot指的是提示词中的少样本技巧,动态就是将这部分样本抽离到一个知识库,每一次走翻译前先去知识库里面召回TOP最相关的,然后放入到提示词的Example中。

假设我的知识库中召回了如下两句:

Item1: 原文:Be quick to obey my command
意译:急急如律令

Item2: 原文:Life is not long, but it’s not short either.
意译:人生,说长不长,说短不短。

结合后提示词如下:

## Role and Goal:
你是一个翻译专家,尤其擅长英文到中文的翻译,接下来我给你多段英文台词,帮我翻译成中文.

Constraints

- 翻译时保持译文格式不变
- 严格按照output中定义的范式输出

Background:

原文来自《哪吒》系列电影的第二部中的台词,讲述了天劫之后,哪吒、敖丙的灵魂保住了,但很快会魂飞魄散。太乙真人打算用七色宝莲给二人重塑肉身,但是在重塑肉身的过程中却遇到重重困难,哪吒、敖丙的命运将迎来更多的挑战。

Guidelines:

翻译的过程分为三部分:
1. 直译:结合背景将文本直接翻译成中文,保持原始格式,不省略任何信息。
2. 评估和反思:结合背景道教封神,主人公对命运反抗,识别直接翻译中的具体问题,例如:
- 非母语常用的中文表达,
- 笨拙的措辞
- 过于口语化的表达
- 等等
提供解释,但不要添加或省略内容或格式。
3. 意译:根据字面翻译和已识别的问题,重新解释翻译,确保它保持与原始输入格式一致,不要删除任何内容。

Example:

1. 原文:Be quick to obey my command
意译:急急如律令

2. 原文:Life is not long, but it’s not short either.
意译:人生,说长不长,说短不短。

Source:

- The prejudice in people’s hearts is like a mountain. No matter how hard you try, you can’t move it.
- Looking back on it, three years isn’t that long.
- Be quick to obey my command
- I’m the captain of my destiny, not heaven.
- If you ask me whether people can change their own destiny, I don’t know. But defying fate is Nezha’s destiny.

Output:

直译

{直译}


评估和反思

{评估和反思}


意译

{意译}

模型

方案一翻译结果:

方案二翻译结果:

方案三翻译结果:

gemini2.0 flash

  • 人心中的成见就像一座大山,任你怎么努力也无法搬动。

  • 如今想来,三年光阴,也不算长。

  • 还不快快听我号令!

  • 我命由我定,不由天!

  • 要问我人能否改变自己的命运,我不知道。但是,逆天而行,就是哪吒的命。

  • 人心存偏见,如山岳难移。纵使竭尽全力,亦不可撼动分毫。

  • 如今想来,三年光阴,弹指一挥间。

  • 奉我号令,不得有误!

  • 我命由我不由天!

  • 若问世人能否逆天改命,吾不得而知。然,抗争宿命,乃哪吒之命也。

  • 人心之偏见,如山岳岿然,纵移山填海,亦难撼其分毫。

  • 事过境迁,三年光阴,亦不过弹指一挥间。

  • 急急如律令

  • 我命由我不由天!

  • 若问人定胜天否,我亦茫然。然逆天而行,乃哪吒之宿命。

few shot这种开卷考试方法是大模型链路中一种重要的优化手段,few shot是提示词中为数不多能够动态变化的部分,且对模型整体效果影响较小,更为可控。此外业务流量一般都是符合2:8分布的,且是可收敛的,可能只需要20%的few shot案例,就能满足80%的场景诉求。

用大模型+Agent做计算器 [增加调用次数]

大家应该都看过下面的案例,大模型是很不擅长数学计算的,那么用大模型直接做计算器就非常容易出问题。





这里使用llama_index的agent框架做演示:

1.定义了三个工具函数,乘法,加法,减法

2.构建一个Agent执行模式

import os

from dotenv import load_dotenv
from llama_index.core.agent import ReActAgent
from llama_index.core.tools import FunctionTool
from llama_index.llms.azure_openai import AzureOpenAI

def multiply(a: int, b: int) -> int:
    “”“Multiply two integers and returns the result integer”“”
    return a * b

def add(a: int, b: int) -> int:
    “”“Add two integers and returns the result integer”“”
    return a + b

def subtract(a: int, b: int) -> int:
    “”“subtract two integers and returns the result integer”“”
    return a - b

加载 .env 文件

load_dotenv()

初始化工具

multiply_tool = FunctionTool.from_defaults(fn=multiply)
add_tool = FunctionTool.from_defaults(fn=add)
subtract_tool = FunctionTool.from_defaults(fn=subtract)

llm = AzureOpenAI(model=“gpt-4o”,  # 或者 gpt-4
                  engine=‘gpt-4o’,
                  deployment_name=“gpt-4o”,
                  api_key=os.getenv(‘AZURE_KEY’),
                  azure_endpoint=“https://ilm-dev.openai.azure.com”,
                  api_version=“2023-07-01-preview”)

初始化Agent

agent = ReActAgent.from_tools([multiply_tool, add_tool, subtract_tool], llm=llm, verbose=True)

response = agent.chat("What is 60-(20+(2*4))? Calculate step by step ")

> Running step cba1a160-74c3-4e34-bcc4-88e6a678eaf9. Step input: What is 60-(20+(2*4))? Calculate step by step 
Thought: The current language of the user is: English. I need to use a tool to help me answer the question.

To solve the expression (60 - (20 + (2 * 4))) step by step, I will first calculate the multiplication inside the parentheses.
Action: multiply
Action Input: {‘a’: 2, ‘b’: 4}
Observation: 8

> Running step 5455108e-ac53-4115-8712-68f2457a9b82. Step input: None
Thought: Now that I have the result of the multiplication, I can proceed to the next step, which is to add 20 and 8.
Action: add
Action Input: {‘a’: 20, ‘b’: 8}
Observation: 28

> Running step 4d8fae00-83bd-4205-9993-f0e0119f408d. Step input: None
Thought: Now that I have the result of the addition, I can proceed to the final step, which is to subtract 28 from 60.
Action: subtract
Action Input: {‘a’: 60, ‘b’: 28}
Observation: 32

> Running step ce5d1075-ff11-47a2-b286-d7a715dc40ba. Step input: None
Thought: I can answer without using any more tools. I’ll use the user’s language to answer.
Answer: The result of the expression (60 - (20 + (2 * 4))) is 32.





上次有同学问,那么大模型在这种链路里面到底发挥了什么作用?大模型最大的能力就是自然语言理解,我们可以尝试把规则再复杂化,输入改成张三代表减法,李四代表加法,王二代表乘法,What is 60张三(20李四(2王二4))? Calculate step by step ,表现仍然可以,这就带来了对自然语言的容错,会像人一样去思考,而不是固定死的逻辑。

Thought: The current language of the user is English. I need to use a tool to help me answer the question. The expression given is 60张三(20李四(2王二4)), which translates to 60 - (20 + (2 * 4)). I will calculate step by step.

First, I need to calculate the multiplication part: 2王二4, which is 2 * 4.
Action: multiply
Action Input: {‘a’: 2, ‘b’: 4}
Observation: 8

> Running step 48262cb8-5c3a-47b7-b13b-449787c27078. Step input: None
Thought: The result of 2王二4 is 8. Now, I need to calculate the addition part: 20李四8, which is 20 + 8.
Action: add
Action Input: {‘a’: 20, ‘b’: 8}
Observation: 28

> Running step 1cccd5c6-3d96-4014-a579-1c997765a1da. Step input: None
Thought: The result of 20李四8 is 28. Now, I need to calculate the subtraction part: 60张三28, which is 60 - 28.
Action: subtract
Action Input: {‘a’: 60, ‘b’: 28}
Observation: 32

> Running step 65d33d20-1009-4482-a6d2-7af20333640c. Step input: None
Thought: I can answer without using any more tools. I’ll use the user’s language to answer.
Answer: The result of 60张三(20李四(2王二4)) is 32.

模型微调

这部分具体案例就不好说了,我举个实际生产的案例,在给WorldFirst做客服的时候,存在很多特殊的业务知识,比如用户在万里汇下载银行对账单 != 下载交易流水单。这里有业务背景,银行对账单是亚马逊要求的账户证明文件。这些业务背景是模型难以掌握的,此时就需要引入微调,将这部分知识内置到模型里面。

现在主流的方式都在慢慢弱化微调,因为费时费力,还不一定起到正向的效果,更多的工程实践是将提示词复杂化动态化,工程上做更多的兜底工作。

一些感想

大模型能带来很大的工作和问题思考方式的革新,让一些问题解决方式变成取决于你的想象力,但对客的业务的效果并非完全取决于大模型。很多同学认为有了LLM,业务效果,开发效率,交付质量都能很方便解决,什么都往LLM上靠拢,这是很大的误区。

以笔者参与的客服场景感想,最早都认为客服是非常适合大模型的场景,笔者同样也是这样认为。实际深入后,并非如此,尤其是在对专业度和准确率有明确要求的场景。客服作为售后,用户是带着问题带着情绪来的,他需要的是明确的解决方案,不需要机械式的安抚和吐答案。因此业办能力 + 拟人化是客服成功的两大主要因素,确定主要因素后,再去思考LLM在这些因素点上能带来什么,接着思考构建你的方案,这样的应用才是靠谱的方式。

端到端全链路追踪诊断


本方案为您介绍如何使用应用实时监控服务 ARMS 应用监控进行一站式调用链路追踪,帮助您快速定位问题,洞察性能瓶颈,重现调用参数,从而大幅提升线上问题诊断的效率。    


点击阅读原文查看详情。

我之前做过一个项目,需要用大模型来生成一些特定风格的文本。刚开始我尝试用prompt engineering,但是效果一直不好。后来我用了一些特定风格的文本来微调模型,效果立马提升了很多。

所以,我觉得微调在生成特定风格的文本方面还是很有用的。但是,微调需要大量的数据,而且需要根据实际情况选择合适的微调策略。总之,微调是一个需要不断尝试和调整的过程。

我感觉微调就像是给模型做“定向培训”,让它更适应特定的任务或者领域。如果你的任务非常专业,或者需要模型掌握一些特定的知识,那微调可能就是必要的。

但是,微调的成本确实很高,需要大量的数据和计算资源。而且,如果你的数据质量不高,或者微调的方法不对,反而会降低模型的效果。所以,除非你有明确的需求和充足的资源,否则还是尽量用prompt engineering来解决问题。

我来补充一个学术点的看法。COT在提升模型可解释性方面有积极作用,因为它可以让开发者看到模型是如何一步步得出结论的。这对于debug和优化prompt非常有帮助。

但是,COT的有效性也取决于模型的大小和训练数据。对于一些小模型,COT可能会因为引入了额外的步骤而增加出错的可能性。此外,如果训练数据中缺乏类似的推理链,模型可能无法很好地掌握这种技巧。所以,使用COT需要根据实际情况进行权衡。

说道RAG,这我可太有体会了。知识库构建,我用过最简单的就是把所有Q&A直接放数据库里,用关键词匹配。优点是简单粗暴,缺点是效果很依赖关键词的质量,同义词、近义词啥的都得考虑进去。

后来我试了向量数据库,把Q&A都embedding成向量,用余弦相似度来检索。效果确实好很多,能找到语义更相关的答案,但是搞embedding模型和向量数据库又引入了新的复杂度。

从学术角度来看,知识库构建和检索是一个信息检索领域的经典问题。除了上面老哥提到的方法,还有基于图结构的知识库,比如知识图谱,可以更好地表示实体之间的关系。检索策略方面,除了向量检索,还可以考虑混合检索,结合关键词检索和向量检索的优点。

每种策略都有其trade-off。关键词检索简单高效,但缺乏语义理解能力;向量检索能理解语义,但计算成本较高;图结构知识库能表示复杂关系,但构建和维护成本很高。选择哪种策略,需要根据具体的应用场景和数据特点来决定。

从理论上讲,微调可以改变模型的参数,让模型更好地拟合特定的数据分布。但是,微调也有可能导致模型过拟合,从而降低模型的泛化能力。

为了避免过拟合,可以使用一些正则化技术,比如dropout、weight decay等。此外,还可以使用一些数据增强技术,来增加训练数据的多样性。总之,微调是一个需要谨慎对待的过程。

文章里提到的COT(思维链)确实是个好东西,感觉在那些需要模型进行复杂推理或者需要多步骤才能得出答案的场景下会特别有效。比如,解决需要数学计算的应用题、或者进行一些逻辑推理、再或者需要根据多个信息源进行整合分析的场景。

但反过来说,如果问题本身就很简单直接,或者模型已经对这类问题非常熟悉了,那COT可能就有点画蛇添足了。就像你让一个已经很会心算的数学高手写下每一步计算过程,反而会降低他的速度和效率。

我觉得吧,COT就像是给模型提供了一份“思考草稿”,让它有条理地解决问题。但是,如果你的问题太模糊,或者模型对问题的理解有偏差,那么COT可能会把模型带偏到错误的方向。就像你给一个方向感不好的人提供了一份错误的地图,只会让他越走越远。

所以,使用COT的前提是确保你的问题清晰明确,并且模型对问题的理解是正确的。否则,还是简单粗暴的prompt更有效。

我之前在公司做RAG的时候,用过Elasticsearch来构建知识库,用它的全文检索功能来做关键词匹配,同时用它的向量检索功能来做语义检索。感觉ES还是挺强大的,能满足大部分的检索需求。

不过,ES的配置和调优还是挺复杂的,需要一定的经验。而且,如果你的数据量很大,ES的性能可能会成为瓶颈。总之,技术选型还是要结合实际情况,没有银弹。