我的学习笔记

土猛的员外

如何使用LLM与任何pdf和图像文件聊天

介绍

如此多有价值的信息被困在PDF和图像文件中。幸运的是,我们拥有强大的大脑,能够处理这些文件以找到特定的信息,这实际上很棒。

但是,我们当中有多少人在内心深处不希望有一个工具可以回答关于给定文档的任何问题?

这就是本文的全部目的。我将逐步解释如何构建一个可以与任何pdf和图像文件聊天的系统。

项目的一般工作流程

对正在构建的系统的主要组件有一个清晰的理解总是好的。让我们开始吧。

截屏2023-09-09 23.47.50

整个聊天系统的端到端工作流程
  • 首先,用户提交待处理的文档,文档可以是PDF格式,也可以是图像格式。
  • 第二个模块用于检测文件的格式,以便应用相关的内容提取功能。
  • 然后使用Data Splitter模块将文档的内容分割成多个块。
  • 这些块最终使用Chunk Transformer转换成Embeddings,然后将它们存储在矢量存储中。
  • 在流程结束时,用户的查询用于查找包含该查询答案的相关块,并将结果作为JSON返回给用户。

1. 检测文档类型

对于每个输入文档,将根据其类型(无论是PDF还是image)应用特定的处理。

这可以通过辅助函数detect_document_type 与内置Python模块中的guess 函数相结合来实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
def detect_document_type(document_path):

guess_file = guess(document_path)
file_type = ""
image_types = ['jpg', 'jpeg', 'png', 'gif']

if(guess_file.extension.lower() == "pdf"):
file_type = "pdf"

elif(guess_file.extension.lower() in image_types):
file_type = "image"

else:
file_type = "unkown"

return file_type

现在我们可以在两种类型的文档上测试这个函数:

  • transformer_paper.pdf是Transformers研究论文来自Arxiv
  • zoumana_article_information.png是图像文档,包含有关我在Medium上覆盖的主要主题的信息。
1
2
3
4
5
research_paper_path = "./data/transformer_paper.pdf"
article_information_path = "./data/zoumana_article_information.png"

print(f"Research Paper Type: {detect_document_type(research_paper_path)}")
print(f"Article Information Document Type: {detect_document_type(article_information_path)}")

输出:

img

成功检测到的文件类型(图片按作者)

这两种文件类型都被detect_document_type函数成功检测到。

2. 根据文档类型提取内容

langchain库提供了不同的模块来提取给定类型文档的内容。

  • UnstructuredImageLoader提取图像内容。
  • UnstructuredFileLoader提取任何pdf和Txt文件的内容。

我们可以将这些模块与上面的detect_document_type 函数结合起来实现文本提取逻辑。

这些模块可用于在extract_file_content函数中实现端到端的文本提取逻辑。

让我们看看他们的行动吧!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
from langchain.document_loaders.image import UnstructuredImageLoader
from langchain.document_loaders import UnstructuredFileLoader

def extract_file_content(file_path):

file_type = detect_document_type(file_path)

if(file_type == "pdf"):
loader = UnstructuredFileLoader(file_path)

elif(file_type == "image"):
loader = UnstructuredImageLoader(file_path)

documents = loader.load()
documents_content = '\n'.join(doc.page_content for doc in documents)

return documents_content

现在,让我们打印每个文件内容的前400个字符。

1
2
3
4
5
6
7
8
research_paper_content = extract_file_content(research_paper_path)
article_information_content = extract_file_content(article_information_path)

nb_characters = 400

print(f"First {nb_characters} Characters of the Paper: \n{research_paper_content[:nb_characters]} ...")
print("---"*5)
print(f"First {nb_characters} Characters of Article Information Document :\n {research_paper_content[:nb_characters]} ...")

输出:

上述文件的前400个字符如下:

  • 研究论文内容以Provided proper attribution is provided开始,以Jacod Uszkoreit* Google research usz@google.com结束。
  • 图像文档的内容以This document provides a quick summary开始,并以Data Science section covers basic to advance concepts结束。

img

《Transformers》论文和文章信息文档的前400个字符

3. Chat实现

输入文档被分割成块,然后在实现问答逻辑之前为每个块创建Embedding。

a. 文档组块

块表示较大文本的较小部分。这个过程对于确保一段内容以尽可能少的噪音表示,使其具有语义相关性至关重要。

可以应用多种分块策略。

例如,我们有NLTKTextSplitterSpacyTextSplitter,、RecursiveCharacterTextSplitterCharacterTextSplitter等等。

每一种策略都有其优缺点。

本文的主要重点是CharacterTextSplitter,它基于\n\n从输入文档中创建块,并通过其字符数测量每个块的长度(length_function)。

1
2
3
4
5
6
text_splitter = CharacterTextSplitter(        
separator = "\n\n",
chunk_size = 1000,
chunk_overlap = 200,
length_function = len,
)

chunk_size告诉我们希望每个块中最多有1000个字符,较小的值将产生更多的块,而较大的值将产生更少的块。

需要注意的是,选择chunk_size的方式会影响整体结果。因此,一个好的方法是尝试不同的值,并选择更适合自己用例的值。

此外,chunk_overlap意味着我们希望在连续块之间最多有200个重叠字符。

例如,假设我们有一个包含文本Chat with your documents using LLMs的文档,并希望使用Chunk Size = 10Chunk overlap = 5来应用分块。

这个过程如下图所示:

img

文档分块说明

我们可以看到,对于35个字符(包括空格)的输入文档,我们最终得到了总共7个块。

但是,我们为什么要首先使用这些重叠呢?

包括这些重叠, CharacterTextSplitter确保在块之间维护底层上下文,这在处理长段文档时特别有用。

chunk_size类似,chunk_overlap没有固定值。需要测试不同的值,以选择效果更好的值。

现在,让我们看看它们在我们的场景中的应用:

1
2
3
4
5
research_paper_chunks = text_splitter.split_text(research_paper_content)
article_information_chunks = text_splitter.split_text(article_information_content)

print(f"# Chunks in Research Paper: {len(research_paper_chunks)}")
print(f"# Chunks in Article Document: {len(article_information_chunks)}")

输出:

img

每个文档中的块数

对于像研究论文这样的大型文档,我们有更多的块(51),而一页的文章文档只有2个。

b. 创建块的Embeddings

我们可以使用OpenAIEmbeddings模块,它默认使用text-embedding-ada-002 模型来创建块的Embedding。

而不是使用text-embedding-ada-002可以使用不同的模型(例如:gpt-3.5-turbo-0301),通过改变以下参数:

  • model = “ gpt-3.5-turbo-0301
  • deployment = “<DEPLOYMENT-NAME>“,对应于模型部署期间给出的名称。默认值也是text- embeddings -ada-002

为了简单起见,我们将在本教程中坚持使用默认参数的值。但在此之前,我们需要获得OpenAI凭据,下面的文章提供了所有步骤。

1
2
3
4
5
from langchain.embeddings.openai import OpenAIEmbeddings
import os

os.environ["OPENAI_API_KEY"] = "<YOUR_KEY>"
embeddings = OpenAIEmbeddings()

c. 创建文档搜索

为了获得给定查询的答案,我们需要创建一个向量存储,用于查找与该查询最接近的匹配块。

这样的矢量存储可以使用FAISS模块中的from_texts函数来创建,该函数有两个主要参数:text_splitterEmbeddings,这两个参数都是前面定义的。

1
2
3
4
5
from langchain.vectorstores import FAISS

def get_doc_search(text_splitter):

return FAISS.from_texts(text_splitter, embeddings)

通过在研究论文块上运行get_doc_search,我们可以看到结果是vectorstores。如果我们使用article_information_chunks,结果将是相同的。

1
2
doc_search_paper = get_doc_search(research_paper_chunks)
print(doc_search_paper)

输出:

img

研究论文的矢量存储

d. 开始和你的文件聊天

祝贺你走了这么远!

chat_with_file函数用于通过组合上述所有函数以及similarity_search函数来实现聊天的端到端逻辑。

最后一个函数接受两个形参:

  • 我们想要聊天的文件,还有
  • 用户提供的查询
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
from langchain.llms import OpenAI
from langchain.chains.question_answering import load_qa_chain
chain = load_qa_chain(OpenAI(), chain_type = "map_rerank",
return_intermediate_steps=True)

def chat_with_file(file_path, query):

file_content = extract_file_content(file_path)
text_splitter = text_splitter.split_text(file_content)

document_search = get_doc_search(text_splitter)
documents = document_search.similarity_search(query)

results = chain({
"input_documents":documents,
"question": query
},
return_only_outputs=True)
answers = results['intermediate_steps'][0]

return answers

让我们退一步来正确理解上面代码块中发生的事情。

  • load_qa_chain提供了一个接口,用于在一组文档上执行问答。在这个特定的情况下,我们使用默认的OpenAI GPT-3大型语言模型。
  • chain_typemap_rerank。通过这样做,load_qa_chain函数根据链给出的置信度分数返回答案。还有其他的chain_type可以使用,比如map_reducestuffrefine等等。每个人都有自己的优点和缺点。
  • 通过设置return_intermediate_steps=True,我们可以访问元数据,如上述置信度评分。

它的输出是一个包含两个键的字典:查询的答案和信心得分

我们终于可以和我们的文件聊天了,从图像文档开始:

  • 与图像文档聊天

为了与图像文档进行对话,我们提供了文档的路径,以及我们希望模型回答的问题。

1
2
3
4
5
6
7
8
query = "What is the document about"

results = chat_with_file(article_information_path, query)

answer = results["answer"]
confidence_score = results["score"]

print(f"Answer: {answer}\n\nConfidence Score: {confidence_score}")

输出:

img

对图片文档查询的结果

该模型对其响应有100%的信心。通过查看下面原始文档的第一段,我们可以看到模型响应确实是正确的。

img

原文章图片文档前两段

最有趣的部分之一是,它提供了文档中涵盖的主要主题的简要摘要(统计、模型评估指标、SQL查询等)。

  • 与PDF文件聊天

PDF文件的处理过程与上一节中的过程类似。

1
2
3
4
5
6
7
8
query = "Why is the self-attention approach used in this document?"

results = chat_with_file(research_paper_path, query)

answer = results["answer"]
confidence_score = results["score"]

print(f"Answer: {answer}\n\nConfidence Score: {confidence_score}")

输出:

我们再一次从模型中得到了100%的置信度。这个问题的答案看起来非常正确!

img

查询PDF文件的结果

在这两种情况下,该模型都能在几秒钟内做出类似人类的反应。让一个人完成同样的过程需要几分钟,甚至几个小时,这取决于文档的长度。

本文的Github地址

原文:How to Chat With Any PDFs and Image Files Using Large Language Models — With Code


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

Midjourney中标点符号的使用指南

这篇文章研究的是标点符号在prompt中的作用。

Midjourney的prompt可以包含标点符号。我们经常使用它们来制作prompt,而不需要太多思考。毕竟,这是官方的Midjourney用户指南声明:

使用逗号,括号和连字符来帮助组织你的想法,但请记住,MidjourneyBot不会可靠地解释它们。

对于许多用户来说,“不能可靠地解释它们”意味着“不用麻烦了”。然而,标点符号对你的prompt几乎没有影响,这是真的吗?如果他们这样做了怎么办?如果它们有微妙的影响,你可以利用它们来调整你的prompt?

到目前为止我们对标点符号的了解

在我们研究标点符号是否重要之前,让我们来看看Midjourney机器人可以可靠理解的五个主要标点符号:

  1. 双连字符--用于--ar 3:2
  2. 双冒号::用于multiprompt(可以表示::两边字符的权重)和输入weights
  3. 花括号{}表示排列prompt
  4. 反斜杠\用于转义排列中的逗号。例如,/imagine prompt:a photo of {a bird\, cat, a dog\, fish}将创建两个prompts:/imagine prompt:a photo of a bird\, cat/imagine prompt:a photo of a dog, fish
  5. 空格实际上就是分隔单词或tokens的字符

另外两个标点符号是正斜杠 / 和冒号: ——但它们是在命令中使用,而不是在prompt中。

根据Midjourney常见问题解答,上述标点符号列表之外的所有其他标点符号都是“有趣的噪音”。

“有趣的噪音”表明某些事情显然正在发生,即使还没有设计出实验来揭示它。在对prompt进行故障排除时,有必要尝试一下有趣的噪音,因为它可能是打开你想要的东西的钥匙。

Midjourney的编程不支持理解逗号或连字符,但建议在prompts中使用它们,因为人类会使用它们,而且它们在数据集中可能具有很强的相关性。

到目前为止,我们已经讨论了我们所知道的标点符号。现在,让我们来看看这个“有趣的噪音”。

以下是我们将探讨的4个问题:

  1. 如果我们用标点符号超载prompt符会怎样?
  2. 何时使用连字符,何时不使用?
  3. 如果我们用不同的标点符号来区分概念或想法有关系吗?
  4. 机器人能理解由标点符号组成的表情符号吗?

方法

  • 至少重新提示3次
  • 小心使用 /shorten
  • 使用CLIP标记器
  • 使用MidjourneyV5.2进行测试

每个prompt将被重新提示至少三次,以确保一致性和可重复性。结果预计会受到随机化的影响,但目标是在再次提示后找到类似的东西或效果。

/shorten用于测试标点符号对prompt的影响。它用于检测由标点符号引起的单词“相对影响值”的变化。相对影响力的值表示token(或单词)对生成的输出是否具有更大的影响力或影响。

不幸的是, /shorten仍然是一项正在进行的工作,需要更可靠地精确定位生成图像所需的单词。例如,一些重要的单词被 /缩短划掉(划掉),但需要生成所需的图像。

但是,我们仍然可以使用它来验证prompt是否发生了变化,因为单词的相对影响值可能由于标点符号而发生了变化。

CLIP Tokenizer用于确定标点符号是否影响在prompt符中创建的tokens的数量。

Midjourney机器人会在读取prompt时将单词分解成称为“tokens”的片段。然后将tokens与训练数据进行比较以生成图像。

tokens的数量通常等于或超过单词的数量。更多的tokens并不总是好的,因为Midjourney V5.2中的prompt符最多只能容纳大约。60个tokens。

好的,让我们从现在开始寻找新的东西。

(1) 如果我们用标点符号超载prompt符会怎样?

感叹号用于表达强烈的情感。星号*符号强调消息传递应用程序中的单词或短语。如果我们把它们都塞进一个prompt中呢?对形象有影响吗?

