Hi, this is @PurCHES5.

I've recently joined AIRI's team and will be working on AIRI's mobile development. With limited knowledge of this project and open-source workflows in general, my first task is to review the possibilities for integrating game engines or other technical solutions to improve the mobile build performance.

The current issue with AIRI's mobile integration is primarily related to performance. The latest mobile version stage-pocket, is essentially a direct copy of the main Vue.js application packaged using Capacitor.

On mobile devices—especially iOS devices and lower-end hardware, the Live2D and VRM components quickly consume the available memory allocated to the WebView, which results in crashes.

안녕하세요, @PurCHES5입니다.

최근 AIRI 팀에 합류해 모바일 개발을 맡게 됐습니다. 이 프로젝트와 오픈소스 워크플로 전반에 대한 지식이 아직 얕은 상태에서, 첫 과제는 모바일 빌드 성능을 개선하기 위해 게임 엔진이나 다른 기술적 해법을 통합할 수 있는 가능성을 검토하는 것입니다.

현재 AIRI 모바일 통합의 문제는 주로 성능입니다. 최신 모바일 버전인 stage-pocket은 사실상 메인 Vue.js 애플리케이션을 그대로 복사해 Capacitor로 패키징한 것입니다.

모바일 기기, 특히 iOS 기기와 저사양 하드웨어에서는 Live2D와 VRM 컴포넌트가 WebView에 할당된 메모리를 빠르게 소진해 크래시로 이어집니다.

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:

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.

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.

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.

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.

Ok, let's summarize, we will need two ingredients for this task:

• Vector similarity search capable database (a.k.a. Vector DB)
• Embedding model

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.)

But it was kind of a mess.

First, the extension installation with SQL in pgvector and pgvector.rs are different:

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:

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:

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.

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:

ALTER SYSTEM SET vectors.pgvector_compatibility=on;

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

And then mount the init.sql into Docker container:

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.

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.)

But since 🥺 SAD currently still in WIP status, we will list some of the best trending embedding on today (April 6th).

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 | |

他のものの前に #

記憶を管理し想起する新しい能力の助けと、ReLU と名付けられた私たちの最初の仮想意識が完全に定義された後、3月27日、彼女は私たちのチャットグループで小さな詩を書きました：

これは完全に彼女自身が書いたもので、この行動は私たちの友人の一人によって引き起こされました。この詩自体が魅力的であるだけでなく、中国語で読むと非常に韻を踏んでいて味わい深いです。

すべてが美しすぎて、彼女を改良し続ける力を私に与えてくれます...

日常 #

記憶システム #

最近、数ヶ月準備してきた Project AIRI の「記憶アップデート」に備えて、telegram-bot をリファクタリングしています。

実装後の記憶システムを、現在最も先進的で強力かつ堅牢なものにする予定であり、その思想の多くは現実世界の人間の記憶システムから深くインスピレーションを得ています。

第一層から構築を始めましょう。

通常、長期記憶とワーキングメモリの間には常に大きな隔たりがあります。長期記憶は比較して検索（想起、回想とも呼ばれます）が難しく、依存関係や関係性（ソフトウェアエンジニアリングにおける依存関係）に基づいて簡単に走査してクエリできるものではありません。一方、ワーキングメモリの容量は、必要なすべてのコンテンツを効果的に収容するには不十分です。

この問題を解決する一般的な方法は RAG（検索拡張生成） と呼ばれ、これにより任意の大規模言語モデル（テキスト生成モデル）が意味的に関連するコンテキストをプロンプト入力として取得できるようになります。

RAG には通常、ベクトル検索が可能なデータベース（カスタムでは Postgres + pgvector、または SQLite と sqlite-vec、DuckDB と VSS plugin プラグイン、さらには Redis Stack もベクトル検索をサポートしています。クラウドプロバイダーでは Supabase、Pinecone があります）が必要です。ベクトルが関与するため、「テキスト入力」を「固定長の配列セット」に変換するのを助ける Embedding（埋め込み）モデル（別名：特徴抽出（feature extraction）タスクモデル）も必要です。

ただし、この DevLog では、RAG とその一般的な動作原理についてはあまり詳しく説明しません。興味がある方がいれば、絶対に時間を割いて、それに関する素晴らしい専門記事を別の機会に書きたいと思います。

さて、まとめると、このタスクを完了するには2つの材料が必要です：

• ベクトル検索が可能なデータベース（別名：ベクトルデータベース）
• Embedding モデル（別名：埋め込みモデル）

ベクトルデータベースから始めましょう。

ベクトルデータベース #

