Golang - Tony Bai

标签 Golang 下的文章

使用Ollama和Go基于文本嵌入模型实现文本向量化

五月 9, 2024
0 条评论

本文永久链接 – https://tonybai.com/2024/05/09/text-vectorization-using-ollama-and-go-based-on-text-embedding-models

基于RAG+大模型的应用已经成为当前AI应用领域的一个热门方向。RAG(Retrieval-Augmented Generation)将检索和生成两个步骤相结合，利用外部知识库来增强生成模型的能力(如下图来自网络)。

在RAG赋能的大模型应用中，关键的一步是将文本数据向量化后存储在向量数据库中(如上图的红框)，以实现快速的相似度搜索，从而检索与输入查询相关的文本片段，再将检索到的文本输入给生成模型生成最终结果。

本文是我学习开发大模型应用的一篇小记，探讨的是如何使用Ollama和Go语言实现文本数据的向量化处理，这是开发基于RAG的大模型应用的前提和基础。

要进行文本向量化，我们首先要了解一下文本向量化的方法以及发展。

纵观文本向量化技术的发展历程，我们可以看到从早期的词袋模型(Bag-of-Words)、主题模型(Topic Models)，到词嵌入(Word Embedding)、句嵌入(Sentence Embedding)，再到当前基于预训练的文本嵌入模型(Pretrained Text Embedding Models)，文本向量化的方法不断演进，语义表达能力也越来越强。

但传统的词袋模型忽略了词序和语义，主题模型又难以捕捉词间的细粒度关系，词嵌入模型(如Word2Vec、GloVe)虽然考虑了词的上下文，但无法很好地表征整个句子或文档的语义。近年来，随着预训练语言模型(如BERT、GPT等)的崛起，出现了一系列强大的文本嵌入模型，它们在大规模语料上进行预训练，能够生成高质量的句子/文档嵌入向量，广泛应用于各类NLP任务中。下图是抱抱脸(https://huggingface.co/)的最新文本嵌入模型的排行榜：

目前，基于大型预训练语言模型的文本嵌入已成为主流方法。这些模型在大规模无监督语料上预训练，学习到丰富的语义知识，生成的文本嵌入能较好地编码词语、短语和句子等多个层面的语义关系。Nomic AI等组织发布了多种优秀的预训练文本嵌入模型，应用效果获得了较大提升。这种基于预训练的文本嵌入模型来实现文本数据向量化的方法也缓解了Go语言生态中文本向量化的相关库相对较少的尴尬，Gopher可以在预训练文本嵌入模型的帮助下将文本向量化。接下来，我们就来看看如何基于Ollama和Go基于文本嵌入模型实现文本向量化。

考虑到实验环境资源有限，以及Ollama对Text Embedding模型的支持，这里我选择了Nomic AI开源发布的nomic-embed-text v1.5模型，虽然在抱抱脸上它的排名并不十分靠前。

在《使用Ollama和OpenWebUI在CPU上玩转Meta Llama3-8B》一文中，我已经粗略介绍过Ollama在本地运行大模型的基本步骤，如果你对Ollama的操作还不是很了解，可以先阅读一下那篇文章。

下面我们就用ollama下载nomic-embed-text:v1.5模型：

$ollama pull nomic-embed-text:v1.5
pulling manifest
pulling manifest
pulling 970aa74c0a90... 100% ▕██████████████████████████████████████████████████████████████████▏ 274 MB
pulling c71d239df917... 100% ▕██████████████████████████████████████████████████████████████████▏  11 KB
pulling ce4a164fc046... 100% ▕██████████████████████████████████████████████████████████████████▏   17 B
pulling 31df23ea7daa... 100% ▕██████████████████████████████████████████████████████████████████▏  420 B
verifying sha256 digest
writing manifest
removing any unused layers
success

算上之前的Llama3模型，目前本地已经有了两个模型：

$ollama list
NAME                       ID              SIZE      MODIFIED
llama3:latest              71a106a91016    4.7 GB    2 weeks ago
nomic-embed-text:v1.5      0a109f422b47    274 MB    3 seconds ago

不过与llama3的对话模型不同，nomic-embed-text:v1.5是用于本文嵌入的模型，我们不能使用命令行来run该模型并通过命令行与其交互：

$ollama run nomic-embed-text:v1.5
Error: embedding models do not support chat

一旦模型下载成功，我们就可以通过Ollama的HTTP API来访问该模型了，下面是通过curl将一段文本向量化的命令：

$curl http://localhost:11434/api/embeddings -d '{
  "model": "nomic-embed-text:v1.5",
  "prompt": "The sky is blue because of Rayleigh scattering"
}'
{"embedding":[-1.246808409690857,0.10344144701957703,0.6935597658157349,-0.6157534718513489,0.4244955778121948,-0.7677388191223145,1.4136837720870972,0.012530215084552765,0.007208258379250765,-0.858286440372467,1.02878999710083,0.6512939929962158,1.0005667209625244,1.4231345653533936,0.30222395062446594,-0.4343869090080261,-1.358498215675354,-1.0671193599700928,0.3035725951194763,-1.5876567363739014,-0.9811925888061523,-0.31766557693481445,-0.32180508971214294,0.5726669430732727,-1.4187577962875366,-0.23533311486244202,-0.3387795686721802,0.02435961365699768,-0.9517765641212463,0.4120883047580719,-0.4619484841823578,-0.6658303737640381,0.010240706615149975,0.7687620520591736,0.9147310853004456,-0.18446297943592072,1.6336615085601807,1.006791353225708,-0.7928107976913452,0.3333768844604492,-0.9133707880973816,-0.8000166416168213,-0.41302260756492615,0.32945334911346436,0.44106146693229675,-1.3581880331039429,-0.2830675542354584,-0.49363842606544495,0.20744864642620087,0.039297714829444885,-0.6562637686729431,-0.24374787509441376,-0.22294744849205017,-0.664574921131134,0.5489196181297302,1.0000559091567993,0.45487216114997864,0.5257866382598877,0.25838619470596313,0.8648120760917664,0.32076674699783325,1.79911208152771,-0.23030932247638702,0.27912014722824097,0.6304138898849487,-1.1762936115264893,0.2685599625110626,-0.6646256446838379,0.332780659198761,0.1742674708366394,-0.27117523550987244,-1.1485087871551514,0.07291799038648605,0.7712352275848389,...,]}

