Tag: text

在 PostgreSQL 裡，當 UUID 當作 Primary Key 時要怎麼處理

繼續清 tab，在「PostgreSQL and UUID as Primary Key (maciejwalkowiak.com)」這邊看到的，原文是討論 PostgreSQL 要怎麼處理 PK 是 UUID 的情況：「PostgreSQL and UUID as primary key」。

文章開頭作者就說了，這篇不是要戰 PK 要不要用 UUID，而是已經決定要用了 (i.e. 通常不是你決定的)，在接手以後要怎麼用比較好：

Considering the size of UUID it is questionable if it is a right choice, but often it is not up to us to decide.

This article does not focus on "if UUID is the right format for a key", but how to use UUID as a primary key with PostgreSQL efficiently.

首先是 PostgreSQL 從 8.3 版 (2008 年) 就支援 UUID 的資料型態了，這點從 release note 可以看到：「PostgreSQL 8.3.0」，所以要當 PK 的話沒什麼道理不考慮他。

用 UUID 的空間上就是 128-bit data (16 bytes)，相比於 TEXT 會省蠻多的，尤其 PK 常常會被其他表格 reference 到 (像是 foreign key) 會在其他表格也省下來：

Table that uses text is 54% larger and the index size 85% larger.

第二點則是考慮到 UUID 本身的特性，以前的 UUID 因為是亂數生成的 (通常會用 UUIDv4)，對寫入 B-tree 類的資料結構不是很有效率，改用 UUIDv7 (差不多是這兩年陸陸續續發展出來的規格) 會得益於與 timestamp 有關，對 B-tree 寫入的效率會好很多：

Random UUIDs are not a good fit for a B-tree indexes - and B-tree index is the only available index type for a primary key.

B-tree indexes work the best with ordered values - like auto-incremented or time sorted columns.

UUID - even though always looks similar - comes in multiple variants. Java's UUID.randomUUID() - returns UUID v4 - which is a pseudo-random value. For us the more interesting one is UUID v7 - which produces time-sorted values. It means that each time new UUID v7 is generated, a greater value it has. And that makes it a good fit for B-Tree index.

作者的測試可以看到寫入速度與 UUIDv4 相比比快不少：

BUT we can clearly see, that inserting UUID v7 is ~2x faster and inserting regular UUID v4.

總結來說，當 PK 已經決定是 UUID 後，主要就是這兩個重點可以注意的，當然 Hacker News 上更熱鬧的是兩派人馬在吵要用 integer 類的 SERIAL/BIGSERIAL 還是用 UUID，那又是另外一個話題了...

如果早個二十年前對 memory size 斤斤計較的情況下，答案鐵定是 integer 類的，但年代不同了...？

把文字檔壓成 PNG 跟 Gzip 比較壓縮率

Hacker News 上看到「Compressing Text into Images (shkspr.mobi)」這個奇怪的方法，是把文字轉成灰階的 PNG 檔案，然後跟 ZIP 比較壓縮率，居然是能打的。原文則是在「Compressing Text into Images」這邊。

這是屬於週末奇怪的 side project，作者也覺得這樣很白爛 XDDD

(This is, I think, a silly idea. But sometimes the silliest things lead to unexpected results.)

作者是拿羅密歐與茱麗葉的小說當資料 (Romeo and Juliet)，這可以在 Project Gutenberg 的網站上下載到 txt 檔案。

基本的想法是把每個文字轉成灰階圖片的像素，然後用 PNG 無損輸出，最後再用 Squoosh 處理：

The English language and its punctuation are not very complicated, so the play only contains 77 unique symbols. The ASCII value of each character spans from 0 - 127. So let's create a greyscale image which each pixel has the same greyness as the ASCII value of the character.

結果居然是跟一般的壓縮軟體差不多：

That's down to 55KB! About 40% of the size of the original file. It is slightly smaller than ZIP, and about 9 bytes larger than Brotli compression.

我試著驗證作者的想法，用 Go 寫了個小程式輸出操作圖片，產稱一張寬度是小說的 byte 數，高度只有 1 的 PNG 檔輸出，最後再用 pngcrush 處理：「gslin/text-to-image-compression」。

另外我是與 gzip 比較 (原作者是與 ZIP 比較)，結果是：

PNG: 64379
Gzip: 64563
Gzip (-9): 64331