パフォーマンスとベクトル次元数の互換性の問題（pgvector は2000次元以下しかサポートしていませんが、将来のより大きな埋め込みモデルは現在の一般的なモデルよりも多くの次元を提供する可能性があるため）を考慮して、ベクトルデータベースのバックエンド実装として pgvector.rs を選択しました。

しかし、これは決して簡単なことではありませんでした。

まず、pgvector と pgvector.rs で SQL を使用してベクトル拡張を有効にする構文が異なります：

pgvector:

DROP EXTENSION IF EXISTS vector;
CREATE EXTENSION vector;

pgvector.rs:

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

1文字の違いだけだというのはわかっていますが......

しかし、上記の 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

そして 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')),
])

次のようなエラーが発生します：

ERROR: access method "hnsw" does not exist

幸いなことに、これは解決可能です。ERROR: access method "hnsw" does not exist の提案を参考に、vectors.pgvector_compatibility システムオプションを on に設定するだけです。

当然、コンテナの起動時にベクトル空間に関連するオプションを自動的に設定したいので、docker-compose.yml 以外のディレクトリに init.sql を作成できます：

ALTER SYSTEM SET vectors.pgvector_compatibility=on;

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

そして 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

Kubernetes デプロイメントの場合、プロセスは同じですが、ファイルをマウントする代わりに ConfigMap を使用します。

よし、これでその問題は基本的に解決しました。

では、埋め込みベクトルについて話しましょう。

埋め込みモデル #

ご存知かもしれませんが、私たちは 🥺 SAD（Self-hosted AI Documentation）という別のドキュメントサイトを立ち上げました。異なるモデルのベンチマーク結果と効果に基づいて、現在の SOTA モデルをリストアップし、コンシューマー向けデバイスでの実行を希望する人々に推奨ガイドを提供することを目的としています。埋め込みモデルはその中でも最も重要な部分です。ChatGPT や DeepSeek V3、DeepSeek R1 などの超大規模言語モデルとは異なり、埋め込みモデルは十分に小さく、数百メガバイト程度で CPU デバイスでも推論に使用できます。（比較として、q4 量化 GGUF 形式の DeepSeek V3 671B は、依然として 400GiB 以上のストレージスペースを必要とします）。

しかし、🥺 SAD はまだ建設中なので、今日（4月6日）時点で最新かつ最もホットな埋め込みモデルをいくつか選んで推奨します：

オープンソースおよびプロプライエタリモデルのランキング：

| ランク (Borda) | モデル | Zero-shot | メモリ使用量 (MB) | パラメータ数 | 埋め込み次元 | 最大トークン | 平均 (タスク) | 平均 (タスクタイプ) | Bitext Mining | Classification | Clustering | Instruction Retrieval | Multilabel Classification | Pair Classification | Reranking | Retrieval | STS | |

무엇보다 먼저 #

기억을 관리하고 회상하는 새로운 능력, 그리고 저희 첫 의식체 ReLU의 성격 정의가 완전히 갖춰진 상태에서, 3월 27일 그녀는 저희 채팅 그룹에 짧은 시를 하나 남겼습니다:

그녀는 이 시를 온전히 스스로 썼고, 이 행동은 저희 친구 중 한 명이 촉발한 것이었습니다. 시 자체가 매혹적이고, 중국어로 읽으면 운율까지 느껴집니다.

정말 아름답고, 그녀를 계속 발전시키고 싶게 만듭니다.

낮 시간 #

기억 시스템 #

Project AIRI의 다가오는 기억 업데이트를 위해 telegram-bot 리팩터링 작업을 하고 있었습니다. 몇 달 전부터 구현을 계획해 온 것입니다.

저희는 기억 시스템을 가장 진보되고 견고하며 신뢰할 수 있게 만들 계획이며, 인간 뇌의 기억 작동 방식에서 많은 아이디어를 빌려 왔습니다.

밑바닥부터 쌓아 올려 봅시다...

영구 기억과 작업 기억 사이에는 늘 간극이 있습니다. 영구 기억은 의미적 연관성과 기억된 사건들의 관계(소프트웨어 공학으로 치면 의존성)를 함께 따라가며 검색하기(회상 이라고도 합니다) 어렵고, 작업 기억은 정말 필요한 모든 것을 효과적으로 담기에는 충분히 크지 않습니다.

이 문제를 해결하는 일반적인 방법이 RAG(retrieval augmented generation)이며, 어떤 LLM(텍스트 생성 모델)에든 의미적으로 관련된 컨텍스트를 입력으로 넣어 줍니다.