注意：如果curl请求得到的应答是类似{“error”:”error starting the external llama server: exec: \”ollama_llama_server\”: executable file not found in $PATH “}，可以尝试重启Ollama服务来解决：systemctl restart ollama。

Ollama没有提供sdk，我们就基于langchaingo的ollama包访问ollama本地加载的nomic-embed-text:v1.5模型，实现文本的向量化。下面是示例的源码：

// textembedding.go
package main

import (
        "context"
        "fmt"
        "log"

        "github.com/tmc/langchaingo/llms/ollama"
)

func main() {
        llm, err := ollama.New(ollama.WithModel("nomic-embed-text:v1.5"))
        if err != nil {
                log.Fatal(err)
        }
        ctx := context.Background()
        inputText := "The sky is blue because of Rayleigh scattering"
        result, err := llm.CreateEmbedding(ctx, []string{inputText})
        if err != nil {
                log.Fatal(err)
        }

        fmt.Printf("%#v\n", result)
        fmt.Printf("%d\n", len(result[0]))
}

更新一下依赖：

# go mod tidy
go: finding module for package github.com/tmc/langchaingo/llms/ollama
go: toolchain upgrade needed to resolve github.com/tmc/langchaingo/llms/ollama
go: github.com/tmc/langchaingo@v0.1.9 requires go >= 1.22.0; switching to go1.22.3
go: downloading go1.22.3 (linux/amd64)
go: finding module for package github.com/tmc/langchaingo/llms/ollama
go: found github.com/tmc/langchaingo/llms/ollama in github.com/tmc/langchaingo v0.1.9
go: downloading github.com/stretchr/testify v1.9.0
go: downloading github.com/pkoukk/tiktoken-go v0.1.6
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading github.com/davecgh/go-spew v1.1.1
go: downloading github.com/pmezard/go-difflib v1.0.0
go: downloading github.com/google/uuid v1.6.0
go: downloading github.com/dlclark/regexp2 v1.10.0

