2004年，为了反抗谷歌对地理信息的垄断，一名黑客Serge Wroclawski设计了Open Street Map。2012年前后，Open Street Map的注册用户超过五百万，成为除中国外其他地区主流地图工具。 作为完全开源的地理信息数据库，Open Street Map在地图内容方面保持着绝对的中立和透明，任何用户都可以向它贡献内容，每天有成千上万的人给这个项目添加数据，许多人称它是全球范围内最精确与完善的地图。 另一方面，Open Street Map的后台数据也支持一切商业和非商业行为下载，任何人都可以通过数据库创建地图并渲染成不同样子，诸如Instagram、Facebook、特斯拉导航系统的地理数据均来自Open Street Map。2017年，《Pokémon GO》内的地图资料也由原本的Google map换成了Open Street Map。 《Pokémon GO》地图与Open Street Map对比 但最近，一向精准的Open Street Map出现了一些问题。 4月27日，Open Street Map社区论坛里一位用户发帖表示，最近地图上一些本不该存在海滩的地方出现了大量海滩，这些假海滩有的出现河边，有的出现在水坝。许多回帖用户表示自己也遇到了相同的情况，甚至还有人在自家后院画了几米见方的池塘，然后标记为“海滩”。 随着交流深入，大家很快发现了假海滩“大量发生”的原因：4月22日，《Pokémon GO》进行版本更新，添加了一只全新宝可梦“海地鼠”。 海地鼠是出自《宝可梦朱/紫》的第九世代宝可梦，设定上只在海岸线附近的沙滩栖息，这次登陆《Pokémon GO》也依照这一设定，仅出现在现实世界的沿海地区。 对于内陆玩家来说，这样的设计让他们感到苦闷，想捕获一只海地鼠还要先去一趟海边城市，显然不是每个玩家都有时间和金钱负担这种玩法。 在以前游戏使用Google map做地图源的时代，有些玩家会使用“开飞机”（伪造GPS）的方式去其他地区捕捉自己家附近没有的生物，但很容易被官方封号。随着地图源切换为Open Street Map，大家似乎发现了更加安全高效的玩法：直接编辑现实中的地图数据。 在“海地鼠”更新后，Reddit上的Pokémon Go板块中，很快便出现了教玩家在Open Street Map上建立“海滩”映射的帖子。 尽管大多数玩家只是抱着“捉到一只海地鼠就好”的朴素想法，甚至面对不慎闯入帖子的路人，还会恳求他们暂时不要举报自己标记的虚假海滩，但玩家们的做法还是让Open Street Map的用户感到不满。 一些在地图上乱画的玩家更是让他们感到愤怒 在他们看来，Open Street Map不是《Pokémon GO》玩家的玩具，每天有成千上万真实的人要使用它的数据，包括导航、商业活动、灾难响应等等，游戏玩家仅凭个人兴趣便随意在地图上添加虚假信息，显然既不负责任也不道德，还会给维护地图的志愿者带来极大麻烦。 在尽力修复虚假标记的时候，Open Street Map用户和《Pokémon GO》玩家不可避免地产生了争吵。比如德国巴伐利亚州的一个小区内，一名玩家在空地处标记了“海滩”，但很快另一位用户就删除了他的标记，并且警告他“别添加这些无聊的玩意了”。 而一些被激怒的用户为了反制《Pokémon GO》玩家，甚至将地图上的大量公园、球场等公共设施改成了“学校”，原因只是“据说学校附近会抑制宝可梦活动和生蛋”，无异于“伤敌八百，自损一千”。 这种行为也让Open Street Map的环境变得更加混沌，就连还在维护地图数据的志愿者也分不清眼前账号是敌是友，最后只能采取封号处理。这些天，Open Street Map社区里列出了一张又一张封号名单。 事情发展至今，Open Street Map社区新增了一张名为“《Pokémon GO》地图绘制者提示”的页面，页面提醒玩家“本地图供行人、残疾人、自行车、徒步旅行者、船夫、司机以及其他人群使用，请只绘制地面上存在的东西，不要添加虚构设施”，言语稍显无奈。 只是对于那些热衷修改地图数据的玩家来说，他们又何尝不知道这些规则，但从“坐飞机”到该地图，这个世界上永远不会缺少愿意作弊的玩家。但真正的宝可梦训练师称号，终究只属于那些愿意按照规则来玩游戏的人。

本文永久链接 – 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 [...]