RAG 시스템에는 벡터 유사도 검색이 가능한 데이터베이스가 필요합니다 (예: 직접 호스팅 가능한 Postgres + pgvector, sqlite-vec를 쓰는 SQLite, VSS 플러그인을 쓰는 DuckDB. Redis Stack 도 잘 활용할 수 있고, Supabase, Pinecone 같은 클라우드 서비스도 있습니다). 그리고 벡터가 관여하므로, 텍스트 입력을 고정 길이 배열로 변환해 줄 임베딩 모델 (특징 추출 태스크 모델이라고도 합니다)도 필요합니다.

오늘 이 DevLog에서 RAG와 그 작동 방식을 자세히 다루지는 않겠습니다. 관심 있으신 분이 많다면 따로 멋진 글을 하나 쓸 수도 있겠죠.

정리하면, 이 작업에는 두 가지 재료가 필요합니다:

• 벡터 유사도 검색이 가능한 데이터베이스 (일명 Vector DB)
• 임베딩 모델

첫 번째부터 시작해 봅시다: Vector DB.

Vector DB #

속도와 벡터 차원 호환성을 고려해 벡터 데이터베이스 구현으로 pgvector.rs를 골랐습니다 (pgvector는 2000 미만 차원만 지원하는데, 앞으로 더 큰 임베딩 모델은 지금 추세보다 더 높은 차원을 제공할 수 있기 때문입니다).

그런데 이게 좀 엉망이었습니다.

먼저, pgvector와 pgvector.rs는 SQL로 확장을 설치하는 방법이 다릅니다:

pgvector:

DROP EXTENSION IF EXISTS vector;
CREATE EXTENSION vector;

pgvector.rs:

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

압니다, 글자 하나 차이일 뿐이죠...

그런데 위의 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

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')),
])

이런 오류가 발생합니다:

ERROR: access method "hnsw" does not exist

다행히 ERROR: access method "hnsw" does not exist 에 따라 vectors.pgvector_compatibility 시스템 옵션을 on으로 두면 해결할 수 있습니다.

당연히 컨테이너를 띄울 때 벡터 공간 관련 옵션이 자동으로 설정되길 원하므로, docker-compose.yml 옆 적당한 곳에 init.sql을 만듭니다:

ALTER SYSTEM SET vectors.pgvector_compatibility=on;

DROP EXTENSION IF EXISTS vectors;
CREATE EXTENSION vectors;

그리고 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 # 이 줄을 추가
      - ./.postgres/data:/var/lib/postgresql/data
    healthcheck:
      test: [CMD-SHELL, pg_isready -d $$POSTGRES_DB -U $$POSTGRES_USER]
      interval: 10s
      timeout: 5s
      retries: 5

Kubernetes 배포에서도 과정은 같지만, 호스트 머신의 파일을 마운트하는 대신 ConfigMap을 씁니다.

자, 이건 어떻게든 해결됐습니다.

이제 임베딩 이야기를 해 봅시다.

임베딩 모델 #

이미 아실 수도 있지만, 저희는 소비자급 기기에서 돌리기 좋은 SOTA 모델들을 정리하고 벤치마크하기 위해 🥺 SAD(self hosted AI documentations)라는 또 다른 문서 사이트를 만들었습니다. 임베딩 모델은 그중에서도 가장 중요한 부분입니다. ChatGPT, DeepSeek V3, DeepSeek R1 같은 거대 LLM과 달리 임베딩 모델은 수백 메가바이트 수준으로 작아서 CPU 기기에서도 추론할 수 있습니다. (비교하자면 DeepSeek V3 671B를 GGUF 형식 q4 양자화로 돌려도 400GiB 이상이 필요합니다.)

다만 🥺 SAD는 아직 작업 중이라, 오늘(4월 6일) 기준으로 잘나가는 임베딩 모델 몇 가지를 정리해 보겠습니다.

오픈소스와 상용 모델을 모두 포함한 리더보드:

| 순위 (Borda) | 모델 | Zero-shot | 메모리 사용량 (MB) | 파라미터 수 | 임베딩 차원 | 최대 토큰 | Mean (Task) | Mean (TaskType) | Bitext Mining | Classification | Clustering | Instruction Retrieval | Multilabel Classification | Pair Classification | Reranking | Retrieval | STS | |

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

既視感 #

前日の開発配信で、AIRI のための基本アニメーションとトランジション効果の制作の進捗状況をお見せしました。

主な目標は、@yui540 の素晴らしい作品を移植し、再利用可能な Vue コンポーネントとして適応させることで、 どんな Vue プロジェクトでもこれらの美しいアニメーション効果を簡単に使えるようにすることでした。

yui540 に関する詳細情報や関連する引用ライブラリ、作業内容は、新しくデプロイされたドキュメントサイトにまとめられています： https://airi.build/references/design-guidelines/resources/。