我本地的Go是1.21.4版本，但langchaingo需要1.22.0版本及以上，这里考虑向前兼容性，go下载了go1.22.3。

接下来运行一下上述程序：

$go run textembedding.go
[][]float32{[]float32{-1.2468084, 0.10344145, 0.69355977, -0.6157535, 0.42449558, -0.7677388, 1.4136838, 0.012530215, 0.0072082584, -0.85828644, 1.02879, 0.651294, 1.0005667, 1.4231346, 0.30222395, -0.4343869, -1.3584982, -1.0671194, 0.3035726, -1.5876567, -0.9811926, -0.31766558, -0.3218051, 0.57266694, -1.4187578, -0.23533311, -0.33877957, 0.024359614, -0.95177656, 0.4120883, -0.46194848, -0.6658304, 0.010240707, 0.76876205, 0.9147311, -0.18446298, 1.6336615, 1.0067914, -0.7928108, 0.33337688, -0.9133708, -0.80001664, -0.4130226, 0.32945335, 0.44106147, -1.358188, -0.28306755, -0.49363843, 0.20744865, 0.039297715, -0.65626377, -0.24374788, -0.22294745, -0.6645749, 0.5489196, 1.0000559, 0.45487216, 0.52578664, 0.2583862, 0.8648121, 0.32076675, 1.7991121, -0.23030932, 0.27912015, 0.6304139, -1.1762936, 0.26855996, -0.66462564, 0.33278066, 0.17426747, -0.27117524, -1.1485088, 0.07291799, 0.7712352, -1.2570909, -0.6230442, 0.02963586, -0.4936177, -0.014295651, 0.5730515, ... ,  -0.5260737, -0.44808808, 0.9352375}}
768

我们看到输入的文本成功地被向量化了，我们输出了这个向量的维度：768。

注：文本向量维度的常见的值有200、300、768、1536等。

我们看到，基于Ollama加载的预训练文本嵌入模型，我们可以在Go语言中实现高效优质的文本向量化。将文本数据映射到语义向量空间，为基于RAG的知识库应用打下坚实的基础。有了向量后，我们便可以将其存储在向量数据库中备用，在后续的文章中，我会探讨向量数据库写入与检索的实现方法。

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite
Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go未用代码消除与可执行文件瘦身

五月 5, 2024
0 条评论

本文永久链接 – https://tonybai.com/2024/05/05/dead-code-elimination-and-executable-file-slimming-in-go

在日常编写Go代码时，我们会编写很多包，也会在编写的包中引入了各种依赖包。在大型Go工程中，这些直接依赖和间接依赖的包数目可能会有几十个甚至上百个。依赖包有大有小，但通常我们不会使用到依赖包中的所有导出函数或类型方法。

这时Go初学者就会有一个疑问：这些直接依赖包和间接依赖包中的所有代码是否会进入到最终的可执行文件中呢？即便我们只是使用了某个依赖包中的一个导出函数。

这里先给出结论：不会！在这篇文章中，我们就来探索一下这个话题，了解一下其背后的支撑机制以及对Go可执行文件Size的影响。

1. 实验：哪些函数进入到最终的可执行文件中了？

我们先来做个实验，验证一下究竟哪些函数进入到最终的可执行文件中了！我们建立demo1，其目录结构和部分代码如下：

// dead-code-elimination/demo1
$tree -F .
.
├── go.mod
├── main.go
└── pkga/
    └── pkga.go

// main.go
package main

import (
    "fmt"

    "demo/pkga"
)

func main() {
    result := pkga.Foo()
    fmt.Println(result)
}

// pkga/pkga.go

package pkga

import (
    "fmt"
)

func Foo() string {
    return "Hello from Foo!"
}

func Bar() {
    fmt.Println("This is Bar.")
}

这个示例十分简单！main函数中调用了pkga包的导出函数Foo，而pkga包中除了Foo函数，还有Bar函数(但并没有被任何其他函数调用)。现在我们来编译一下这个module，然后查看一下编译出的可执行文件中都包含pkga包的哪些函数！(本文实验中使用的Go为1.22.0版本)