Prompt 1 — /imagine prompt: a dog and a cat

Prompt 2 — /imagine prompt: a dog and a !!!!!**cat**!!!!

Prompt 3 — /imagine prompt: a cat and a !!!!!**dog**!!!!

Prompt 1 在没有标点符号时,为图像的外观建立基线。它创建了5个tokens。生成的图像描绘了一只没有表情或情感的狗和一只猫。

  • /shorten 分析只是忽略了猫作为重要关键字,这是令人沮丧的。
  • 为了演示标点符号的效果,我修改了prompt符,以包括短语“一张照片”-生成的图像与没有短语的图像相同(未显示图像)。据报道,狗的相对影响值为1,猫的相对影响值为0.6。

Prompt 2 用感叹号和星号填充了prompt。它生成了10个tokens,是prompt1的两倍!动物们现在表现出兴奋的迹象。令人惊讶的是,虽然“猫”这个词被标点符号包围,但狗比猫更兴奋。但摇了几下之后,这只猫也表现出兴奋的迹象。

  • 因为在prompt中没有使用其他词语来描述情感,很明显,标点符号改变了受试者的行为举止
  • 情绪的表现是随机的。偶尔,网格中的大多数图像都描绘了情感。其他时候,每个网格只有一个图像具有情感表达。

Prompt 3和Prompt 2是一样的,除了猫的位置和狗的位置互换了。因为Prompt 2中的狗狗同样兴奋,所以很难说位置的改变是否会让狗狗更开心。Prompt 3生成10个tokens,与Prompt 2相同。

  • 看到 /shorten如何识别感叹号(!!!!!cat)作为重要的tokens而忽略星号是很有趣的。Cat现在的相对值(0.46)低于没有标点符号的prompt符。

img

img

(上) /imagine prompt: a dog and a cat (下) /imagine prompt: a *dog and a !!!!!**cat**!!!!*

img

img

img

/shorten 分析结果. (上) /imagine prompt: a dog and a cat (中) /imagine prompt: a photo of a dog and a cat (下) /imagine prompt: *a photo of a dog and a !!!!!**cat**!!!!*

目前还不清楚我们是否可以针对一个主题,并在其周围使用多个标点符号来让主题“做某事”。

将prompt改为使用更少的感叹号对动物的表达几乎没有影响(图片未显示)。例如:/imagine prompt:a dog and a !cat!

不管周围有没有标点符号,狗狗们都很兴奋。(我还想在第一个图像网格中突出显示图4的6腿猫!)

img

img

(上) /imagine prompt: *a dog and a !!!!!**cat**!!!!* (下) /imagine prompt: *a cat and a !!!!!**dog**!!!!*

另一件需要注意的事情是,在单词周围加上星号将使它在Discord中斜体化。例如,/imagine prompt:dog将斜体/强调dog这个词。然而,不管有没有星号,都没有任何特殊效果。

摘要:标点符号会影响prompt中单词的相对影响力,产生的tokens数量,甚至受试者的行为举止。

(2) 什么时候用连字符,什么时候不用?

连字符是我最喜欢的连接单词的方便工具之一,它可以增加单词之间的联系和影响力。“影响力”指的是这些词在生成的图像中被表达或出现的能力。

Prompt 4 — /imagine prompt: a photo of an **elephant-like** **monster**

Prompt 5 — /imagine prompt: a photo of an **elephant like monster**

假设我们正在寻找具有某些怪物特征的大象,prompt 4的“elephant-like”链接短语比prompt5的结果更好。

根据“/shorten”分析的结果,“monster” token在prompt4中的影响较小,使主题看起来更像大象。

当prompt5中“monster” token的相对影响值增加时,我们得到一个具有大象特征的怪物。

prompt 4生成8个tokens,而prompt 5生成7个。

img

img

(上) /imagine prompt: a photo of an elephant-like monster (下) /imagine prompt: a photo of an elephant like monster

img

img

/shorten分析结果. (上) /imagine prompt: a photo of an elephant-like monster (下) /imagine prompt: a photo of an elephant like monster

什么时候使用连字符

Midjourney中的许多颜色使用连字符。在Midjourney V5 alpha中记录的一种公认的遗留颜色是带有连字符的“olive-green”。

Prompt 6 — /imagine prompt: a photo of a box **olive green**

Prompt 7 — /imagine prompt: a photo of a box **olive-green**

Prompt 8 — /imagine prompt: a photo of a box**, olive-green**

prompt8产生了最好的结果,假设我们正在寻找一个与橄榄无关的绿色盒子。它用逗号把盒子的概念和颜色分开。

prompt6有问题。如果没有连字符,机器人就会生成带有橄榄色和绿色方框的图像。如果这是你要找的,去掉连字符。

prompt7与prompt8非常相似。然而,它偶尔会生成一些绿色盒子和橄榄的图像。如果这就是你所需要的,那么就不需要加逗号了。

prompts6到8分别产生了7、8和9个tokens。标点符号增加了tokens的数量。

img

img

img

(上) /imagine prompt: a photo of a box olive green (中) /imagine prompt: a photo of a box olive-green (下) /imagine prompt: a photo of a box, olive-green

总结:连字符是用来连接单词,以增加他们的联想和影响力。它影响prompt中单词的相对重要性和生成的tokens的数量。

在对prompt进行故障处理时,请考虑添加或删除连字符,并判断生成的结果是否符合要求。

(3) 如果我们用不同的标点符号来区分概念或想法有关系吗?

Midjourney唯一的“官方”概念分隔符是双冒号::。这意味着机器人必须独立考虑概念或想法,而不是将它们结合起来。

双冒号在多提示符中被广泛使用。如果你是多提示和多提示的新手,看看这些故事:Midjourney:多提示的温和指南Midjourney滑块方法:如何通过多提示微调图像

还有其他很少讨论的概念分隔符。为了简单起见,我们将集中讨论逗号和管道符号。(注意:我将在本文中使用管道符号作为“标点符号”,尽管thesaurus.com说它不是。)