的確是差不多的等級？

很多 MTurk 的接案者都用 LLM 在解決文字類的問題

剛剛在 Hacker News 上翻到的：「33-46% of workers on MTurk used LLMs in a text production task (arxiv.org)」，論文在「Artificial Artificial Artificial Intelligence: Crowd Workers Widely Use Large Language Models for Text Production Tasks」這邊，這個標題取的很故意... XD

Hacker News 上的標題主要是出自論文 abstract 的這段：

We reran an abstract summarization task from the literature on Amazon Mechanical Turk and, through a combination of keystroke detection and synthetic text classification, estimate that 33-46% of crowd workers used LLMs when completing the task.

想想還蠻正常的？能輕鬆賺當然就輕鬆賺... 但這也代表開發者可以思考 offload 給 LLM 的品質，以及如果需要外部的工人智慧，是不是可以搭配 LLM 再 offload 一些簡單的處理給人類就好？

話說好久沒聽到 MTurk 這個服務了，翻了 wiki 看起來是 2005 年就有的服務。

用 Automerge 處理 CRDT 問題

上個月看到 Automerge 出了 2.0 版的消息：「Automerge 2.0」，Automerge 這個套件可以幫你處理複雜的 CRDT 結構 (Conflict-free replicated data type)。

可以看到 Automerge 在 2.0 之後的效能改善不少，可以跟 yjs 比較了：

所以練了一下手測界面怎麼用，另外也看一下 conflict 時的處理方式。

這邊先產生 hello, world.，然後做了三個操作，第一個是把開頭的 h 改成 H；第二個是把 world 改成 test；第三個是把 world 改成 example：

(() => {
  const Automerge = require('@automerge/automerge');

  let doc1 = Automerge.init();

  doc1 = Automerge.change(doc1, 'Init', doc => {
    doc.text = new Automerge.Text();
    doc.text.insertAt(0, 'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd', '.');
  });
  
  let doc2 = Automerge.clone(doc1);
  let doc3 = Automerge.clone(doc1);

  doc1 = Automerge.change(doc1, 'Capitalize', doc => {
    doc.text.deleteAt(0);
    doc.text.insertAt(0, 'H');
  });
  doc2 = Automerge.change(doc2, 'world => test', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'test');
  });
  doc3 = Automerge.change(doc3, 'world => example', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'example');
  });

  let finalDoc = Automerge.merge(doc1, doc2);
  finalDoc = Automerge.merge(finalDoc, doc3);
  console.log(finalDoc);
})();

這樣最後會產生出 Hello, testexample.：

{
  text: Text {
    elems: [
      'H', 'e', 'l', 'l', 'o',
      ',', ' ', 't', 'e', 's',
      't', 'e', 'x', 'a', 'm',
      'p', 'l', 'e', '.'
    ]
  }
}

這結果看起來還行。

只能說以前要是有這些 library 就好了，當初在 KKBOX 做雲端歌單自己搞半天...

用 AI 模型判斷是否為 AI 產生的文字

OpenAI 放出了新的 model，可以用來判斷是否為 AI 產生的文字：「New AI classifier for indicating AI-written text」。

但目前的成效其實還是不太行，只以英文的成效來看，true positive 只有 26%，而 false positive 是 9%：

In our evaluations on a “challenge set” of English texts, our classifier correctly identifies 26% of AI-written text (true positives) as “likely AI-written,” while incorrectly labeling human-written text as AI-written 9% of the time (false positives).

另外也有提到弱點，像是比較短的內容機很難辨認：

The classifier is very unreliable on short texts (below 1,000 characters). Even longer texts are sometimes incorrectly labeled by the classifier.

然後就是有正確答案的內容也很難辨認，因為正確答案幾乎都是一樣的：

Text that is very predictable cannot be reliably identified. For example, it is impossible to predict whether a list of the first 1,000 prime numbers was written by AI or humans, because the correct answer is always the same.

另外題到了技術上的限制，現在的方法比較像是「辨認是不是從某些 corpus 訓練出來的 model，所產生的文字」，而非通用性的 AI 文字偵測：

Classifiers based on neural networks are known to be poorly calibrated outside of their training data. For inputs that are very different from text in our training set, the classifier is sometimes extremely confident in a wrong prediction.

看起來是還不到可以用的程度...