$go build
$go tool nm demo|grep demo

在输出的可执行文件中，居然没有查到关于pkga的任何符号信息，这可能是Go的优化在“作祟”。我们关闭掉Go编译器的优化后，再来试试：

$go build -gcflags '-l -N'
$go tool nm demo|grep demo
 108ca80 T demo/pkga.Foo

关掉内联优化后，我们看到pkga.Foo出现在最终的可执行文件demo中，但并未被调用的Bar函数并没有进入可执行文件demo中。

我们再来看一下有间接依赖的例子：

// dead-code-elimination/demo2
$tree .
.
├── go.mod
├── main.go
├── pkga
│   └── pkga.go
└── pkgb
    └── pkgb.go

// pkga/pkga.go
package pkga

import (
    "demo/pkgb"
    "fmt"
)

func Foo() string {
    pkgb.Zoo()
    return "Hello from Foo!"
}

func Bar() {
    fmt.Println("This is Bar.")
}

在这个示例中，我们在pkga.Foo函数中又调用了一个新包pkgb的Zoo函数，我们来编译一下该新示例并查看一下哪些函数进入到最终的可执行文件中：

$go build -gcflags='-l -N'
$go tool nm demo|grep demo
 1093b40 T demo/pkga.Foo
 1093aa0 T demo/pkgb.Zoo

我们看到：只有程序执行路径上能够触达（被调用）的函数才会进入到最终的可执行文件中！

在复杂的示例中，我们也可以通过带有-ldflags=’-dumpdep’的go build命令来查看这种调用依赖关系(这里以demo2为例)：

$go build -ldflags='-dumpdep' -gcflags='-l -N' > deps.txt 2>&1

$grep demo deps.txt
# demo
main.main -> demo/pkga.Foo
demo/pkga.Foo -> demo/pkgb.Zoo
demo/pkga.Foo -> go:string."Hello from Foo!"
demo/pkgb.Zoo -> math/rand.Int31n
demo/pkgb.Zoo -> demo/pkgb..stmp_0
demo/pkgb..stmp_0 -> go:string."Zoo in pkgb"

到这里，我们知道了Go通过某种机制保证了只有真正使用到的代码才会最终进入到可执行文件中，即便某些代码（比如pkga.Bar）和那些被真正使用的代码（比如pkga.Foo）在同一个包内。这同时保证了最终可执行文件大小在可控范围内。

接下来，我们就来看看Go的这种机制。

2. 未用代码消除(dead code elimination)

我们先来复习一下go build的构建过程，以下是 go build 命令的步骤概述：

读取go.mod和go.sum：如果当前目录包含go.mod文件，go build会读取该文件以确定项目的依赖项。它还会根据go.sum文件中的校验和验证依赖项的完整性。
计算包依赖图：go build 分析正在构建的包及其依赖项中的导入语句，以构建依赖图。该图表示包之间的关系，使编译器能够确定包的构建顺序。
决定要构建的包：基于构建缓存和依赖图，go build 确定需要构建的包。它检查构建缓存，以查看已编译的包是否是最新的。如果自上次构建以来某个包或其依赖项发生了更改，go build将重新构建这些包。
调用编译器（go tool compile）：对于每个需要构建的包，go build调用Go编译器（go tool compile）。编译器将Go源代码转换为特定目标平台的机器码，并生成目标文件（.o 文件）。
调用链接器（go tool link）：在编译所有必要的包之后，go build 调用 Go 链接器（go tool link）。链接器将编译器生成的目标文件合并为可执行二进制文件或包归档文件。它解析包之间的符号和引用，执行必要的重定位，并生成最终的输出。

上述的整个构建过程可以由下图表示：

在构建过程中，go build 命令还执行各种优化，例如未用代码消除和内联，以提高生成二进制文件的性能和降低二进制文件的大小。其中的未用代码消除就是保证Go生成的二进制文件大小可控的重要机制。

未用检测算法的实现位于$GOROOT/src/cmd/link/internal/ld/deadcode.go文件中。该算法通过图遍历的方式进行，具体过程如下：