`/shorten据说与多提示符不兼容,但我发现它对短的多提示符有些作用。

Prompt 9 — /imagine prompt: a photo of a **honey bee**

Prompt 10 — /imagine prompt: a photo of a **honey, bee**

Prompt 11 — /imagine prompt: a photo of a **honey | bee**

Prompt 12 — /imagine prompt: a photo of a **honey:: bee::**

假设我们只是在寻找蜜蜂(不是蜂蜜),prompt9(没有标点符号)显然是赢家,表明蜜蜂在努力工作。

令人惊讶的是,逗号(prompt10)巧妙地将单词honey和bee分开。网格中至少有一张图像描绘了蜂巢上的蜜蜂。

  • 我曾经认为逗号对概念分离没有任何影响,但这是不正确的。它确实有微妙的影响。这个新信息使我想知道是否应该删除或添加逗号以排除将来的prompts。

双冒号(prompt12)将蜂蜜和蜜蜂的概念分开。它在合成中生成了蜜蜂和蜂蜜/蜂巢的独立图像。分离的概念是显而易见的。(注意:末尾的最后一个双冒号是可选的,但这是我喜欢的编写多提示符的风格。)

Pipe是一个发现,它证明了它可以分离概念,尽管比双冒号更弱、更模糊。

/shorten分析结果表明,标点符号改变了tokens的相对影响值。它支持这样一种看法,即逗号会微妙地影响概念分离,因为其影响值与没有逗号的prompt相似。

如前所述,生成的tokens数量随着使用标点符号的增加而增加。

从整体上看,标点符号的“概念分离强度”由高到低依次为:逗号(最弱)→管道→双冒号(最强)

img

img

(上) /imagine prompt: a photo of a honey bee (下) /imagine prompt: a photo of a honey, bee

img

img

(上) /imagine prompt: a photo of a honey | bee (下) /imagine prompt: a photo of a honey:: bee::

img

img

/shorten分析结果 (上) /imagine prompt: a photo of a honey bee (下) /imagine prompt: a photo of a honey, bee

img

img

/shorten 分析结果. (上) /imagine prompt: a photo of a honey | bee (下) /imagine prompt: a photo of a honey:: bee::

再次确认

考虑到Midjourney中概念分离的重要性,我将调查扩展到另一个主题上——海狮。

Prompt 13 — /imagine prompt: a photo of a **sea lion**

Prompt 14 — /imagine prompt: a photo of a **sea, lion**

Prompt 15 — /imagine prompt: a photo of a **sea | lion**

Prompt 16 — /imagine prompt: a photo of a **sea:: lion::**

实验结果与以往的蜜蜂实验结果一致。除了 / shorten的结果更难以解释。目前还不清楚为什么逗号会对相对影响值产生如此重大的影响。

img

img

(上) /imagine prompt: a photo of a sea lion (下) /imagine prompt: a photo of a sea, lion

img

img

(上) /imagine prompt: a photo of a sea | lion (下) /imagine prompt: a photo of a sea:: lion::

img

img

Results of /shorten analysis. (Top/Left) /imagine prompt: a photo of a sea lion (Bottom/Right) /imagine prompt: a photo of a sea, lion

img

img

/shorten分析结果. (Top/Left) /imagine prompt: a photo of a sea | lion (Bottom/Right) /imagine prompt: a photo of a sea:: lion::

我还测试了使用连字符和加号+的效果。这里没有显示生成的图像,因为没有什么特别的期望。

不出所料,连字符很好地连接了这些想法。加号对概念分离的影响可以忽略不计,但改变了/shorten 分析中的相对影响值。

摘要:最强的概念分隔符是一个双冒号,后跟一个管道和一个逗号。逗号在分隔prompt中的概念方面有微妙的作用。该管道可能具有用于分离概念的新应用程序,作为多提示符的替代方案。尚不清楚该管道是否受控制多提示符的相同规则的约束。

img

img

/shorten 分析结果. (Top/Left) /imagine prompt: a photo of a sea-lion (Bottom/ Right) /imagine prompt: a photo of a sea + lion

(4) 机器人能理解由标点符号组成的表情符号吗?

最后,让我们看看机器人是否能理解一些完全由标点符号(没有单词)组成的表情符号。

Prompt 17 — /imagine prompt: {:-), :-(, ;-), :-/, :-O, X-(}

以下是经过测试的简单表情符号列表:

:-)
:-(
;-)
:-/
:-O
X-(

你猜怎么着?机器人只能理解 :-( 悲伤的表情符号。其他的表情符号都不起作用。

嘿,Midjourney机器人,你现在不开心吗?是因为我们给你太多工作要做吗?

Images of sad people.

/imagine prompt: :-(

原文:Midjourney: The Ultimate Guide to Punctuation


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

为什么是奥本海默,成为“之父”需要哪些能力

obhm

上周去看了诺兰的《奥本海默》,说真的,要深刻了解这个片子,没有一些辅助的资料还是很难的,特别是当时的背景和时局发展,后半段对奥本海默的审批,以及各种闪现的配角(诺贝尔奖得主)。当然,本篇不想过多解读审判这条主线,更多想说说研发原子弹的庞大工程——曼哈顿计划的主持人为什么是奥本海默,他有什么过人之处,以及我们可以学到什么。

为了把这个问题讨论清楚,我们还是分四个章节来讲,分别是:

  • 曼哈顿计划的历史背景——先把整体的情况捋一下;
  • 为什么是奥本海默——选他的原因,以及他如何成功;
  • 我们学到了什么——对于创新型产品研发的启示;
  • 说说第二主角格罗夫斯——管理的艺术。

一、曼哈顿计划背景

为了让大家可以对整体的背景有一些了解,这一章节会先简要介绍背景和数据。

起因

原子弹工程的起因是1939年德国科学家哈恩和斯特拉斯曼发表了铀原子核裂变的论文,很短时间内,世界各国科学家在自己的实验室复现了该实验,并且发现可以实现链式反应,极其微量的铀235就可以释放出巨大能力。由于当时英法已经对德宣战,二战的大规模战争开始,于是这马上引起了科学界的警觉,匈牙利赴美的科学家齐拉得·莱奥呼吁大家警惕这种全新的科技会被用于战争。果不其然,德国任命量子力学奠基人之一海森堡开始了原子弹研究。

2

电影剧照:爱因斯坦和奥本海默

在美国这边,爱因斯坦(不用介绍了)和西伯格(“钚之父”,诺贝尔化学奖)给当时美国总统罗斯福写了一封倡议研发原子弹的信,希望总统下令全力研制核武器——德国人已经在海森堡的主持下率先开始了工作,如果这种超级炸弹掌握在泯灭人性的纳粹手里,那将是谁也不敢想象的一种结局。而后万尼瓦尔·布什(著名科学家、香农的导师,互联网、鼠标、图形界面等一系列产物的原始提出者)作为总负责人发起了原子弹制造计划。军方派出的总指挥是格罗夫斯准将(Leslie R. Groves),当时他刚建造好五角大楼,在曼哈顿项目中属于万尼瓦尔的下属。此人的能力非常强悍,而且难得可贵的是他积极满足项目的各种需求,但几乎不干预后来科学家们的具体工作,设置包括一些人事任命。

奥本海默加入

最初参与该项目的科学家是与奥本海默同在加州大学伯克利分校任职的欧内斯特·劳伦斯(回旋加速器发明人、诺贝尔物理学奖获得者)和芝加哥大学的阿瑟·康普顿(“康普顿效应”发现者,诺贝尔物理学奖获得者),但他们极力向格罗夫斯推荐更加才智卓越的奥本海默。奥本海默在参加曼哈顿计划之前就已经有多年的左翼活动,而且妻子、情人、弟弟全是美国共产党,这也是后来他最大的麻烦。但是格罗夫斯的厉害之处是守住安全底线的前提下,不问出身,只看是否可以为计划带来决定性贡献。于是奥本海默成为了整个曼哈顿计划的首席科学家,任职洛斯·阿拉莫斯实验室(曼哈顿计划总部)的主任,负责整个研发工作。

诺贝尔奖得主集中营

整个研发过程集聚了大量人员,巅峰时达到50余万,且其中大量科学家,诺贝尔奖(很多是之后获得)得主近百人,特别是洛斯阿拉莫斯实验室,也被称为“诺贝尔奖获得者集中营”。

除了上面提到的,还有玻尔(和爱因斯坦齐名)、费米(中子物理学之父,诺贝尔物理学奖,建成第一座原子反应堆)、查德威克(发现中子、诺贝尔物理学奖得主)、阿尔瓦雷茨(诺贝尔物理学奖得主)、费曼(物理学家、数学家,诺贝尔物理学奖获得者)、尤金·维格纳(诺贝尔物理学奖得主)、爱德华·泰勒(氢弹之父)、冯·诺依曼(计算机之父)等。

feimi

芝加哥大学费米团队建造出世界上第一个核反应堆

曼哈顿工程可能是人类历史上首个三位一体工程,既科学、军事和工业三位一体。而且可能也是在科技时代最大最复杂的工程之一。

为什么是奥本海默,他为什么可以成功

介绍了大致背景,上面的阵容应该已经空前强大了。那么,为什么,没有诺贝尔奖的奥本海默会被选为研发原子弹的总负责人呢?(事后诸葛亮般的总结

先来看看当时推荐他的欧内斯特·劳伦斯是怎么评价他的:

“曼哈顿工程”是一个要凝聚全世界最顶尖大脑的“超级工程”,但越是一流的科学家,就越是有些“恃才傲物”,必须要有一个既懂科学又懂管理的人才来把这批人管理起来,有效运转,最快达成目标。

既懂科学又懂管理,是劳伦斯的主要观点,这里其实跟重要的是“懂科学”,因为参与曼哈顿计划的都是一些什么人,大家在上面已经看到了。但是通过《奥本海默传》等书籍可以看出,之所以科学家们推举他,还有很多其他重要的原因,反而学术能力只是一种底线,而不是真正的原因。

那么我们来看看到底是哪些原因促成了他,并且领导整个项目顺利完成。

学术能力

奥本海默本身就是天才,在剑桥卡文迪许实验室学习过,当时的主任是大名鼎鼎的卢瑟福(弟子中有29名诺贝尔奖得主),后又在哥廷根大学(当时世界上最顶级学府)获得博士,师从量子力学奠基人之一的马克思玻恩。在理论天文学、核物理、光谱学和量子场论(包括量子电动力学)等方面都做出了优秀成果,而且预测了“黑洞”的存在。所以他在学术能力是可以和这些参与者一起共事的,甚至在当时,他在学术上比一些参与者还要更领先(因为一些参与者获得诺贝尔奖是在曼哈顿计划之后)。

lusehu

物理神话卢瑟福,一众大神的老师

讲故事能力

他有超强的讲故事能力。

他来到加州大学伯克利分校之后,在课堂总能把深奥的天文学、物理学知识通过让人印象深刻的故事讲述出来,所以他的学生众多,且非常受欢迎。这一点在领导曼哈顿工程时尤为重要,他在不同地点和不同时间,至少与3000人进行过工作沟通。没有这种深入浅出的讲故事和刻画的能力,很难让大家明白并统一意识。相信也是基于这一点,让当时很多科学家觉得奥本海默有一种“看见”的能力,并可以通过交流让大家共同“看见”,这是推荐他来当总负责人的原因之一。

“看见”的能力

在电影里面还提到了他经常睡不着,因为脑子停不下来,一直在播放各种运算的画面。这一点特质也非常重要,甚至我觉得在这个项目中是最重要的。因为要完成这样一个工程,他需要首先在脑子里有一个完整的蓝图,他首先要“看见”最终的样子。

然后脑子里有一张庞大繁杂的思维导图,上面动态地描绘着发展的情况:从总目标,到一级、二级、三级…目标是什么,每个环节的功能和时间节点,现在进展到哪里,哪里可能是难点…。首先要自己“看见”,才能让大家一起看见(虽然当时不能让大家一起看见,因为需要保密,50万人里面只有12人知道全盘计划)。

siweidaotu

“看见”是管理的基础,如果无法“看见”,那根本无法从全局视野推动事情的进展。其实同在曼哈顿计划的很多杰出人才在这方面也是对奥本海默非常佩服的,可以看看和他不太对付的“氢弹之父”泰勒是怎么说的:

“我不知道奥本海默是怎样做到这一切的,但是没有他的话,这项工程不知道什么时候能成功。”

系统工程

3

电影剧照:奥本海默在洛斯阿拉莫斯

曼哈顿工程的复杂度,哪怕放到现在,依然可以排在世界上五大最复杂的工程之列:
整个工程分布在16个地区进行,其中最重要是4个:

  • 费米和康普顿领导的芝加哥大学第一个原子核反应堆;
  • 在田纳西的核反应材料工厂,代号“橡树岭”,提炼铀235,8.2万人;
  • 西伯格的汉福德钚提炼工厂,6万人;
  • 奥本海默的洛斯阿拉莫斯实验室,总指挥部和组装原子弹。

Y12

橡树岭Y-12工程

在这么广大的区域,在如此多人员参与的情况下,虽然有军方的各种保障,但是管理难度依然非常大。所以在管理过程中,奥本海默运用了运筹学、控制论、信息理论、基础数学和计算机科学等学科的经验,以寻找最优解为目标出发,对组织、技术、行为和方法进行了科学的综合应用。这也在后来催生了“系统工程”学科的诞生。

语言能力

奥本海默除了学术能力,还有一些非常特殊的能力。比如他熟练掌握八门语言,包括梵语。在原子弹试爆成功之后,他用常读的印度梵文诗《摩诃婆罗多经》中的《福者之歌》选段说了一段:

“漫天奇光异彩,有如圣灵逞威。
只有一千个太阳,才能与其争辉。
……
我是死神,是世界的毁灭者。”

yuanzidan

第一颗原子弹试爆

面对多国科学家组成的大团队,拥有多国语言能力同样也是一项重要特质。

我们可以学到什么

曼哈顿工程可以算得上一个高科技产品研发项目,我们把焦点放会到自己手上的事情,也会发现如果我们作为一个owner去做一件创新的事情,同样需要这些品质,才能有效地把事情做好。

通过上面的描述,我认为要带领一个创新产品的研发,需要有以下几种能力:

  • 有扎实的技术和产品能力:这是基础能力,技术和产品,最低限度是要精通一样吧。有了这个能力,才能和共同参与的成员进行沟通,才能有整体的思考基础;
  • 有“看见”的能力:这是非常核心的能力,对于要去创造的产品,你心中必须要有一个蓝图,而且是非常清晰的,不能朦朦胧胧,这样你才能清晰知道团队的方向在哪里,还需要往前走多少路程。“看见”之后,你必须分解达成需要做的事务,一般可以分成多级事务,每个事务都会有目标、动作、组成人员和其能力,以及过程进度。这样才能搭建组织,寻找能力匹配的人员,分配工作,检查工作完成度和质量。这里需要去学习一些系统工程的方法,让自己在管理上更加科学。当然,你也可以在电脑上用XMind、Focus等软件进行管理;
  • 讲故事的能力:其实是一种非常优秀的沟通能力,而且可以将复杂的业务逻辑非常清晰、生态地同步给同伴,重点是让别人可以理解。只有将“蓝图”与团队同事分享,让他们共同看见,才能形成合力完成目标,也就是上下同欲者胜。

当然,如果你是在主导一个面向市场的产品,你可能还需要一些额外的但也同样重要的能力:

  • 需要懂PMF:PMF(Product-Market-Fit)要研究的是产品价值和市场需求是否匹配的问题,这是成功的产品必须要有的条件。这就需要你也有市场能力,有一些客户人脉,能和客户去交流MVP(最小可用品)的价值,并对市场反馈非常敏感。诚然,找到PMF是非常难的,有时候还需要一些运气,但你必须要有这种意识,并了解实现它的一些方法;
  • 产品推广能力:一个研发中的产品,很多时候都是需要在它完成前就进行推广的。这同样需要讲故事的能力,你不需要把所有特性都一一讲出来,有时候需要将它的一两个点拿出来放大。对于会讲故事的人,这并不难,因为我看见过几个讲故事很厉害的人,有时候即使他们完全没参与产品的研发过程,一样可以快速提炼价值点,并打动客户。

好吧,也许你会认为这样的人几乎很难找,是的,但这正是你的竞争力所在啊。被冠以“之父”的人,必须是要有这些能力的,而且要有“主人翁”心态,哪怕你明明知道产品最终是属于公司的,哈哈。

最后,说说管理

你也许会想,那我不会技术和产品,是不是就已经没有这个机会了。那也不是的,你看看格罗夫斯,他确实是个很厉害的人。他的能力在于知人善任,哪怕知道奥本海默有共产主义倾向。而且在奥本海默的一些用人上,他虽然不太乐意,但是依然不干涉。整部影片,从组件核心团队,到推进,到完成结果,处处可以看到他优秀的管理能力(马特达蒙饰演的效果是,一本正经的时候反而有一点幽默)。

geluosifu

格罗夫斯的另一个具体贡献是在保障上,在资源上让奥本海默无后顾之忧。这真的太重要了,别认为这些事情是奥本海默自己应该去争取,我觉得这些事情如果是奥本海默需要耗尽心机去想办法搞定的,那项目不可能顺利推进。原因无非有二:一,权限不够,虽然奥本海默已经K-6最高等级,但是仅限于研发团队,对于军方人员、大量劳动力、经费和国土资源依然没有办法调动;二、一个人需要耗费大量精力在思考项目推进的情况下,是不太可能有更多精力去思考人和人之间、信念之间的“斗争”的。

最后就是格罗夫斯很知道自己该站的位置,不会去干涉具体工具,不会想着要在原子弹工程上留下自己的印记,比如需要加点什么特性,应该长什么样子等等。这一点我也是这个态度,如果我在这个位置,除非负责人需要征求我的意见,不然我不会去强加我的思想,因为很多时候产品是一种创意,不太可能在“民主”投票中产生。

sitelaos

钢铁侠饰演的刘易斯·施特劳斯

格罗夫斯和奥本海默一样,都是优秀的管理者,而且都是业务管理者,他们的特点是善于目标管理,在用人上更看重人的优点。作为区别,电影后期的施特劳斯(小罗伯特唐尼饰演)更像是行政管理,他们更在意的是意识形态、文化,重点在发现人的缺点或者危险。

所以,如果把曼哈顿工程比作一部电影,那么格罗夫斯就是总监制,奥本海默是导演,上面的万尼瓦尔·布什就是制片人。没有技术和产品背景,你依然可以成为格罗夫斯。

好了,就写到这里!


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

用AI(大模型)重构推荐系统

AI助手的崛起

人工智能正在改变我们与在线应用程序互动的方式。目前,我们使用搜索引擎、新闻源和精心设计的菜单来导航,这些菜单引导我们找到所需的信息或服务。然而,我相信目前人工智能的创新使一种新型的推荐引擎成为可能:人工智能助手。随着Chat-GPTBard的出现,我们已经看到了这方面的证据。但是,让我们考虑一个示例来进一步说明这一点。想象一下,你正在伦敦度假,你想和一些朋友在格林威治公园野餐。在你决定日期之前,你可能会通过谷歌搜索或直接找到你喜欢的天气预报服务。接下来,您将浏览他们的站点并检查所选日期范围内的天气预报,根据最有利的天气选择一天和时间。

img

格林威治公园

如果你直接问不是更简单吗?“哪天去格林威治公园野餐最好?”

不需要搜索谷歌,不需要选择你的日子。如果它与语音助手相连,你可能甚至不需要输入任何东西,你只需要从你信任的人工智能天气助手那里得到一个建议,告诉你安排旅行的最佳日期。

在本文中,我将演示如何使用从Open AILangchain ‘s SQL Database ChainOpen Weather Map API调用的函数来实现这一点。

请注意下面的动图,展示了我在实际中开发的原型

The first shows the response to “What’s the best day to have a picnic in Greenwich park?”(第一个是对“在格林威治公园野餐最好的一天是哪天?”)

img

这是一个温和的例子,说明了什么是可能的。让我们尝试一些更复杂的方法。如果我们去冰岛旅游,想看北极光呢?我们可能会问:“When am I most likely to see the Northern Lights in Reykjavik?(我什么时候最有可能在雷克雅未克看到北极光?)”

如果您对此印象深刻,请继续阅读,我将解释它是如何工作的。

(简化的)应用架构

img

首先,我想通过提供我认为将为这些人工智能助手提供动力的架构类型的广泛而直接的概述来建立背景。

他们将使用大型语言模型 (LLM)函数调用、API请求和对结构化数据集的自动查询来向用户提供个性化的响应。

随着生态系统的成熟,这个也会成熟,但我相信一般的方法将保持不变——只是增加一些额外的功能。

这是我用来构建AI天气助手原型的通用架构,所以让我们深入了解一些技术细节,以获得更好的理解。

函数调用

在llm出现之前,解析文本需要使用Regex——它非常严格,限制了我们使用自然语言所能做的事情。

现在有了llm和函数调用,我们可以更灵活地操作自然语言。让我们检查一下函数调用本身,以理解为什么它如此强大。

在我们的AI天气助手示例中,应用程序的用户希望确定访问特定地点的最佳日期,可能是为了参加活动。

因此,我们需要三个关键的信息:地标/目的地、它的坐标(纬度、经度)和未来一段时间的天气预报。

一旦知道了地标/目的地,后两者就很简单了。但是,前者是从用户提供的自由格式文本输入派生出来的。

由于拼写错误、大小写不一致和语法错误,或者目的地可能只能通过上下文推断,因此从自由文本中确定目的地是具有挑战性的。

然而,这正是函数调用被证明是无价的地方。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
from geopy.geocoders import Nominatim
import pandas as pd
import requests
import uuid

# gets latitude and longitude
def get_lat_long(location):
geolocator = Nominatim(user_agent="my_application_" + str(uuid.uuid4()))
location = geolocator.geocode(location)
return (location.latitude, location.longitude)

# gets weather data for the enxt five days - returns a dataframe
def get_weather(location_response, location):
api_key = YOUR_OPEN_WEATHER_MAP_API_KEY # Replace with your API key from Open Weather Map
base_url = "https://api.openweathermap.org/data/2.5/forecast"
params = {
'lat': location_response[0], # latitude
'lon': location_response[1], # longitude
'appid': api_key,
'units': 'metric' # change 'metric' to 'imperial' for Fahrenheit
}
response = requests.get(base_url, params=params)
weather_data = response.json()
df = pd.json_normalize(weather_data['list']).drop(columns='weather')
df['location'] = location

return df

我们首先定义检索天气数据的函数。我们有两个独立的函数。

第一个方法接受位置作为非特定输入,并返回纬度和经度。

第二个方法接受纬度、经度和位置,并通过调用Open weather Map API返回一个包含该位置未来五天天气数据的数据框。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import openai
import pandas as pd
import json

def parse_location(query):

# OpenAI function calling

function_call = [
{
"name": "get_lat_long",
"description": "Takes the location as an argument. Returns a tuple (latiude, longitude)",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": '''Do not answer the question. Only respond with the location, or the location of the landmark/tourist attraction mentioned.
Location must be in the form City name, state code (only for the US) and country code divided by comma.
Please use ISO 3166 country codes.'''
}
},
"required": ["location"]
}
}
]

# Open AI API Call
openai.api_key = YOUR_OPEN_AI_API_KEY # Replace this with your openAI API key

message = openai.ChatCompletion.create(
model="gpt-4",
messages=[{"role": "system", "content": query}],
functions = function_call,
function_call = 'auto',
temperature=0
)

arguments = message["choices"][0]["message"]["function_call"]["arguments"]
arguments_dict = json.loads(arguments)
location = arguments_dict['location']

print(f"LOCATION!: {location}")

return location

接下来,我们设计函数调用。这里我们感兴趣的函数是我们之前定义的get_lat_long函数,它以location作为参数。我们在函数调用字典中的name键中建立它。

真正的“神奇”发生在parameters键下,我们通过其属性定义参数。

该描述尤其重要,因为它使我们能够利用大型语言模型的预测属性来帮助从查询中识别位置。

例如,如果用户询问:“参观埃菲尔铁塔的最佳日期是哪天?”,我们将收到以下回复:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<OpenAIObject chat.completion id=chatcmpl-7byJmyUNMNeYIIQhrBQ295u4JqM4C at 0x1f654544680> JSON: {
"id": "chatcmpl-7byJmyUNMNeYIIQhrBQ295u4JqM4C",
"object": "chat.completion",
"created": 1689284354,
"model": "gpt-4-0613",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "{\n \"location\": \"Paris, FR\"\n}"
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 124,
"completion_tokens": 12,
"total_tokens": 136
}
}
}
],
"usage": {
"prompt_tokens": 132,
"completion_tokens": 19,
"total_tokens": 151
}
}

我们可以看到函数调用返回了Paris, Fr作为我们的位置。这里的诀窍是,我们利用模型的强大功能,直接从查询中推断出埃菲尔铁塔的位置。

在这个关键时刻,我应该提出一个警告:虽然这个技巧到目前为止表现良好,但llm不是数据库查找,它们可能会产生幻觉并推断出错误的位置。

为了提高健壮性,可以加入一个步骤,将位置与数据库交叉引用。虽然我没有对错误率做过任何数学计算,但大多数时候,这个模型都是正确的,特别是如果你使用GPT-4以后的版本。

一旦确定了位置,我们就可以继续获取纬度和经度,最终从Open weather Map返回用户指定位置的结构化天气数据。

Langchain SQL数据库链

创新的第二部分是朗链的SQL数据库链。调用API之后,我们就有了一些结构化的天气数据。

我们可以利用Langchain的SQL数据库链来自动查询。下面是相应的代码片段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
from sqlalchemy import create_engine
import openai
import pandas as pd
from langchain import OpenAI, SQLDatabase, SQLDatabaseChain

# load data in memeory to sql lite database
def load_data(df):
engine = create_engine('sqlite:///:memory:')

# Write the data to the SQLite database
df.to_sql('weather', engine, if_exists='replace', index=False)

# Check if the data was loaded correctly
df_loaded = pd.read_sql('SELECT * FROM weather', engine)
db = SQLDatabase(engine)
return db

# run langchain sql database chain
def run_query(query, db):
openai_token = YOUR_OPENAI_KEY
llm = OpenAI(temperature=0, verbose=True, openai_api_key=openai_token)
db_chain = SQLDatabaseChain.from_llm(llm, db, verbose=True, use_query_checker=True)
response = db_chain.run(query)
return response

Note: 我对SQL数据库链使用的一个小提示工程技巧是要求模型解释它的选择,我发现这样做会产生更好的响应。这只需使用f字符串即可完成。

1
2
3
query = "What's the best day to visit the Eiffel Tower for the best view of the city?"
query_1 = f"{query} Return an explanation alongside your response, and a description of the relevant weather conditions"

SQL数据库链将自然语言请求转换为SQL查询,并在结构化天气数据上执行该查询。

让我们回想一下雷克雅未克的例子。SQL数据库链生成的SQL查询是这样的:

img

SQL数据库链能够进行一些分析推理。它可以接受用户提交的请求并基于它生成SQL查询。

通过检查SQL查询,我们可以辨别模型用来生成响应的逻辑。看看你是否相信它与反应一致。

人工智能天气助手原型可供你自己玩。你需要一个OpenAI API密钥来让它工作并批准使用GPT-4,不幸的是,该模型不能与GPT-3.5一起工作。

总结

我相信专业的人工智能助手将在众多服务行业中变得越来越普遍。

采用这些更无缝的人工智能替代方案的公司可能会从一些采用传统菜单或基于搜索的选项的公司那里抢夺市场份额。

我可以想象这样一个未来,我们与人工智能助手互动,帮助我们预订机票、安排住宿、计划约会、组织我们的财务生活——这个清单是无止境的。然而,仍有许多问题需要解决。

  • 延迟相当高,特别是考虑到我们已经习惯了即时请求和接收信息。

  • 用户体验设计是另一个将被证明是关键区别的领域。目前,许多人工智能应用程序感觉很麻烦,但用户体验将得到改善,并将成为用户采用背后的关键驱动力之一。

  • 一致性很难实现。大多数情况下,模型会返回相同的结果,但偶尔也会给出不同的建议。对于期望一定程度的确定性的用户来说,这可能是一个问题。

  • 调用多个api的成本限制了高价值用例的商业可行性。

原文:Reimagining the Recommendation Engine


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

使用AI(大模型)进行文档自动化处理

手工文档处理

随着所有人工智能创新的发生,人们很容易忘记,人们的工作的许多方面仍然是手工和繁琐的。这种单调的工作很大程度上源于重复的文档处理。在一家银行工作期间,我的一位前股东(风险经理)被大量手工文档处理任务淹没。她会花时间浏览冗长的基金招股说明书,以识别招股说明书中的关键信息,并将其转换为Excel电子表格(用于记录保存和下游分析)。

我预计许多读者将遇到类似的工作负载。因此,在本文中,我将介绍一种使用大型语言模型和检索管道自动化此类工作负载的简单方法。为了给您提供一个现实的用例,我用Morgan Stanley Funds UK的基金招股说明书来演示这一点,这是一份164页的公开文件,提供了他们一些基金的信息。这与风险经理可能会看到的招股说明书类型类似。我们将从招股说明书中提取并记录以下信息:

  • FCA产品参考编号: 6位数字,用于识别基金。
  • 基金名称: 基金名称。
  • 投资目标: 基金的目标,例如在10年内增加投资。
  • 投资政策: 基金经理制定的投资规则。
  • 投资策略: 基金经理的投资“哲学”。
  • ESG: 如果基金正在追求ESG战略。

看看下面的演示,让你更好地理解我们将做什么。

img

演示从基金招股说明书中提取信息的管道

我之所以选择这个例子,是因为我知道它与许多银行业人士息息相关。然而,这种方法可以很容易地转移到具有类似工作量的其他领域,包括保险、法律、测量、医学等。

库和先决条件

使这个例子为您工作所需的主要库是OpenAIHaystackPandashugs Face中的句子变形器。对于OpenAI,你需要注册一个API密钥——如果你还没有,你可以遵循这个教程

How to Build

在继续之前,看一下这个显示流程的高级架构图。下一节将解释图表上的每个过程。

2

Step 1 — 查询

这里的查询只是来自用户(或我们的示例中的风险管理人员)的请求。经理可能会问这样的问题:“我需要就全球可持续发展基金(Global Sustainability Fund)做报告。

Step 2 — 预处理

我们正在处理一份大型招股说明书(168页文本),需要对其进行预处理并存储以供下游使用。预处理分为两个阶段:

  1. 读入并重新格式化:我们需要把我们的招股说明书分成更小的块或句子,我们称之为文档。我们可以利用Haystack中的“开箱即用”函数来实现这一点。只需指出[convert_files_to_docs] (https://docs.haystack.deepset.ai/reference/utils-api convert_files_to_docs:文本=模块预处理- convert_files_to_docs, python: ~:文本=模块预处理- convert_files_to_docs, python)招股说明书的存储位置和初始化函数(预处理)(https://docs.haystack.deepset.ai/reference/preprocessor-api::文本=模块预处理,预处理,python: ~:文本=模块预处理,预处理,python)对象与我们文档拆分要求,我们可以轻松地将招股说明书重新格式化为更小、更易于管理的块。
  2. 转换和存储:模型实际上并不解释单词;他们解读数字。因此,我们利用句子嵌入模型将我们的句子转换为密集向量(即,保留句子语义结构的数值表示)。我们利用了一个来自hug Face句子转换器库的预训练的句子嵌入模型all-mpnet-base-v2来做到这一点。一旦我们有了嵌入,我们需要用FAISS对它们进行索引。我们还将文档和相关元数据以文本格式存储在SQL Lite数据库中。Haystack提供了一个API [FAISSDocumentStore](https://docs.haystack.deepset.ai/reference/document-store-api#faissdocumentstore:~:text=Module faiss-,FAISSDocumentStore,- python),使我们能够索引嵌入并将文档存储在磁盘上,以便稍后检索(我们将在下一节讨论检索)。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
from haystack.nodes import PreProcessor
from haystack.utils import convert_files_to_docs
from haystack.document_stores import FAISSDocumentStore
from sqlalchemy import create_engine
from haystack.nodes import EmbeddingRetriever

# pre-process docs
def preprocess_docs(doc_dir):
all_docs = convert_files_to_docs(dir_path=doc_dir)
preprocessor = PreProcessor(
clean_empty_lines=True,
clean_whitespace=True,
clean_header_footer=False,
split_by="word",
split_respect_sentence_boundary=True,
split_overlap=30,
split_length=100
)
docs = preprocessor.process(all_docs)
print(f"n_files_input: {len(all_docs)}\nn_docs_output: {len(docs)}")
return docs

# create FAISS and store
def vector_stores(docs):
engine = create_engine('sqlite:///C:/Users/johna/anaconda3/envs/longfunctioncall_env/long_functioncall/database/database.db') # change to your local directory
try:
# Attempt to drop the table
engine.execute("DROP TABLE document")
except Exception as e:
# Catch any exceptions, likely due to the table not existing
print(f"Exception occurred while trying to drop the table: {e}")

document_store = FAISSDocumentStore(sql_url='sqlite:///C:/Users/johna/anaconda3/envs/longfunctioncall_env/long_functioncall/database/database.db', faiss_index_factory_str="Flat", embedding_dim=768) # change to your local directory
document_store.write_documents(docs)

return document_store

def generate_embeddings(document_store):
retriever = EmbeddingRetriever(
document_store=document_store,
embedding_model="sentence-transformers/all-mpnet-base-v2"
)
document_store.update_embeddings(retriever)
return retriever

接下来的两个步骤定义我们的管道,它由两个节点组成:一个检索器和一个定制的OpenAI函数调用节点。

Step 3 — Retriever

检索节点利用FAISS在文档的句子嵌入和表示用户查询的句子嵌入之间执行相似性搜索(回想一下,我们用FAISS对句子嵌入进行了索引)。根据相似度评分,检索节点返回与我们的查询相似度最高的前k个文档。从本质上讲,检索使我们能够有效地从冗长的基金文档中搜索和隔离相关部分。如果您尝试处理整个168页的文档,您会发现您将很快超过任何大型语言模型的最大上下文长度(在撰写本文时)。

*注意:研究 *表明,大型语言模型,即使是那些具有显式长上下文窗口的语言模型,在没有检索的情况下对这些文档进行操作时,其性能也会下降

Step 4 — OpenAI函数调用

对于那些不熟悉函数调用的人,您可以将其视为使用OpenAI的大型语言模型构建非结构化文本数据的一种方式。有一些非结构化文本作为输入,函数调用返回结构化JSON输出。阅读我的关于函数的文章,深入了解细节。函数调用将从检索器返回的k个最相关的文档作为输入。在函数调用中,我们将希望从招股说明书中提取的关键信息定义为提示符。

我们必须足够精确地使用这里的提示来引导大型语言模型提取正确的信息。该函数调用由OpenAI的gpt -3.5 turbo驱动,可以根据我们的提示,利用其推理能力识别并记录关键信息。

最后,函数调用返回一个JSON,其中包含我们要求它提取的键细节,记录为参数。从这里开始,将这些写入DataFrame非常简单。

注意:函数调用不能作为Haystack中的节点使用,因此必须通过创建自定义组件来创建该节点。下面的脚本向您展示了如何实现这一点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
import openai
from haystack.nodes.base import BaseComponent
from typing import List
import json

class OpenAIFunctionCall(BaseComponent):
outgoing_edges = 1
def __init__(self, API_KEY):
self.API_KEY = API_KEY

def run(self, documents: List[str]):

try:
document_content_list = [doc.content for doc in documents]
print("documents extracted")
document_content = " ".join(document_content_list)
except Exception as e:
print("Error extracting content:", e)
return
functions = [
{
"name": "update_dataframe",
"description": "write the fund details to a dataframe",
"parameters": {
"type": "object",
"properties": {
"Product_reference_num": {
"type": "string",
"description": "The FCA product reference number which will be six or seven digits"
},
"investment_objective": {
"type": "string",
"description": "You should return the investment objective of the fund. This is likely to be something like this: The Fund aims to grow your investment over t – t + delta t years"
},
"investment_policy": {
"type": "string",
"description": "Return a summary of the fund's investment policy, no more than two sentences."
},
"investment_strategy": {
"type": "string",
"description": "Return a summary of the fund's investment strategy, no more than two sentences."
},
"ESG": {
"type": "string",
"description": "Return either True, or False. True if the fund is an ESG fund, False otherwise."
},
"fund_name": {
"type": "string",
"description": "Return the name of the fund"
},
},
},
"required": ["Product_reference_num",
"investment_objective",
"investment_policy",
"investment_strategy",
"ESG",
"fund_name"]
}
]

openai.api_key = self.API_KEY
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo-0613",
messages=[{"role": "system", "content": document_content}],
functions=functions,
function_call="auto", # auto is default, but we'll be explicit
)

function_call_args = json.loads(response["choices"][0]["message"]["function_call"]["arguments"])

return function_call_args, "output_1"

def run_batch(self, documents: List[str]):
# You can either process multiple documents in a batch here or simply loop over the run method
results = []
for document_content in document_content:
result, _ = self.run(document_content)
results.append(result)
return results, "output_1"

一旦定义了自定义函数调用,将其与管道中的检索器结合在一起就很简单了。

1
2
3
4
5
6
7
8
from haystack import Pipeline
from function_call import OpenAIFunctionCall

def create_pipeline(retriever, API_KEY):
p = Pipeline()
p.add_node(component=retriever, name="retriever", inputs=["Query"])
p.add_node(component=OpenAIFunctionCall(API_KEY), name="OpenAIFunctionCall", inputs=["retriever"])
return p

这个Github库可供您探索;有一个笔记本和一个带有Streamlit前端的原型版本。

结论

这种方法非常有效;然而,本演示是为本基金招股说明书设计的。在实际的业务用例中,每个招股说明书可能使用不同的术语或应用不同的标准。尽管大型语言模型在这种情况下往往是健壮的,但我怀疑您将不得不以更复杂的方式设计流程来处理细微差别。我所展示的是,将函数调用与检索相结合可以提供大量自动化可能性,这些可能性相对容易实现。

原文:Automate Tedious Document Processing


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

langchain的替代方案

由于OpenAI创建了允许开发人员使用GPT-3和GPT-4语言模型的api, LangChain等工具也得到了蓬勃发展。它们的附加值是多少?它们提供了简单而通用的抽象,使开发人员能够试验大型语言模型(llm),这些模型不仅来自OpenAI,还来自Cohere、Anthropic等。

这些工具或模块还允许开发人员合并专门的矢量存储,这对于存储单词embedding特别有用。单词的向量化是至关重要的,因为它通过减轻维度的诅咒来促进像GPT这样的语言模型的训练。

在这些工具中,LangChain无疑是最知名和最广泛使用的。我自己也写了很多关于如何使用LangChain的教程。我还写过一些关于LangChain局限性的文章,它的接口可能过于复杂,其抽象在生产环境中的实用性还有待证明。

LangChain的策略

在我看来,LangChain的创造者的策略是通过合作来实现增长。目前,LangChain集成了12个聊天模型,100多个文档加载器,50多个llm(大型语言模型),众多检索器,embedding模型,工具和向量存储。看来,LangChain的目标是成为连接各种解决方案的重要枢纽,以开发利用llm的应用程序。

这种策略很强大,因为它往往会使LangChain变得不可或缺。目标似乎是使LangChain成为基于LLM的应用程序生态系统的本地语言。至少从市场营销的角度来看,这种策略似乎是有效的。从本质上讲,LangChain作为一个API连接器,具有一些通用的抽象,可以有效地利用这些API。

这个策略面临的挑战

这种方法的问题是,作为开发人员,您最终会使用一个笨重的系统来实现一些简单的东西。这就像用锤子打苍蝇一样;您可以轻松地连接到各种API,但在为您的特定用例定制庞大模块的复杂性中,您将失去这些好处。不幸的是,LangChain之于基于llm的应用程序并不像Flask之于Python web开发。

此外,将一个开源模块商业化也是一个挑战。考虑到LangChain最近获得了1000万美元的VC(风险投资)种子基金,他们无疑会受到激励去寻找盈利解决方案。这解释了为什么LangChain推出了LangSmith,以实现对基于llm的应用程序的监控。

另一种选择:

由于所有这些原因,我想在这里提出一个LangChain的替代品:LlamaIndex。

我最欣赏的是LlamaIndex的清晰使命:将大型语言模型(LLM)与数据源连接起来,用于上下文学习或部署检索增强生成(RAG)系统。它是清晰的、集中的,并且可以立即可视化用例。例如,部署一个允许与存储在Notion中的文档进行对话的RAG系统是一个在企业环境中非常有用的用例。

下面来看看LlamaIndex提供了什么:

  • 数据连接器:这些连接器从其原生源和格式中摄取现有数据。这些可以是api、pdf、SQL等等。
  • 数据索引:这些以中间表示形式结构化数据,便于llm使用。
  • 引擎:这些提供对数据的自然语言访问。例如:
    • 查询引擎:这些是用于知识增强输出的强大检索接口。
    • 聊天引擎:这些是多消息的会话接口,“来回”与您的数据交互。
  • 数据代理:这些是llm支持的知识工作者,通过工具增强,从简单的辅助功能到API集成等等。
  • 应用程序集成:这些将羊驼指数连接回您的生态系统的其余部分。它可以是LangChain、Flask、Docker、ChatGPT或其他任何东西。

在快速阅读文档后,我很容易识别用例。例如,我遇到了一个允许读取GitHub存储库内容的类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class llama_index.readers.GithubRepositoryReader(owner: str, repo: str, use_parser: bool = True, verbose: bool = False, github_token: Optional[str] = None, concurrent_requests: int = 5, ignore_file_extensions: Optional[List[str]] = None, ignore_directories: Optional[List[str]] = None)
Github repository reader.

Retrieves the contents of a Github repository and returns a list of documents. The documents are either the contents of the files in the repository or the text extracted from the files using the parser.

EXAMPLES

reader = GithubRepositoryReader("owner", "repo")
branch_documents = reader.load_data(branch="branch")
commit_documents = reader.load_data(commit_sha="commit_sha")
load_data(commit_sha: Optional[str] = None, branch: Optional[str] = None) → List[Document]
Load data from a commit or a branch.

Loads github repository data from a specific commit sha or a branch.

PARAMETERS
commit – commit sha

branch – branch name

RETURNS
list of documents

load_langchain_documents(**load_kwargs: Any) → List[Document]
Load data in LangChain document format.

多亏了这一点,人们可以开发一个应用程序,通过聊天与GitHub存储库进行交互。

img

原文:Everyone Talks About LangChain But This Alternative Seduced Me


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

互联网诞生以来的31种商业模式(21-31)

互联网诞生以来的31种商业模式(1-10)
互联网诞生以来的31种商业模式(11-20)

21. 点对点(P2P)业务模式

在P2P商业模式中,两个人直接互动买卖商品和服务,而不需要第三方或使用平台。

案例: OLX

Peer-to-peer (P2P) Business Model

译者:其实放在国内,我理解的就是类似闲鱼和瓜子二手车,也就是所谓的没有中间商赚差价!!!

这样的平台的收费方式一般两种:1.广告排名;2.数字交易服务费(确实不是中间商)。

22. P2P借贷商业模式

在P2P借贷业务模式中,一个个人(“P2P贷款人”)向另一个个人(“P2P借款人”)借出/投资或借钱。

案例: Kabbage

P2P Lending as a business model

这也被称为“社交借贷”,因为它允许个人直接相互借贷,而无需使用官方金融机构作为中介。

译者:P2P在国内已经完全终结,就不多说了。

23. 经纪业务模式

经纪业务通常向一方或双方收取佣金或费用,以换取所提供的服务。

案例: Robinhood, Coinbase, and ebay

Brokerage business model

Brokerage business model

经纪业务在房地产、金融和在线市场中很常见,通常按以下模式运作。

Brokerage business model

经纪业务模式的类型

  1. 买卖匹配模式 ——他们匹配买卖交易并从中收取佣金:例子:-金融经纪人,保险经纪人等

  2. 分类广告主模式——这些经纪人根据广告的时间、地点、大小或性质向广告主收取费用。**例子:- Craiglist **

译者:这是非常传统的业务,只是现在线上化了。但是不仅仅贝壳等是经纪人业务,包括赶集等也是。

24. 代发货商业模式

Drop shipping是一种电子商务零售模式,允许商店销售产品而不保留任何实物库存。

Drop shipping Business model

当客户下订单时,履行来自第三方供应商和物流合作伙伴的订单。

Dropshipping商业模式的关键要素:

  • 零售商 ——产品组合和客户体验
  • 填充 ——管理,运输,并履行订单
  • 客户 ——购买订单

托运优势

  • 需要更少的资金(低开销-无库存或仓储)
  • 入门容易(少于100美元)
  • 灵活的工作地点
  • 更易测试新产品

译者:这其实就是一件代发模式,我看网上很多人发源于义乌,国外抄的我们。但是目前国外这种模式起来比较凶猛,包括跨境。

这个模式,对于卖家来说,需要自己会搞流量——适合于会玩直播的朋友们;对于第三方和供应商来说,如果可以实现分仓(比如国内在北京、上海、广州、西安和成都搞五大仓,保证80%以上地区48小时内到货),那就是真实的竞争力!

25. 空间即服务商业模式

它基于共享经济的理念,为千禧一代提供在共享空间生活或工作的灵活性,而不用担心所有权或租赁问题。

案例: WeWork, Airbnb

Space as a Service Business Model

WeWork business model

像WeWork这样的公司充当了房地产、法律合规、维护和维修业务之间的中间层。

Space as a Service Business Model

译者:WeWork是在商业办公领域,Airbnb是在民宿旅游层面。目前看来Airbnb发展好很多,WeWork目前面临破产保护,也差点让孙正义跪了。

26. 第三方物流(3PL)业务模式

在第三方物流业务模式中,企业将其产品的分销、仓储和履行外包给代表其执行这些流程的外部物流公司。

案例: Fulfilment by Amazon, Ship Bob, etc.

3rd party logistic (3PL) business model

第三方物流

第三方物流合作伙伴处理进站和出站的仓储、履行和某些商品的退货,并收取一定的费用。

入库物流是指采购和安排产品从供应商到您的仓库的运输。

出站物流是指物品通过公司的生产线、仓库,最终到达客户手中的流动。

3rd party logistic (3PL) business model

译者:这种模式在国内四通一达其实都在做,中国的小件物流还是很强大的,另外京东和菜鸟也在进行集中式和加盟式的物流仓储业务。

27. 最后一英里配送作为一种商业模式

最后一英里交付包括供应链中将服务和产品带给最终客户的一系列活动。

案例: Gojek, Postmates, Rappi, etc

Last Mile delivery as a business model

最后一英里也与按需服务交织在一起,通常有一个高峰周期,尤其是在晚上。

译者:天哪,我发现这些模式在国内都已经做得更超前了,一个美团外卖、一个饿了吗,再加上一个叮叮买菜,如果在国外,那肯定是无敌手的,所以不做解释了。这是中国已经发展的很厉害的O2O。

28. 联盟商业模式

联盟营销是一种推广其他公司产品并收取每笔销售佣金的盈利策略。

译者:简单说就是淘宝客这种模式,按推广到最终下单进行结算,也就是CPS,或者直接点:抽佣。

案例: Amazon, Skillshare, Hubspot, etc

Affiliate business model

我相信你最喜欢的youtube正在使用这些简短的亚马逊链接来获得来自这些链接的每笔销售的5%。

img

使用联盟商业模式的优势

  • 它使许多独立的营销人员能够代表它进行营销,并获得成功费或佣金。
  • 为系统带来透明度,为影响者提供独特的跟踪链接和在线仪表板,以查看他们的收入。
  • 获取促销材料并了解最新优惠。

29. 虚拟商品商业模式

这也被称为应用内购买,即你需要在应用内购买无形产品。

案例: Candy Crush, Roblox, PubG, etc

virtual goods business model

可消费产品就像在游戏中购买货币,而这些货币会在适当的时候用完。

非消耗性产品是指用户无需反复购买即可获得永久利益的产品。

译者:苹果APP的常用方式就是应用内购买,当然,游戏充钻这些更直接。另外,我记得iOS上的微信应用在虚拟商品方面是不能支付的,不知道现在两家和解了没。

30. 云厨房商业模式

也被称为幽灵厨房,黑暗厨房,黑盒子厨房等

专门通过外卖渠道销售食物的餐馆。

这些餐馆不提供实际的就餐体验,而是只为在家用餐的顾客提供服务。

案例:NextBite, Faaso’s

Cloud Kitchen Business Models

译者:在国内好像也很多了,包括在外卖兴起的早期,很多店也是不需要门店的。

31. 众包商业模式

众包 = 人群作为特定平台的资源。

在众包的商业模式中,你自愿从世界各地的人那里获得帮助,而不需要雇佣他们作为正式员工。

Crowdsourcing Business model

众包平台类型

  1. 开源软件

允许开发人员访问软件源代码来修改或改进它。

示例:Linux操作系统和Firefox浏览器。

  1. **众筹 **

译者:在国内目前众筹也越来越少了,主要还是信任的问题,特别在监管不健全的时候。

PLUS1. 批发转零售

这是一个附加商业模式,一般是用1元买一个服务,然后通过分发,用3元卖给更多的人。

比如28.com,去央视、门户等买广告,然后把自己的首页切成几百个小广告,让更多的小广告主购买。

再比如前段时间大量的ChatGPT代理,他们付费给OpenAI买接口服务,然后再做个应用卖给更多人。

好了,31种商业模式已经讲完,希望对大家有帮助啊!


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

RAG和微调哪个是LLM优化的最优解

img

序言

随着对大型语言模型(llm)的兴起,许多开发人员和组织都在忙着利用它的能力构建自己的应用程序。然而,当预训练的大语言模型开箱即用的表现不如预期时,关于如何提高LLM应用程序性能的问题就被提了出来。就目前来说,这个问题可以具象到:我们应该使用检索增强生成(RAG)还是模型微调(Fine-Tuning)来改进结果?

在深入研究之前,让我们揭开这两种方法的神秘面纱:

RAG: 这种方法将检索(或搜索)的能力集成到LLM文本生成中。它结合了检索系统(从大型语料库中获取相关文档片段)和LLM(使用这些片段中的信息生成答案)。本质上,RAG帮助模型“查找”外部信息以改进其响应。

img

微调: 这是采用预训练的LLM并在较小的特定数据集上进一步训练它以使其适应特定任务或提高其性能的过程。通过调优,我们根据数据调整模型的权重,使其更适合应用程序的独特需求。

img

RAG和微调都是增强基于llm的应用程序性能的强大工具,但它们处理优化过程的不同方面,这在选择一个而不是另一个时至关重要。

以前,我经常建议组织在进行微调之前先试验一下RAG。这是基于我的看法,即两种方法都获得了类似的结果,但在复杂性、成本和质量方面有所不同。我甚至用下图来说明这一点:

img

在这个图中,像复杂性、成本和质量这样的各种因素沿着一个维度表示。外卖呢?RAG更简单,更便宜,但其质量可能无法匹配。我的建议通常是:从RAG开始,评估它的性能,如果发现不足,就转向微调。

然而,我的观点后来发生了变化。我认为将RAG和调优视为实现相同结果的两种技术过于简单化了,只是其中一种比另一种更便宜,更简单。它们从根本上是不同的——不是“共线性”,而是“正交”——并且满足LLM应用程序的不同要求。

为了更清楚地说明这一点,考虑一个简单的现实类比:当被问到“我应该用刀还是用勺子吃饭?”,最合乎逻辑的反问是:“那你在吃什么?”我问朋友和家人这个问题,每个人都本能地反问,表明他们不认为刀和勺子是可以互换的,或者一个是另一个的劣等变体。

这是怎么回事?

在这篇博文中,我们将深入探讨不同维度上区分RAG和调优的细微差别,在我看来,这些细微差别对于确定特定任务的最佳技术至关重要。此外,我们将查看LLM应用程序的一些最流行的用例,并使用在第一部分中建立的维度来确定哪种技术可能最适合哪种用例。在这篇博文的最后一部分,我们将确定在构建LLM应用程序时应该考虑的其他方面。这其中的每一个都有自己的博客文章,因此我们只能在这篇文章的范围内简要地介绍一下。

你为什么要在意?

为适应大型语言模型选择正确的技术会对NLP应用程序的成功产生重大影响。选择错误的方法会导致:

  • 模型在特定任务上表现不佳,导致输出不准确。
  • 如果该技术没有针对您的用例进行优化,则会增加模型训练和推理的计算成本。
  • 如果以后需要转向不同的技术,则需要额外的开发和迭代时间。
  • 延迟部署应用程序并将其呈现在用户面前。
  • 如果选择过于复杂的适应方法,则缺乏模型可解释性。
  • 由于尺寸或计算限制,难以将模型部署到生产中。

RAG和微调之间的细微差别涵盖了模型体系结构、数据需求、计算复杂性等等。忽略这些细节可能会破坏你的项目时间表和预算

这篇博文的目的是通过清楚地列出每种技术的优势,避免浪费精力。有了这些见解,您就可以从第一天开始就采用正确的适应方法。详细的比较将使您能够做出最佳的技术选择,以实现您的业务和AI目标。本指南为工作选择正确的工具将使您的项目获得成功

提高性能的关键考虑因素

在我们选择RAG vs Fintuning之前,我们应该沿着一些维度评估我们的LLM项目的需求,并问自己一些问题。

我们的用例是否需要访问外部数据源?

在选择调优LLM还是使用RAG时,一个关键的考虑因素是应用程序是否需要访问外部数据源。如果答案是肯定的,那么RAG可能是更好的选择。

根据定义,RAG系统旨在通过在生成响应之前从知识来源中检索相关信息来增强LLM的能力。这使得该技术非常适合需要查询数据库、文档或其他结构化/非结构化数据存储库的应用程序。检索器和发电机组件可以优化以利用这些外部源。

相比之下,虽然有可能对LLM进行微调以学习一些外部知识,但这样做需要来自目标领域的大型标记的问答对数据集。该数据集必须在底层数据更改时更新,这使得频繁更改数据源变得不切实际。微调过程也没有明确地为查询外部知识所涉及的检索和推理步骤建模。

因此,总而言之,如果我们的应用程序需要利用外部数据源,那么使用RAG系统可能比仅仅通过调优来尝试“导入”所需的知识更有效和可伸缩。

我们是否需要修改模型的行为、写作风格或特定领域的知识?

另一个需要考虑的非常重要的方面是,我们需要多少模型来调整它的行为、它的写作风格,或者为特定领域的应用程序定制它的响应。

微调卓越的能力,以适应LLM的行为,具体的细微差别,音调,或术语。如果我们想让模型听起来更像医学专业人士,用诗意的风格写作,或者使用特定行业的行话,对特定领域的数据进行微调可以让我们实现这些定制。这种影响模型行为的能力对于与特定风格或领域专业知识保持一致至关重要的应用程序是必不可少的。

RAG虽然在整合外部知识方面很强大,但主要侧重于信息检索,并没有根据检索到的信息固有地调整其语言风格或领域特异性。它将从外部数据源中提取相关内容,但可能不会显示出经过微调的模型所能提供的细微差别或领域专业知识。

因此,如果我们的应用程序需要专门的写作风格或与特定于领域的本地语言和惯例进行深度对齐,那么调优提供了实现这种对齐的更直接的途径。它提供了与特定受众或专业领域真正产生共鸣所需的深度和定制,确保生成的内容感觉真实且消息灵通。

快速回顾

在决定使用哪种方法来提高LLM应用程序性能时,这两个方面是迄今为止需要考虑的最重要的方面。有趣的是,在我看来,它们是正交的,可以单独使用(也可以组合使用)。

img

然而,在深入研究用例之前,在选择方法之前,我们应该考虑几个关键方面:

抑制幻觉有多重要?

大语言模型的一个缺点是他们倾向于产生幻觉——编造没有现实基础的事实或细节。在准确性和真实性至关重要的应用程序中,这可能是非常有问题的。

通过将模型建立在特定领域的训练数据中,微调可以在一定程度上帮助减少幻觉。然而,当面对不熟悉的输入时,模型仍然可能产生响应。需要对新数据进行再培训,以不断减少虚假编造。

相反,RAG系统天生就不容易产生幻觉,因为它们的每个反应都是基于检索到的证据。在生成器构造答案之前,检索器从外部知识来源识别相关事实。这个检索步骤作为事实检查机制,降低了模型虚构的能力。生成器被限制为合成检索上下文支持的响应。

因此,在压制谎言和虚构的应用中,RAG系统提供了内置机制来最大限度地减少幻觉。在生成响应之前检索支持性证据使RAG在确保实际准确和真实的输出方面具有优势。

有多少有标签的训练数据可用?

当决定在RAG和微调之间进行选择时,要考虑的一个关键因素是我们可以处理的特定于领域或任务的标记训练数据的数量。

调整LLM以适应特定的任务或领域在很大程度上取决于可用标记数据的质量和数量。丰富的数据集可以帮助模型深入理解特定领域的细微差别、复杂性和独特模式,从而生成更准确和上下文相关的响应。然而,如果我们使用的是有限的数据集,那么微调所带来的改进可能是微不足道的。在某些情况下,缺乏数据集甚至可能导致过拟合,其中模型在训练数据上表现良好,但在看不见的或现实世界的输入上挣扎。

相反,RAG系统独立于训练数据,因为它们利用外部知识来源来检索相关信息。即使我们没有广泛的标记数据集,RAG系统仍然可以通过访问和合并来自外部数据源的见解来胜任工作。检索和生成的结合确保系统保持信息灵通,即使领域特定的训练数据是稀疏的。

从本质上讲,如果我们有丰富的标记数据来捕获领域的复杂性,微调可以提供更裁剪和精细的模型行为。但是在此类数据有限的场景中,RAG系统提供了一个健壮的替代方案,确保应用程序通过其检索功能保持数据知情和上下文感知。

数据是静态的还是动态的?

在RAG和调优之间进行选择时要考虑的另一个基本方面是数据的动态性。数据更新的频率有多高,模型保持最新的必要性有多大?

对特定数据集的LLM进行微调意味着模型的知识在训练时成为该数据的静态快照。如果数据经历频繁的更新、更改或扩展,这可能很快使模型过时。为了使LLM在这种动态环境中保持最新状态,我们必须经常对其进行再培训,这一过程既耗时又耗费资源。此外,每次迭代都需要仔细监控,以确保更新的模型在不同的场景中仍然表现良好,并且没有在理解中产生新的偏差或差距。

相反,RAG系统在具有动态数据的环境中具有固有的优势。它们的检索机制不断地查询外部源,确保它们用于生成响应的信息是最新的。随着外部知识库或数据库的更新,RAG系统无缝地集成了这些更改,在不需要频繁的模型再训练的情况下保持其相关性。

总而言之,如果我们正在努力应对快速发展的数据环境,RAG提供的敏捷性很难与传统的调优相匹配。通过始终保持与最新数据的连接,RAG确保生成的响应与信息的当前状态保持一致,使其成为动态数据场景的理想选择。

我们的LLM应用程序需要有多透明/可解释?

要考虑的最后一个方面是我们需要深入了解模型决策过程的程度。

对LLM进行微调,虽然非常强大,但操作起来就像一个黑盒子,使其反应背后的原因更加不透明。由于模型内化了数据集的信息,因此识别每个响应背后的确切来源或原因变得具有挑战性。这可能使开发人员或用户难以信任模型的输出,特别是在关键应用程序中,在这些应用程序中,理解答案背后的“为什么”是至关重要的。

另一方面,RAG系统提供了在单独调优的模型中通常找不到的透明度级别。考虑到RAG的两步性质——检索然后生成——用户可以窥视到这个过程。检索组件允许检查哪些外部文档或数据点被选择为相关的。这提供了一种有形的证据或参考线索,可以对其进行评估,以了解建立响应的基础。在需要高度问责制或需要验证生成内容的准确性的应用程序中,将模型的答案追溯到特定数据源的能力是非常宝贵的。

从本质上讲,如果透明度和解释模型响应的基础的能力是优先考虑的,那么RAG提供了一个明显的优势。通过将响应生成分解为不同的阶段并允许洞察其数据检索,RAG在其输出中培养了更大的信任和理解。

总结

在考虑这些维度时,在RAG和微调之间进行选择变得更加直观。如果我们需要倾向于获取外部知识和重视透明度,RAG是我们的首选。另一方面,如果我们正在使用稳定的标记数据,并旨在使模型更接近特定需求,则微调是更好的选择。

img

在下一节中,我们将看到如何基于这些标准评估流行的LLM用例。

Use cases

让我们来看看一些流行的用例,以及如何使用上述框架来选择正确的方法:

总结(在专门的领域和/或特定的风格)

**1. 需要外部知识吗?**对于以以前的摘要样式进行摘要的任务,主要数据源将是以前的摘要本身。如果这些摘要包含在静态数据集中,则几乎不需要持续的外部数据检索。但是,如果有一个经常更新的动态摘要数据库,并且目标是不断地使样式与最新条目保持一致,那么RAG在这里可能很有用。

**2. 需要模型调整吗?**这个用例的核心围绕着适应一个专门的领域或一个和/或一个特定的写作风格。微调特别擅长捕捉风格上的细微差别、音调变化和特定的领域词汇表,使其成为这个维度的最佳选择。

**3. 最小化幻觉的关键?**幻觉在大多数LLM申请中都是有问题的,包括总结。然而,在这个用例中,要摘要的文本通常作为上下文提供。与其他用例相比,这使得幻觉不那么令人担忧。源文本限制了模型,减少了想象中的虚构。因此,尽管事实的准确性总是可取的,但鉴于上下文基础,抑制幻觉是总结的较低优先级。

**4. 有培训数据吗?**如果有大量以前的总结,这些总结以模型可以从中学习的方式被标记或结构化,那么微调就成为一个非常有吸引力的选择。另一方面,如果数据集是有限的,并且我们依靠外部数据库进行风格对齐,RAG可以发挥作用,尽管它的主要优势不是风格适应。

**5. 数据有多动态?**如果先前摘要的数据库是静态的或不经常更新,则微调模型的知识可能会在较长时间内保持相关性。但是,如果摘要经常更新,并且需要模型不断地与最新的风格变化保持一致,那么由于RAG的动态数据检索功能,它可能具有优势。

**6. 需要透明度和可解释性?**这里的主要目标是风格一致性,所以特定摘要风格背后的“为什么”可能没有其他用例那么重要。也就是说,如果需要追溯并了解哪些先前的摘要影响了特定的输出,RAG提供了更多的透明度。不过,这可能是这个用例的次要问题。

建议:对于这个用例微调**似乎是更合适的选择。主要目标是风格对齐,这是微调的亮点。假设有相当数量的以前的总结可用于培训,微调LLM将允许深度适应所需的风格,捕捉领域的细微差别和复杂性。但是,如果摘要数据库是非常动态的,并且追踪影响是有价值的,那么可以考虑采用混合方法或倾向于RAG。

组织知识(即外部数据)问答系统

**1. 需要外部知识吗?**依赖于组织知识库的问答系统本质上需要访问外部数据,在这种情况下,是组织的内部数据库和文档存储。该系统的有效性取决于其从这些资源中挖掘和检索相关信息以回答查询的能力。考虑到这一点,RAG作为更适合这个维度的选择脱颖而出,因为它被设计为通过从知识来源检索相关数据来增强LLM功能。

**2. 需要模型调整吗?**根据组织及其领域的不同,可能需要模型与特定的术语、语气或约定保持一致。虽然RAG主要侧重于信息检索,但微调可以帮助LLM调整其对公司内部方言或其领域细微差别的反应。因此,对于这个维度,取决于特定的需求微调可能会发挥作用。

**3. 最小化幻觉的关键?**在这个用例中,由于大语言模型的知识限制,幻觉是一个主要问题。如果模型无法根据它所训练的数据回答问题,它几乎肯定会(部分或全部)恢复到编造一个看似合理但不正确的答案。

**4. 有培训数据吗?**如果组织有一个结构化和标记的先前回答问题的数据集,这可以支持微调方法。然而,并非所有的内部数据库都是为培训目的而标记或构建的。在数据没有整齐地标记或主要关注检索准确和相关答案的场景中,RAG无需大量标记数据集即可利用外部数据源的能力使其成为一个引人注目的选择。

**5. 数据有多动态?**组织中的内部数据库和文档存储可能是高度动态的,有频繁的更新、更改或添加。如果这种动态是组织知识库的特征,RAG提供了一个明显的优势。它不断地查询外部来源,确保其答案基于最新的可用数据。微调需要定期的再培训来跟上这些变化,这可能是不切实际的。

**6.需要透明度和可解释性?**对于内部应用程序,特别是在金融、医疗保健或法律等领域,理解答案背后的推理或来源可能是至关重要的。由于RAG提供了检索和生成的两步过程,因此它可以更清楚地了解哪些文档或数据点影响了特定的答案。这种可追溯性对于可能需要验证或进一步调查某些答案来源的内部涉众来说是无价的。

**建议:**对于这个用例 一个RAG系统似乎是更合适的选择。考虑到对组织不断发展的内部数据库的动态访问的需求,以及在回答过程中对透明度的潜在需求,RAG提供的功能很好地满足了这些需求。但是,如果非常强调裁剪模型的语言风格或适应特定于领域的细微差别,则可以考虑合并调优元素。

客户支持自动化

(即自动聊天机器人或帮助台解决方案,为客户查询提供即时响应)

**1. 需要外部知识吗?**客户支持通常需要访问外部数据,特别是在处理产品详细信息、帐户特定信息或故障排除数据库时。虽然许多查询可以用一般知识解决,但有些查询可能需要从公司数据库或产品faq中提取数据。在这里,RAG从外部来源检索相关信息的能力将是有益的。然而,值得注意的是,许多客户支持交互也基于预定义的脚本或知识,这可以通过微调模型有效地解决。

**2. 需要模型调整吗?**客户互动需要一定的语气、礼貌和清晰,也可能需要公司特定的术语。微调对于确保LLM适应公司的声音、品牌和特定术语,确保一致和品牌一致的客户体验尤其有用。

**3. 最小化幻觉的关键?**对于客服聊天机器人来说,避免虚假信息对于维护用户信任至关重要。当面对不熟悉的查询时,仅微调就会使模型容易产生幻觉。相反,RAG系统通过在检索到的证据中接地响应来抑制捏造。这种对事实来源的依赖使RAG聊天机器人能够最大限度地减少有害的谎言,并在准确性至关重要的情况下为用户提供可靠的信息。

**4. 有培训数据吗?**如果一家公司有客户互动的历史记录,那么这些数据对于调整是非常宝贵的。以前的客户查询及其解决方案的丰富数据集可用于训练模型,以便在将来处理类似的交互。如果这样的数据是有限的,RAG可以通过从外部来源(如产品文档)检索答案来提供一个备用方案。

**5. 数据有多动态?**客户支持可能需要解决有关新产品、更新政策或更改服务条款的查询。在产品阵容、软件版本或公司策略经常更新的场景中,RAG动态提取最新文档或数据库的能力是有利的。另一方面,对于更多的静态知识领域,微调就足够了。

**6. 需要透明度和可解释性?**虽然透明度在某些领域是必不可少的,但在客户支持方面,主要关注的是准确、快速和礼貌的回应。然而,对于内部监控、质量保证或处理客户纠纷,具有关于答案来源的可追溯性可能是有益的。在这种情况下,RAG的检索机制提供了一个额外的透明层。

建议:对于客户支持自动化混合方法**可能是最佳的。微调可以确保聊天机器人与公司的品牌、语气和一般知识保持一致,处理大多数典型的客户查询。然后,RAG可以作为一个补充系统,介入更动态或更具体的查询,确保聊天机器人可以从最新的公司文档或数据库中提取信息,从而最大限度地减少幻觉。通过整合这两种方法,公司可以提供全面、及时和品牌一致的客户支持体验。

img

Image by author

需要考虑的其他方面

如上所述,在决定是使用RAG还是微调(或两者都使用)时,还应该考虑其他因素。我们不可能深入研究它们,因为它们都是多方面的,并且不像上面的某些方面那样有明确的答案(例如,如果没有训练数据,则根本不可能进行微调)。但这并不意味着我们应该无视它们:

扩展性

随着组织的发展和需求的演变,所讨论的方法的可扩展性如何?考虑到RAG系统的模块化特性,它可能提供更直接的可伸缩性,特别是在知识库增长的情况下。另一方面,经常微调以适应扩展的数据集可能需要大量的计算。

时延和实时性要求

如果应用程序需要实时或接近实时的响应,请考虑每种方法引入的延迟。RAG系统需要在生成响应之前检索数据,与基于内部化知识生成响应的经过微调的LLM相比,RAG系统可能会引入更多的延迟。

维护与支持

考虑长远。哪个系统更符合组织提供一致维护和支持的能力?

RAG可能需要维护数据库和检索机制,而微调则需要一致的再训练工作,特别是在数据或需求发生变化的情况下。

稳健性和可靠性

每种方法对不同类型输入的鲁棒性如何?虽然RAG系统可以从外部知识来源中提取,并且可以处理广泛的问题,但是一个精心调整的模型可能会在某些领域提供更多的一致性。

道德及私隐问题

存储和从外部数据库检索可能会引起隐私问题,特别是如果数据是敏感的。另一方面,一个经过微调的模型,虽然不查询实时数据库,但仍然可能产生基于其训练数据的输出,这可能有其自身的伦理含义。

如果要保护本地数据,又想享受LLM的能力,那么最好的方式是用模拟的业务数据先做一套prompt模板。对于业务询问,还是经过大模型处理返回相应的agent内容。如,在本地输入“{xx部门} {2月份}的{销售额}是多少?”,大模型生成相应的结果,类似一条SQL指令:“select … ”。这个指令回到本地,本地有一个小模型来解决执行这个输出结果的指令,而它可以利用内网访问本地的业务数据库。这样既利用LLM的能力完成了对复杂的用户询问内容的理解,也避免了本地数据进入外网的LLM。

集成能力

组织可能已经有了一定的基础设施和其他业务系统。RAG和微调的集成能力会和具体现有系统的数据库、云资源和交互界面等相关,但总体上来说,RAG更白盒,集成相对容易。

用户体验

考虑最终用户和他们的需求。如果他们需要详细的、有参考依据的答案,RAG可能更可取。如果他们重视速度和特定领域的专业知识,那么一个经过微调的模型可能更合适。

成本

微调可能会很昂贵,特别是对于非常大的模型。但在过去的几个月里,由于QLoRA等参数高效技术,成本已经显著下降。建立RAG可能是一笔巨大的初始投资——包括集成、数据库访问,甚至可能是许可费用——但是还需要考虑对外部知识库的定期维护。

复杂度

微调很快就会变得复杂。虽然现在许多提供商都提供一键微调,我们只需要提供训练数据,但跟踪模型版本并确保新模型仍然全面表现良好是一项挑战。另一方面,RAG也会很快变得复杂。需要设置多个组件,确保数据库保持新鲜,并确保各个部分(如检索和生成)正确地组合在一起。

结论

正如我们所探讨的,在RAG和微调之间进行选择需要对LLM应用程序的独特需求和优先级进行细致的评估。没有放之四海而皆准的解决方案——成功在于使优化方法与任务的具体要求保持一致。通过评估关键标准——对外部数据的需求、调整模型行为、培训数据可用性、数据动态、结果透明度等等——组织可以在最佳的前进道路上做出明智的决定。在某些情况下,同时利用RAG和微调的混合方法可能是最优的。

关键是避免假设一种方法普遍优越。像任何工具一样,它们的适用性取决于手头的工作。方法和目标的不一致会阻碍进步,而正确的方法则会加速进步。当组织评估提升LLM应用程序的选项时,它必须抵制过度简化,不要将RAG和微调视为可互换的,并选择使模型能够满足其与用例需求一致的功能的工具。这些方法打开的可能性是惊人的,但可能性本身是不够的-执行是一切。工具都在这里——现在让我们把它们付诸实践。

原文:RAG vs Finetuning — Which Is the Best Tool to Boost Your LLM Application?


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

互联网诞生以来的31种商业模式(11-20)

11. 数据也是一种商业模式

如果应用程序或算法从客户那里收集数据,以改进系统或通过为其他公司增加价值来赚钱。

译者:数据法则里面,数据维度、量级越多,价值越高。特别是一些交互类数据,包括问答、行为、LBS和行业知识等数据,完全可以成为数据公司的护城河。但是这里需要注意的是数据隐私保护和数据获取授权,且数据需要找到正确的应用场景。

案例: OpenAI的GPT3.5或4模型随着人们的使用而变得更加智能.

Data as a business model

流行的免费签到应用Foursquare允许用户在签到时分享自己的位置。后来,他们编制了庞大的数据库,帮助像星巴克这样的零售公司找到用户群来开设新店。

12. 区块链商业模式

区块链是一种分布式账本技术,允许其他公司和企业在没有像AWS、Digital ocean等中央机构的情况下部署他们的智能合约。

案例: Ethereum(以太坊)、Solana、Alchemy等

Blockchain Business Model

区块链商业模式的类型

  1. token经济或效用token商业模式是指公司发行某种token作为奖励token矿工或token持有者的机制之一。示例: Solana和以太坊。 译者:ICO的事情,还是劝各位善良吧。

  2. P2P区块链商业模式 :点对点(P2P)区块链使最终用户能够直接相互交互。

  3. 区块链即服务商业模式(Baas) :Baas是关于提供生态系统服务,如微软(Azure)和亚马逊(AWS),但在web 3空间,可以认为是一种IaaS+PaaS的结合服务。例如:比特币和以太坊,即以太坊区块链即服务(EBaaS)。

  4. 基于区块链的聚合器:针对区块链的AWS意味着你将为你最喜欢的区块链调用API,然后你可以使用该服务。示例:Alchemy是各种区块链的节点提供商

13. 免费企业服务商业模式

在免费企业商业模式中,免费的专业账户通过免费产品进入漏斗,然后转换为B2B/企业账户。

案例:Slack、Zoom、飞书、钉钉

Freeterprise business model

译者:在国内的话企业服务还是需要有一定体量的大厂来做的,和蓝湖、墨刀等专业服务不同,企业服务功能非常广,SMS只是一个组织内用户的连接基础。如果没有协作工具、文档工具、流程工具、审批工具、视频会议,以及组织和员工管理、CRM等,那很难在国内获得企业用户,而且这些功能说实话特异性不强,很难有独特性。而要提供这些,本身就不是一家中小体量的公司可以做的,就很难谈接下来的付费服务。

一些公司在免费企业服务模式中使用协作作为增长引擎

img

Loom希望您以企业帐户加入您的工作空间。

你可以从一个免费的专业账号开始,然后把整个组织都拉进去,把它变成一个企业。

译者:关于企业服务的付费,常见的做法是:

  • 用户数:比如xxx数量用户免费,超过的就需要付费;
  • 用时用量:包括目前钉钉、飞书、腾讯会议等都已经开始用时限制了,超过就需要充值续包;
  • 生态:基于生态合作的产品的收费(一般是订阅制),获取交易抽成。

14. 刀片商业模式

它被广泛应用于硬件项目,其中一个项目以低价或亏损出售,并从补充或附加组件中获得利润。

案例:Gillet razor & blades, Coffee machine & coffee beans, HP Printer & Cartage, etc.

img

刀片/诱饵和钩子的商业模式

索尼在亏损销售Playstation游戏机,但通过销售游戏和在线服务收费来弥补亏损。

剃须刀-刀片方法的好处

  1. 降低客户试用产品的风险允许客户试用产品和服务,而无需大量的前期成本。

  2. 来自产品的持续收入流潜在的销售额是初始支出的数倍。

译者:这个商业模式来源于吉列剃须刀,刀架+1-2片刀片的组合包装,都可以先送给你,然后后面再买刀片的时候赚钱。这个模式应该是很常见,就不做过多介绍了。但是这个模式需要注意场景+体验,比如剃须刀一定要用的有效。还有就是像Apple的Pencil,它的笔尖也是这种模式,那就必须保证用户是有持续使用iPad+pencil创造的欲望和能力,所以需要配套教程、让人羡慕的作品,持续激励用户使用。不然,耗材就卖不动了。

15. 直接面向消费者(D2C)的商业模式

在D2C商业模式中,品牌省去了中间商,通过第三方物流合作伙伴从其网站直接向最终消费者销售产品。

案例: GymShark, Kylie Cosmetics, etc

Direct-to-consumer (D2C) business model

译者:

D2C其实接近以前大家耳熟能详的“淘品牌”,但又不完全是。

很多品牌的努力其实是在在线卖场(天猫、京东等)之外的,他们都会在互联网上(小红书可能是一个合适的推广平台)宣扬自己的理念,圈住一批忠实粉丝,然后发展KOL(如健身达人、美妆网红等)来快速收粉。

在线卖场其实只是一个完成交易的地方,快递只是交付的方式,他们成功的秘诀还是粉丝群(或利基市场)的打造,一步步吸粉扩张。

当然,做的更极致的品牌也会考虑C2M(从客户到制造),就是他的客户群体来发表意见,品牌来制造,完成一些先共同看见,再生产交付的过程。

使用D2C商业模式的品牌只能通过网站、市场(亚马逊、eBay)等在线渠道进行扩张

Direct-to-consumer (D2C) business model

传统零售商vs D2C商业模式

使用D2C商业模式的好处

  • 没有中间商=更好的利润控制。

  • 您可以获得更有针对性的客户数据,比如客群数量统计和地理统计。

  • 更多的产品测试空间,直接听到了最终客户的心声

  • 产品范围的个性化程度更高,库存更少(译者:这点有存疑,单sku库存量可能更少,但是挤压的sku或者spu会增加

16. 自有品牌vs白标商业模式

自有标签/白标产品由合同或第三方制造商生产,并以品牌名称销售。

译者:这就是OEM(代工),也有部分ODM(设计好,给亚马逊等选品)。

亚马逊上的大多数电子产品都是在中国制造的,并且在一些品牌下打了白色标签。

案例:中国大量玩具、厨具和电子产品在亚马逊、宜家、沃尔玛等玩这种方式。

Private Label vs White Label business model

品牌用设计标签指定其产品数量,其余部分由合同制造商负责。

17. 特许经营模式

在这里,特许经营商(店主)使用特许人(公司)的商标、品牌和商业模式。

译者:其实就是加盟模式,在中国,奶茶加盟太多了,大家还是要仔细甄别,千万别被骗加盟费、技术保密押金等。

案例: Dominos, KFC, etc.

Franchise business model

这种商业模式被赛百味、达美乐、汉堡王等快餐店广泛采用。

成本 初始加盟费用 启动成本
流程 已经有标准化流程 从零开始制定流程
品牌 已有品牌辨识度 从零开始打品牌
商业模式 已经有完善的盈利模式 未知
失败风险
特许经营vs自己开开餐厅

开餐厅会增加失败的风险,因此很多人选择特许经营。

18. 基于广告的商业模式

这种商业模式被社交媒体和搜索引擎巨头使用,他们使用你的搜索引擎和兴趣数据来展示广告。

案例: Google, Meta, TikTok, and Snapchat

Ad-based business model

它将用户排除在等式之外,这样他们就不用为提供的服务或产品付费,例如谷歌用户不用为搜索付费。

作为回报,他们收集数据,然后高度个性化这些广告,以确保业务的最大收入。

译者:这就是传说中的羊毛出在猪身上。其实互联网上稳定的现金牛本身就不多,抛开贸易、制作等传统生意,购物、游戏、互联网金融应该算是最主要的现金牛,而且比O2O等高频互联网服务的利润要高。当然还有一些黑色或灰色的,比如荷官和色情等,大家千万别去碰!!!

互联网的很多广告是指向购物、游戏和互联网金融(金融目前国内管制之下已经收敛很多,都转移到电话上了),比如百度搜索,这个大家都知道有故事;比如天猫淘宝的直通车和钻展,抖音的抖+,就是更直接的投流广告了。

19. 八达通商业模式

这是一种多元化的经营策略,每个业务部门都像章鱼的触手一样独立工作,但又与主体相连。

案例: Oyo

Octopus business model

OYO是亚洲的Airbnb,在酒店、联合办公、共同生活、度假屋等方面都有业务。

译者:OYO在中国市场的状况不算好,虽然前面已经达到1万家以上门店规模,但是只提供VI和硬件标准的模式,在国内显然打不过全季等品牌,目前OYO酒店首页展示都有问题。

目前的市场在发生转变,这样的商业模式是译者不推荐的。

20. 助理型业务模式

收入是通过直接向客户销售商品或服务产生的。

广泛用于电子商务网站或您在网上购买的任何其他产品。

译者:这种模式更多聚焦在健康、零食、特殊服装和母婴等产业。

说是电商,其实更多是社群和私域的打法,或者说是私人教练和助理。比如,他们会针对一些特定人群来获取市场,如肥胖人群的穿衣指南和销售,比如帮助选择困难症用户选择和销售母婴个护等等。

案例:GymShark, Goli.

Transactional business model

助理型业务模式

我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号

TOP15——MacOS上的MySQL GUI客户端

2023年Mac上的MySQL GUI客户端TOP15

dbForge Studio for MySQL

dbForge Studio for MySQL 是一个一体化的集成开发环境,旨在简化数据库开发人员和管理员的日常工作。虽然dbForge Studio是作为经典的Windows应用程序设计的,但它目前可以通过一种名为CrossOver的特殊兼容性解决方案在macOS和Linux上使用。

dbForge Studio for MySQL

优点

  • 丰富的SQL开发功能,包括代码完成、格式化、重构和调试
  • 如果你喜欢无编码的数据库开发和管理,你有像查询生成器和数据库设计器这样的工具,使你的工作更方便的可视化图表
  • 其余的特性太长,无法在这里列出,尽管我们应该提到数据库备份、恢复、同步、迁移、正向和反向工程、用户管理以及几乎所有任务的cli自动化
  • 用户界面是如此干净和直观,即使是初学者也不会迷失在众多的功能
  • 多通道支持和大量额外的材料(包括文章和视频教程)
  • 全面的文档,包括一个详细的指南,显示如何安装dbForge Studio for MySQL在macOS上
  • 免费试用30天-足够熟悉这个IDE的巨大功能,看看它是否真的是你需要的
  • 或者,您可以使用dbForge Studio的免费Express Edition,它提供基本功能

缺点

  • 在没有安装CrossOver之前,你将无法使用dbForge Studio。但是一旦壮了CrossOver,安装和配置过程还是相当简单
  • 高级功能仅在付费版本中可用
  • dbForge Studio for MySQL只支持MySQL和MariaDB;然而,你可以分别获得类似的SQL ServerOraclePostgreSQL数据库的Studios。

下载dbForge Studio for MySQL

Download dbForge Studio for MySQL for a FREE 30-day trial

MySQL Workbench

MySQL Workbench可能是MySQL数据库开发人员、架构师和分析师的默认(如果不是最终的)GUI客户端。与macOS、Windows和Linux兼容,它包含了一个很好的数据库设计和管理工具选择,这肯定会简化您的日常工作。

MySQL Workbench

优势

  • 与之前的客户端类似,您可以获得帮助您可视化地构建查询和使用任何复杂的ER图设计数据库的工具
  • 智能代码补全
  • 高级数据建模工具
  • 所有的管理基础都牢固到位,包括用户管理,服务器配置和监控,数据库备份和恢复,以及数据迁移
  • 这是一个免费的,非常受欢迎的产品,有一个大的社区

缺点

  • UI比普通用户想要的更复杂;因此,即使是简单的任务,如数据传输过程,也可能变得相当复杂
  • 资源消耗过多

下载MySQL Workbench

SQLPro

SQLPro是一个免费的(但有几个付费选项)macOS的MySQL管理器,它可以快速访问表和视图,提供类似intellisense的自动完成,格式化和语法高亮显示,支持多个结果集和基于选择的查询执行,以及包括一个表设计器,可以轻松修改列,索引,外键和触发器。

SQLPro

优势

  • 原生应用程序
  • 美观,直观的界面
  • 易于管理多个结果集

缺点

  • 总的来说,功能是相当有限的,但是如果您不需要一个包罗万象的工具包,您可以考虑这个选项
  • 没有文档

下载SQLPro

Valentina Studio

Valentina Studio是一个多平台GUI工具,用于轻松管理MySQL, MariaDB, SQL Server, SQLite, PostgreSQL和(他们自己的)Valentina DB数据库。最需要的功能包括可视化查询构建和数据库建模、简单但有用的数据编辑器、报表设计器、源表和目标表之间的快速数据传输、模式比较和基本的数据库管理。

Valentina Studio

优势

  • 易于处理多个数据库管理系统
  • 方便的导航和快速的数据搜索
  • 强大的报表设计器与丰富的功能
  • Valentina Studio的免费版已经相当有能力了,3个付费版本在此基础上进一步改进

缺点

  • 无技术支持
  • 相当不发达的文档

下载Valentina Studio

DBeaver

现在让我们回到更熟悉的标题。DBeaver是一个支持多个数据库管理系统的多平台IDE。它功能强大,用户友好,并且它的社区版是免费的。DBeaver最流行的特性是SQL查询编辑器、可视化查询生成器、数据库比较工具、测试数据生成器和ER图。dbeaver还有更多的东西要做——它的团队帮助它积极地发展。如果您是一个要求苛刻的用户,您绝对应该探索这个选项。

DBeaver

优势

  • 多用户环境,灵活的访问管理
  • 高级数据编辑器
  • 可视化查询生成器是一个经过验证的解决方案,适合那些喜欢处理图表查询的人
  • 可定制的结果集管理
  • 灵活的比较数据库对象与不同的结果表示
  • 生成虚拟数据
  • 完整的文件

缺点

  • 免费版中没有支持服务
  • 弱数据可视化功能
  • 数据导入导出流程复杂

下载DBeaver

Querious

Querious是一个仅限MacOS的商业CUI客户端,用于MySQL和兼容数据库。在一个干净的界面下,您将找到一个具有中等强大查询功能的解决方案,以及用于数据库对象编辑、服务器管理和易于配置的数据库结构比较的精选工具。

Querious

优势

  • 原生的macOS体验确实非常不错,性能也非常稳定
  • 使您的查询变得方便的基础—例如自动补全、格式化和语法高亮—您在这里已经具备了
  • 所有类型数据库对象的编辑器
  • 丰富的数据库管理和服务器管理工具
  • 支援服务
  • 这是一个非常实惠的解决方案,免费试用30天

缺点

  • 就像上面描述的几个情况一样,这是一个中等能力的解决方案,但不是一个一体化的解决方案;好消息是,在购买之前,你有很多时间去探索它
  • 没有文档

下载Querious

TablePlus

TablePlus是一个美观的多平台GUI工具,可以帮助您处理众多数据库系统中的数据。然而,请注意TablePlus的主要杀手级功能是它的智能查询编辑器,它具有语法高亮显示、即时自动补全、SQL格式化和数据编辑功能。剩下的就取决于它是否是你关注的焦点。

TablePlus

优势

  • 干净和简单的用户界面
  • 每个平台上流畅的原生体验
  • 良好的文档
  • 如果免费版的TablePlus对你来说还不够,那么付费的许可证还是相当实惠的

缺点

  • TablePlus的功能与SQL查询和数据编辑很好地对齐,但在所有其他方面相当有限;如果您主要需要浏览、编辑和查询数据,请查看它

下载TablePlus

RazorSQL

RazorSQL是一个易于使用的SQL查询工具,已经在40多个数据库管理系统上进行了测试,包括MySQL。它的主要特性包括方便的数据库浏览器、可视化数据库工具、SQL查询构建器、SQL编辑器以及数据导入、导出和比较功能。

RazorSQL

优势

  • 列表中功能更全面的条目之一
  • 庞大的数据库系统覆盖
  • 精心设计的用户界面
  • 帮助创建、修改、描述、执行和删除数据库对象的可视化工具
  • 查询的多表格显示,具有过滤、排序、搜索和其他操作的功能
  • CLI支持
  • 详细的文件
  • 免费试用30天

缺点

  • 虽然RazorSQL提供了相当多的功能,但您必须仔细检查每个功能是否足够高级,以满足您的需求和要求。

下载RazorSQL

Navicat是一个通用的数据库开发和管理解决方案,支持大多数流行的数据库管理系统和云平台。有了它的帮助,您可以轻松地设计和管理整个数据库和特定的数据库对象、迁移数据、比较和同步数据库、构建查询以及执行逆向工程。

Navicat

优势

  • 设计良好的GUI
  • 方便的数据库对象设计器
  • 优秀的SQL编辑器
  • 可视化数据库设计和建模
  • 强大的数据库比较功能
  • 方便的任务自动化功能(仅可与dbForge Studio for MySQL相比)

缺点

  • 这是一个相当昂贵的解决方案
  • 14天的试用期对于IDE来说相当短
  • 文档需要一些扩展

下载Navicat

DataGrip

DataGrip是一个智能的基于订阅的IDE,用于许多数据库任务。它为数据库开发人员、管理员和分析人员提供了大量集成工具,帮助您处理查询并提供灵活的数据库对象管理。

DataGrip

优势

  • 广泛支持的数据库管理系统
  • 智能建议和重构
  • 版本控制集成
  • 高效导航
  • 集成数据连接器
  • 广泛的文档与教程
  • 免费试用30天

缺点

  • 复杂的学习曲线
  • 资源占用过多

下载DataGrip

Beekeeper Studio

现在让我们继续一些更直接,但有趣的事情。Beekeeper Studio是一个免费开源的基于gui的数据库管理器和SQL代码编辑器,适用于MySQL、PostgreSQL、SQLite和SQL Server数据库。该工作室的创建者专注于使其尽可能用户友好和简单。如果您的主要工作涉及查询,并且不会超出查询范围,则可以查看它。

Beekeeper Studio

优势

  • 简单的用户界面
  • 良好的SQL编辑器功能,包括自动补全和语法高亮显示
  • 可查询的查询历史
  • SSL连接加密

缺点

  • 有限的功能(不是一个缺点,因为它是一个编辑器,而不是高级用户的IDE,你应该这样对待它)
  • 无支持服务
  • 没有文档

下载Beekeeper Studio

DbVisualizer

DbVisualizer是一款智能且重点突出的SQL编辑器和数据库管理器,作为在G2上拥有最高客户满意度评级的数据库客户端进行营销。它确实是一个非常有用的解决方案,使您能够使用SQL代码,访问和探索数据库以及操作数据。DbVisualizer有免费版和专业版,后者是用许可密钥激活的。

DbVisualizer

优势

  • 美观的用户界面
  • 庞大的数据库系统覆盖
  • 高级SQL编辑器,自动格式化和建议
  • 注重安全(支持SSH数据加密和安全访问)
  • 良好的定制
  • CLI支持

缺点

  • 有时很难跟随潮流或找到正确的选择,这使得它不是初学者的最佳解决方案
  • 有时会很慢
  • 对于它提供的功能集来说,它也有点贵

下载DbVisualizer

Azure Data Studio

我们榜单上最后一个真正的大牌是微软的Azure Data Studio。它是一个跨平台工具,适用于在Windows、macOS和Linux上使用本地和云数据平台的数据专业人员。虽然SQL Server是Azure Data Studio的关键DBMS,你也可以使用一个特殊的扩展连接到MySQL数据库。Studio提供了一个现代的编辑器体验,包括IntelliSense补全、代码片段、源代码控制集成、集成终端、内置查询结果集图表和可定制的仪表板。

Azure Data Studio

优势

  • 干净和直观的界面,从微软Visual Studio的提示
  • 相当强大的一套功能的免费产品
  • 与Azure数据服务无缝集成
  • 有扩展,给访问新的功能和额外的服务
  • 优秀的文档、支持服务和大型社区

缺点

  • 虽然Azure Data Studio是一款高级产品,但也有一些ide可以更深入地实现可视化数据库设计和查询构建、表设计、服务器管理和数据库管理

下载Azure Data Studio

DbGate

最后,让我们来概述一下DbGate——一个免费的、跨平台的、跨数据库的GUI客户端,涵盖基于sql和NoSQL的系统。它允许连接到多个数据库,浏览和编辑表模式和实际数据,编写带有自动完成功能的SQL查询,可视化地构建查询,以及基于数据创建ER图表、图表和地图。把它当作一个没有野心的数据库管理器,以满足macOS用户的基本需求。

DbGate

优势

  • 一个很好的一组功能的免费工具
  • 支持多种数据库(包括NoSQL)
  • 可用的导入/导出格式可以扩展自定义插件

缺点

  • 没有一个可用的功能可以与这个列表中更高级的条目竞争,但我们猜这是不言而喻的;然而,这可能正是你正在寻找的

下载DbGate

总结

还不确定哪个客户最适合你?没关系。至少现在你可以更精确地勾勒出你的需求和要求,并记下可以决定你最终选择的优点和缺点指标。无论您是MySQL新手还是经验丰富的专家,让我们重申全面的文档、活跃的社区、可靠的技术支持以及可用的额外材料的重要性,这些都将教会您如何最有效地处理基本任务。


原文:15 Best MySQL GUI Clients for macOS


我们的创业项目已经上线!!!

TorchV AI,帮助企业快速进入AI时代!

具体详情,请点击官网咨询


最新内容,关注“土猛的员外”公众号