可以自己調整的黑白照片上色服務

在 Hacker News Daily 上看到 Palette 這個服務，作者在 Hacker News 上有提到你可以提供一些句子調整顏色：「Show HN: I made a new AI colorizer (palette.fm)」。

Hi HN, I’m Emil, the maker behind Palette. I’ve been tinkering with AI and colorization for about five years. This is my latest colorization model. It’s a text-based AI colorizer, so you can edit the colorizations with natural language. To make it easier to use, I also automatically create captions and generate filters.

作者有把一些作品貼在 Reddit 上面，可以參考 https://www.reddit.com/user/emilwallner/?sort=top 這邊，看起來已經有一陣子了...

用 GPT-3 產生 Hacker News 上熱門文章的摘要

看到「Autosummarized HN」這個工具，算是一個組合技的應用：

All summaries have been generated automatically by GPT-3. No responsibility is claimed for their contents nor its accuracy.

透過 GPT-3 解讀並產生出摘要，目前頁面上是沒有 RSS feed，但可以透過一些工具直接拉出來 (像是 PolitePol)，然後就可以掛到 Slack 或是 RSS reader 裡面...

玩玩文字轉圖片的 min(DALL·E)

幾個禮拜前看到「Show HN: I stripped DALL·E Mini to its bare essentials and converted it to Torch (github.com/kuprel)」這個東西，有訓練好的 model 可以直接玩文字轉圖片，GitHub 專案在「min(DALL·E) is a fast, minimal port of DALL·E Mini to PyTorch」這邊可以取得。

因為這是包裝過的版本，裝起來 & 跑起來都很簡單，但沒想到桌機的 1080 Ti 還是跑不動，只能用 CPU 硬扛了，速度上當然是比官網上面列出來用 GPU 的那些慢很多，但至少能跑起來玩看看。

首先是拿官方的句子來玩看看，第一次跑會需要下載 model (會放到我們指定的 pretrained 目錄下)：

#!/usr/bin/env python3

from min_dalle import MinDalle
import torch

model = MinDalle(
    models_root='./pretrained',
    dtype=torch.float32,
    device='cpu',
    is_mega=True,
    is_reusable=False,
)

images = model.generate_image(
    text='Nuclear explosion broccoli',
    seed=-1,
    grid_size=2,
    is_seamless=False,
    temperature=1,
    top_k=256,
    supercondition_factor=32,
    is_verbose=False,
)

images = images.save('test.png')

我自己在下載過後，跑每個生成大概都需要十分鐘左右 (參數就像上面列的，CPU 是 AMD 的 5800X，定頻跑在 4.5GHz)，出來的結果是這樣：

接著是一些比較普通的描述，這是 sleeping fat cats：

然後來測試看看一些比較偏門的詞，像是 Lolicon，這個就差蠻多了：

但感覺有蠻多應用可以掛上去，這樣有點想買張 3090 了...

各種特殊符號的英文

在 Hacker News 首頁上看到「Pronunciation guide for UNIX」這個列表，裡面有各種特殊符號的英文。

裡面列的真的比較簡易，舉例來說，像是他對 - 的說明是：

但如果你查 Hyphen (連字號) 與 Dash (連接號) 的定義，都會指出者兩個東西是不一樣的東西：

The hyphen is sometimes confused with dashes (figure dash ‒, en dash –, em dash —, horizontal bar ―), which are longer and have different uses, or with the minus sign −, which is also longer and more vertically centred in some typefaces.

The dash is a punctuation mark consisting of a long horizontal line. It is similar in appearance to the hyphen but is longer and sometimes higher from the baseline.

裡面的說明用在口語上表達應該還行，但如果是真的在寫比較正式的資料的時候還是要去其他地方確認...

I have no capslock and I must scream

前幾天看到「I have no capslock and I must scream (marginalia.nu)」這個討論，原文的標題是致敬於「I Have No Mouth, and I Must Scream」這篇小說，所以就決定把原標題留起來好了...

原文在「I have no capslock and I must scream」這邊，在原文的後面提到了 Mozilla 的這張 ticket，應該就是寫這篇文章的「主因」了：「Replace the Text Encoding menu with a single override item Repair Text Encoding」。

這種行為也是為什麼即使 Chrome 愈來愈爛，也不打算跳去 Firefox 的原因...