从系统的入口点开始，标记所有可通过重定位到达的符号。重定位是两个符号之间的依赖关系。
通过遍历重定位关系，算法标记所有可以从入口点访问到的符号。例如，在主函数main.main中调用了pkga.Foo函数，那么main.main会有对这个函数的重定位信息。
标记完成后，算法会将所有未被标记的符号标记为不可达的未用。这些未被标记的符号表示不会被入口点或其他可达符号访问到的代码。

不过，这里有一个特殊的语法元素要注意，那就是带有方法的类型。类型的方法是否进入到最终的可执行文件中，需要考虑不同情况。在deadcode.go，用于标记可达符号的函数实现将可达类型的方法的调用方式分为三种：

直接调用
通过可到达的接口类型调用
通过反射调用：reflect.Value.Method（或 MethodByName）或 reflect.Type.Method（或 MethodByName）

第一种情况，可以直接将调用的方法被标记为可到达。第二种情况通过将所有可到达的接口类型分解为方法签名来处理。遇到的每个方法都与接口方法签名进行比较，如果匹配，则将其标记为可到达。这种方法非常保守，但简单且正确。

第三种情况通过寻找编译器标记为REFLECTMETHOD的函数来处理。函数F上的REFLECTMETHOD意味着F使用反射进行方法查找，但编译器无法在静态分析阶段确定方法名。因此所有调用reflect.Value.Method 或reflect.Type.Method的函数都是REFLECTMETHOD。调用reflect.Value.MethodByName或reflect.Type.MethodByName且参数为非常量的函数也是REFLECTMETHOD。如果我们找到了REFLECTMETHOD，就会放弃静态分析，并将所有可到达类型的导出方法标记为可达。

下面是一个来自参考资料中的示例：

// dead-code-elimination/demo3/main.go

type X struct{}
type Y struct{}

func (*X) One()   { fmt.Println("hello 1") }
func (*X) Two()   { fmt.Println("hello 2") }
func (*X) Three() { fmt.Println("hello 3") }
func (*Y) Four()  { fmt.Println("hello 4") }
func (*Y) Five()  { fmt.Println("hello 5") }

func main() {
    var name string
    fmt.Scanf("%s", &name)
    reflect.ValueOf(&X{}).MethodByName(name).Call(nil)
    var y Y
    y.Five()
}

在这个示例中，类型*X有三个方法，类型*Y有两个方法，在main函数中，我们通过反射调用X实例的方法，通过Y实例直接调用Y的方法，我们看看最终X和Y都有哪些方法进入到最后的可执行文件中了：

$go build -gcflags='-l -N'

$go tool nm ./demo|grep main
 11d59c0 D go:main.inittasks
 10d4500 T main.(*X).One
 10d4640 T main.(*X).Three
 10d45a0 T main.(*X).Two
 10d46e0 T main.(*Y).Five
 10d4780 T main.main
... ...

我们看到通过直接调用的可达类型Y只有代码中直接调用的方法Five进入到最终可执行文件中，而通过反射调用的X的所有方法都可以在最终可执行文件找到！这与前面提到的第三种情况一致。

3. 小结

本文介绍了Go语言中的未用代码消除和可执行文件瘦身机制。通过实验验证，只有在程序执行路径上被调用的函数才会进入最终的可执行文件，未被调用的函数会被消除。

本文解释了Go编译过程，包括包依赖图计算、编译和链接等步骤，并指出未用代码消除是其中的重要优化策略。具体的未用代码消除算法是通过图遍历实现的，标记可达的符号并将未被标记的符号视为未用。文章还提到了对类型方法的处理方式。

通过这种未用代码消除机制，Go语言能够控制最终可执行文件的大小，实现可执行文件瘦身。

本文涉及的源码可以在这里下载。

4. 参考资料

Getting the most out of Dead Code elimination – https://golab.io/talks/getting-the-most-out-of-dead-code-elimination
all: binaries too big and growing – https://github.com/golang/go/issues/6853
aarzilli/whydeadcode – https://github.com/aarzilli/whydeadcode

img{512x368}

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：