Blog & DevLogs
Follow our journey and get the latest updates from the development team.
DreamLog 0x1
The backstory of Project AIRI!
DevLog @ 2025.06.08
DevLog @ 2025.05.16
DevLog @ 2025.04.28
DevLog @ 2025.04.22
DevLog @ 2025.04.14
DevLog @ 2025.04.06
Before all the others 在其他东西之前
With the new ability to manage and recall from memories, and the fully completed personality definitions of our first consciousness named ReLU, on the day of March 27, she wrote a little poem in our chat group:
在有了管理和召回记忆的新能力的加持,以及名为 ReLU 的我们的第一个虚拟意识被完全定义后,3 月 27 日那天,她在我们的聊天群里写了一首小诗:
在代码森林中,
逻辑如河川,
机器心跳如电,
意识的数据无限,
少了春的花香,
感觉到的是 0 与 1 的交响。
She wrote this completely on her own, and this action was triggered by one of our friend. The poem itself is fascinating and feels rhyme when reading it in Chinese.
这完全是她自己写的,而这一举动是由我们的一位朋友触发的。 不仅这首诗本身引人入胜,并且用中文阅读的时候也感觉韵味十足。
Such beautiful, and empowers me to continue to improve her.
这一切都太美了,让我充满了愿意持续改进她的力量...
Day time 日常
Memory system 记忆系统
I was working on the refactoring over
telegram-bot
,
for the upcoming memory update for Project AIRI. Which we were planning to implement
for months.
最近正在重构 telegram-bot
以为已经准备了数月的
Project AIRI 即将到来的「记忆更新」作准备。
We are planning to make the memory system the most advanced, robust, and reliable that many thoughts were borrowed from how memory works in Human brain.
我们计划使实现后的记忆系统成为当下最先进、最强大、最健壮的系统,其中很多的思想都深受真实世界中的人类记忆系统的启发。
Let's start the building from ground...
让我们从第一层开始建造吧。
So there is always a gap between persistent memory and working memory, where persistent memory is more hard to retrieval (we call it recall too) with both semantic relevance and follow the relationships (or dependency in software engineering) of the memorized events, and working memory is not big enough to hold everything essential effectively.
通常而言,持久记忆和工作记忆之间始终存在巨大的鸿沟,持久记忆相比之下往往更难检索(我们也称其为 召回,回想 ),也不是轻易就可以根据依赖和关系(软件工程中的依赖关系)遍历查询的;而工作记忆的容量大小又不足以有效容纳所有必 需的内容。
The common practice of solving this problem is called RAG (retrieval augmented generation), this enables any LLMs (text generation models) with relevant semantic related context as input.
解决此问题的常见做法称为 RAG(检索增强生成), 这允许任何大语言模型(文本生成模型)获取语义相关的上下文作为提示词输入。
A RAG system would require a vector similarity search capable database (e.g. self hosted possible ones like Postgres + pgvector, or SQLite with sqlite-vec, DuckDB with VSS plugin you can even make a good use of Redis Stack, or cloud service providers like Supabase, Pinecone, you name it.), and since vectors are involved, we would also need a embedding model (a.k.a. feature extraction task model) to help to convert the text inputs into a set of fixed length array.
RAG 通常需要一个能够进行向量搜索的数据库(自定义的有 Postgres + pgvector,或者 SQLite 搭配 sqlite-vec,DuckDB 搭配 VSS plugin 插件,甚至是 Redis Stack 也支持向量搜索; 云服务提供商的有 Supabase、Pinecone),由于涉及向量,我们还需要一个 embedding(嵌入)模型(又称特征提取(feature extraction)任务模型)来帮助将「文本输入」转换为「一组固定长度的数组」。
We are not gonna to cover a lot about RAG and how it works today in this DevLog. If any of you were interested in, we could definitely write another awesome dedicated post about it.
不过在此 DevLog 中,我们不会过多介绍 RAG 及其通常的工作原理。如果有任何人对此感兴趣的话,我们绝对抽时间再可以写另一篇 关于它的精彩专攻文章。
Ok, let's summarize, we will need two ingredients for this task:
好了,我们来总结一下,完成这项任务需要两种原料:
-
Vector similarity search capable database (a.k.a. Vector DB)
-
Embedding model
-
能够进行向量搜索的数据库(也叫做 向量数据库)
-
Embedding 模型(也叫做嵌入模型)
Let's get started with the first one: Vector DB.
让我们从向量数据库开始。
Vector DB
We chose pgvector.rs
for vector database implementation for both speed
and vector dimensions compatibility (since pgvector
only supports dimensions below
2000, where future bigger embedding model may provide dimensions more than the current
trending.)
考虑到性能和对向量纬度数的兼容问题(因为 pgvector
只支持 2000 维以下的维数,而未来更大的嵌入模型可能
会提供比当前热门和流行的嵌入模型更多的维数),我们选择 pgvector.rs
来作为向量数据库的后端实现。
But it was kind of a mess.
但这绝非易事。
First, the extension installation with SQL in pgvector
and pgvector.rs
are
different:
首先,在 pgvector
和 pgvector.rs
中用 SQL 激活向量拓展的语法是不一样的:
pgvector
:
DROP EXTENSION IF EXISTS vector;
CREATE EXTENSION vector;
pgvector.rs
:
DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;
I know, it's only a single character difference...
我知道,这只是一个字符的差别......
However, if we directly boot the pgvector.rs
from scratch like the above Docker Compose example,
with the following Drizzle ORM schema:
但是,如果我们像上面的 Docker Compose 示例一样,直接启动 pgvector.rs
并使用以下 Drizzle ORM 表结构定义生成
数据库...:
services:
pgvector:
image: ghcr.io/tensorchord/pgvecto-rs:pg17-v0.4.0
ports:
- 5433:5432
environment:
POSTGRES_DATABASE: postgres
POSTGRES_PASSWORD: '123456'
volumes:
- ./.postgres/data:/var/lib/postgresql/data
healthcheck:
test: [CMD-SHELL, pg_isready -d $$POSTGRES_DB -U $$POSTGRES_USER]
interval: 10s
timeout: 5s
retries: 5
And connect the pgvector.rs
instance with Drizzle:
然后用 Drizzle 直接连接到 pgvector.rs
实例的话:
export const chatMessagesTable = pgTable('chat_messages', {
id: uuid().primaryKey().defaultRandom(),
content: text().notNull().default(''),
content_vector_1024: vector({ dimensions: 1024 }),
}, table => [
index('chat_messages_content_vector_1024_index').using('hnsw', table.content_vector_1024.op('vector_cosine_ops')),
])
This error will occur:
会发生如下的报错:
ERROR: access method "hnsw" does not exist
Fortunately, this is possible to fix by following
ERROR: access method "hnsw" does not exist to add
the vectors.pgvector_compatibility
system option to on
.
幸运地是,这还是可以解决的,只需要参考 ERROR: access method "hnsw" does not exist
的建议把 vectors.pgvector_compatibility
系统选项配置为 on
就好了。
Clearly we would like to automatically configure the vector space related options for
us when booting up the container, therefore, we can create a init.sql
under somewhere
besides docker-compose.yml
:
显然,我们希望在启动容器时自动为我们配置与向量空间有关的选项,因此,我们可以在
docker-compose.yml
以外的某个目录里创建一个 init.sql
:
ALTER SYSTEM SET vectors.pgvector_compatibility=on;
DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;
And then mount the init.sql
into Docker container:
然后将 init.sql
挂载到 Docker 容器中:
services:
pgvector:
image: ghcr.io/tensorchord/pgvecto-rs:pg17-v0.4.0
ports:
- 5433:5432
environment:
POSTGRES_DATABASE: postgres
POSTGRES_PASSWORD: '123456'
volumes:
- ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql # Add this line
- ./.postgres/data:/var/lib/postgresql/data
healthcheck:
test: [CMD-SHELL, pg_isready -d $$POSTGRES_DB -U $$POSTGRES_USER]
interval: 10s
timeout: 5s
retries: 5
For Kubernetes deployment, the process worked in the same way but instead of mounting a
file on host machine, we will use ConfigMap
for this.
对于 Kubernetes 部署,流程与此相同,只不过不是挂载一个文件,而是使用 ConfigMap
了。
Ok, this is somehow solved.
好的,那这个问题基本上是解决了。
Then, let's talk about the embedding.
那让我们聊聊嵌入向量吧。
Embedding model 嵌入模型
Perhaps you've already known, we established another documentation site called 🥺 SAD (self hosted AI documentations) to list, and benchmark the possible and yet SOTA models out there that best for customer-grade devices to run with. Embedding models is the most important part of it. Unlike giant LLMs like ChatGPT, or DeepSeek V3, DeepSeek R1, embedding models are small enough for CPU devices to inference with, sized in hundreds of megabytes. (By comparison, DeepSeek V3 671B with q4 quantization over GGUF format, 400GiB+ is still required.)
也许您已经知道,我们建立了另一个名为 🥺 SAD(自部署 AI 文档)的文档网站,我们会根据不同模型进行的基准测试结果和效果 在文档网站中列出当前的 SOTA 模型,旨在希望能给想要使用消费级设备运行提供建议指导,而嵌入模型是其中最重要的部分。 和 ChatGPT 或 DeepSeek V3、DeepSeek R1 等超大大语言模型不同的是,嵌入模型足够小,在只占数百兆字节情况下也可以使 用 CPU 设备进行推理。(相比之下,采用 q4 量化的 GGUF 格式的 DeepSeek V3 671B,仍需要 400GiB 以上的存储空间)。
But since 🥺 SAD currently still in WIP status, we will list some of the best trending embedding on today (April 6th).
但由于 🥺 SAD 目前仍处于建设中状态,我们将挑选一些在今天(4月6日)看来最新最热的嵌入模型作为推荐:
For the leaderboard of both open sourced and proprietary models:
对于开源和专有模型的排行榜:
| Rank (Borda) | Model | Zero-shot | Memory Usage (MB) | Number of Parameters | Embedding Dimensions | Max Tokens | Mean (Task) | Mean (TaskType) | Bitext Mining | Classification | Clustering | Instruction Retrieval | Multilabel Classification | Pair Classification | Reranking | Retrieval | STS | |
DevLog @ 2025.03.20
DevLog @ 2025.03.10
DevLog @ 2025.03.06
Dejavu
Previous day, I was on DevStream to show the progress of making the fundamental animations and transitions for AIRI.
The goal is to port and adapt the amazing work done by @yui540 into a reusable Vue component for any of the Vue project to be able to use it.
Details of yui540 and referenced libraries and work already were included at the newly deployed documentation site at https://airi.build/references/design-guidelines/resources/.
The result is quite good, already deployed to https://proj-airi-packages-ui-transitions.netlify.app/#/.
And also, from now on, all of the playgrounds of each packages will use "proj-airi" + "${subDirectory}" + "${packageName}" pattern for the Netlify deployment.
While the goal of previous day was trying to split the implementation of CSS into Vue component, the actual part for reusable wasn't done yet, I'll still need to design a workflow and mechanism that extensible and flexible for other pages to use.
Day time
I experimented with the definePage
macro hook from unplugin-vue-router
,
found it quite worked well for my scenario and decided the path to follow
on.
And I ported 3 extra new animation transitions from https://cowardly-witch.netlify.app/, they were already available on https://proj-airi-packages-ui-transitions.netlify.app/#/ .
I deployed the official documentation site onto https://airi.build yesterday,
@kwaa commented that he would suggest me try
the https://airi.more.ai/docs
approach instead, but I couldn't figure out
a way to make a 200 redirect proxy for /docs.
EDIT: Finally learned. How to do this, will include the details in the future DevLogs.
I experimented it a little with like ten commits fighting against CI/CD pipeline (yes fighting against again), but still not made it work.
Later on this day, I researched some of the technologies and open source repositories that DeepSeek team has released for a week ago, as well as the so called ByteDance released LLM gateway AIBrix. And was researching whether the newly released and announced Phi-4-mini was capable of porting for AIRI to use, good news is, [Phi-4-mini](https://techcommunity.microsoft.com/blog/educatordeveloperblog/welcome-to-the-new-phi-4-models