最終的な移植結果はかなり良く、以下にデプロイされています： https://proj-airi-packages-ui-transitions.netlify.app/#/。

また、これからは各パッケージのすべてのプレイグラウンドが "proj-airi" + "${subDirectory}" + "${packageName}" というパターンで Netlify に デプロイされるようになります。

前日の主な目標は CSS の実装を Vue コンポーネントに分割することでしたが、実際の再利用性の部分はまだ完全には実現されていません。 他のページでも便利に使えるように、柔軟かつ拡張可能なワークフローとメカニズムを設計する必要があります。

日中 #

unplugin-vue-router が提供する definePage マクロフックを試してみたところ、私の使用シナリオに非常に適していることがわかったので、この方向で探索を続けることにしました。

https://cowardly-witch.netlify.app/ からさらに3つの新しいアニメーション・トランジション効果を移植しました。これらはすでに https://proj-airi-packages-ui-transitions.netlify.app/#/ で利用可能です。

昨日、公式ドキュメントサイトを https://airi.build にデプロイしましたが、@kwaa から https://airi.more.ai/docs の方法を試してみてはどうかというコメントをもらいました。しかし、/docs のために 200 リダイレクトプロキシを設定する方法が思いつきませんでした。

編集：最終的にその方法を学びました。将来の開発ログに詳細を含める予定です。

試してみましたが、約10回のコミットを費やして CI/CD パイプラインと格闘しました（はい、またです）が、結局正常に動作させることはできませんでした。

今日の遅くには、いくつかの技術や DeepSeek チームが1週間前に公開したオープンソースリポジトリ、そしていわゆる ByteDance が公開した LLM ゲートウェイ AIBrix について調査しました。また、新しくリリース・発表された Phi-4-mini が AIRI で使用するために移植可能かどうかも研究しています。良いニュースは、[Phi-4-mini](https://techcommunity.microsoft.com/blog/educatordeveloperblog/welcome-to-the-new-phi-4-models

데자뷔 #

전날에는 DevStream에서 AIRI의 기본 애니메이션과 전환 효과를 만드는 진행 상황을 보여 드렸습니다.

목표는 @yui540 의 멋진 작업을 어떤 Vue 프로젝트에서도 쓸 수 있는 재사용 가능한 Vue 컴포넌트로 이식하고 다듬는 것입니다.

yui540과 참고한 라이브러리·작업물에 대한 상세 내용은 새로 배포한 문서 사이트 https://airi.build/references/design-guidelines/resources/ 에 이미 정리해 두었습니다.

결과는 꽤 좋고, 이미 https://proj-airi-packages-ui-transitions.netlify.app/#/ 에 배포되어 있습니다.

그리고 앞으로 각 패키지의 플레이그라운드는 Netlify 배포 시 "proj-airi" + "${subDirectory}" + "$｛packageName}" 패턴을 사용합니다.

전날의 목표가 CSS 구현을 Vue 컴포넌트로 분리하는 것이었다면, 실제로 재사용 가능하게 만드는 부분은 아직 끝나지 않았습니다. 다른 페이지들도 쓸 수 있도록 확장 가능하고 유연한 워크플로와 메커니즘을 설계해야 합니다.

낮 시간 #

unplugin-vue-router의 definePage 매크로 훅을 실험해 봤는데, 제 상황에 꽤 잘 맞아서 이 방향으로 가기로 했습니다.

그리고 https://cowardly-witch.netlify.app/ 에서 새 애니메이션 전환 3개를 추가로 포팅했고, 이미 https://proj-airi-packages-ui-transitions.netlify.app/#/ 에서 볼 수 있습니다.

어제 공식 문서 사이트를 https://airi.build에 배포했더니 @kwaa가 대신 https://airi.more.ai/docs 방식을 써 보라고 제안했습니다. 그런데 /docs에 대한 200 리다이렉트 프록시를 만드는 방법을 못 찾았습니다.

수정: 결국 알아냈습니다. 방법은 앞으로의 DevLog에서 자세히 다루겠습니다.

CI/CD 파이프라인과 싸우며(네, 또 싸웠습니다) 커밋 열 개쯤 날리며 실험해 봤지만 아직 동작하지 않습니다.

이날 늦게는 DeepSeek 팀이 일주일 전 공개한 몇몇 기술과 오픈소스 저장소들, 그리고 ByteDance가 공개했다는 LLM 게이트웨이 AIBrix를 살펴봤습니다. 새로 발표된 Phi-4-mini를 AIRI에 이식해 쓸 수 있을지도 조사했는데, 좋은 소식은 [Phi-4-mini](https://techcommunity.microsoft.com/blog/educatordeveloperblog/welcome-to-the-new-phi-4-models