当谈到 Go中结构体值时，人们纠结：通过指针传递这些值还是只是复制值？ 由于指针会带来一些开销，因此人们自然的反应是不惜一切代价避免使用它们，并尽可能传递结构值复制副本。 而我通常选择使用指针结构的两个原因是标识性和一致性。 对于我的项目，我宁愿使用 语义： 我会查看结构类型应该表示什么，并预先决定是否要为其使用指针或值复制语义。 一旦我做出决定，这个决定几乎总是在项目期间持续存在。  为了在指针和值复制语义之间划清界限，我选择的标准部分受到领域驱动设计 (DDD) 的启发，部分受到Ardan Labs 这篇文章的启发。这一切都与类型的标识身份有关。标识身份IdentityDDD 将实体与值对

关注点分离、松散耦合系统和依赖倒置原则等都是软件工程中众所周知的概念，并且在创建良好的计算机程序的过程中非常重要。在本文中，我们将讨论一种完全应用这三个原则的技术，称为依赖注入。Wire是 Go 中用于依赖注入的代码生成器。Wire 会为我们生成必要的初始化代码。我们只需要定义提供者和注入者。提供者是普通的 Go 函数，根据给定的依赖关系提供值，而注入器是按依赖顺序调用提供者的函数。案例：考虑一下，我们正在开发为用户注册提供端点的 HTTP 服务器。尽管只有一个端点，但它设计为三层，通常出现在更复杂的应用程序中：存储库、用例和控制器。假设有以下目录结构，.├── go.modgo.mod├──

当我们需要管理 有多少goroutine可以同时访问资源，使用信号量是一种可靠的方法。可以使用缓冲通道创建一个信号量，其中通道的大小决定了可以同时运行多少个goroutine： 一个goroutine发送一个值到通道中，占用一个槽。  在完成任务后，它会删除该值，从而为另一个goroutine释放该插槽。 信号量 代码：// nonbinary/counting semaphores// 用于有多个读者和一个写者的读者-写者锁。type Semaphore struct {    sem     chan struct{ id int }    timeout time.Duration //

一般和rust有关的性能对比都是当爽文看的，一开始可能没比过某某gc语言，只要找准方法最终还是可以可以比赢性能的（虽然实现上可能会稍显复杂）。 今天在公众号上看到这篇文章：Rust 解码 Protobuf 数据比 Go 慢五倍？记一次性能调优之旅 具体技术细节没上手过不是很懂，但看作者优化了很久很辛苦还上了unsafe，还是没有打赢go。

TL;DR: I’d like Postgres community input on a decision: Should we build PGXN v2 services and tools in Go or Rust? Context for the question and some weighing of options constitutes the rest of this post, but to skip to the end, 🗳️ Vote your choice! Poll closes April 12 at the end of the day (midnight) New York time. The PGXN v2 project now under way requires developing or updating several services and tools, including: A root registry for source distribution A package registry for binary distribution A command line client for developing, building, and distributing extension packages An interactions service for notifications and stats aggregation And more. Historically, the PGXN tools were written in Perl, which was an ideal choice for me back in 2011, and quite familiar to many members of the core team, but also deeply foreign to most everyone else. Furthermore, its dynamic nature and need for dozens of dependencies in most apps makes installation and packaging a challenge, to say the least.1 In the last ten years I’ve become quite proficient in Go. I appreciate its near system-level performance, memory safety, robust standard library, concurrency design, and short learning curve — especially for web services. But perhaps most eye-opening to me, as a long-time user of dynamic languages, is that, like C, Go compiles an application into a single static binary. Not only that, but Go provides cross compilation natively. This makes distribution incredibly simple. Distribution Digression Compare, for example, the Dockerfile for Sqitch, the database change management system I wrote and maintain in Perl. It’s…a lot. Sure there are a ton of system dependencies, but what’s invisible in this file is the weeks of work that went into Module::Build::Sqitch, which performs a bunch of tricks to build the Sqitch “app” as a single directory with all of its Perl dependencie[...]

Go官方博客:More powerful Go execution traces by Michael Knyszek.

原文： High-Speed Packet Processing in Go: From net.Dial to AF_XDP by Andree Toonk.

最小规则引擎，使用 yaml 作为输入，其目的是允许非程序员编辑和提供将生成特定输出的业务规则。它使用 yaml 因为有固定的语法，人们可以在线参考（不是脚本语言）。它仍然有很多冗长的内容，以方便开发可以读取和编辑它们的 GUI/客户端。这样它们也很容易存储/转移。检查example_test.go中的示例简短描述 也可被视为 "条件输出 "引擎，因为规则接收输入（map[string]any），并在规则满足时生成输出。输出与输入不同。 规则被组合成一组，因此将输入传递给一组规则后，将返回输入所传递的所有规则的组合输出。 每条规则可以有多个条件。如果满足了这些条件，就会附加/写入规则的输出。