Solving Spark error: “Cannot broadcast the table that is larger than 8GB"

2023-02-232023-02-23 Jumping發表留言

Error

Although I have already set crossJoin.enable to true and autoBroadcastJoinThreshold to -1, I still got an error.

spark = (
    SparkSession
    .builder.appName('my_spark')
    .config("spark.sql.crossJoin.enabled", "true")
    .config("spark.sql.autoBroadcastJoinThreshold", '-1')
    .getOrCreate()
)

java.util.concurrent.ExecutionException:
org.apache.spark.SparkException: Cannot broadcast the table that is larger than 8GB: 8 GB

This error is due to default PySpark broadcast size limit which is 8 GB.

Solution

There is no specific code or config we can set to solve this problem (at least I didn’t find one).

What we can do is to optimize our code.
Here are some of my ideas.

Use select(cols) or selectExpr(cols) to choose the columns we actually need before join to reduce the dataframe’s size.
Use filter(expr) to filter out what data we don’t need.
Use normal df1.join(df2) instead of using df1.join(broadcast(df2)).

I selected less columns of my dataframe (from 7 cols to 3 cols) to solve my problem.

Solving Spark error: “TaskMemoryManager: Failed to allocate a page"

2023-02-23 Jumping發表留言

Error

This error occurs endlessly during PySpark code running.

TaskMemoryManager: Failed to allocate a page.

Solution

I added one spark config in SparkSession that solved my problem.
Set autoBroadcastJoinThreshold to -1.

“spark.sql.autoBroadcastJoinThreshold": ‘-1’

Code example

spark = (
    SparkSession
    .builder.appName('my_spark')
    .config("spark.sql.autoBroadcastJoinThreshold", '-1')
    .getOrCreate()
)

Solving Spark error: “Decompression error: Version not supported" on GCP Dataproc

2023-02-232023-02-23 Jumping發表留言

My gcloud command on terminal to create cluster

sudo gcloud dataproc clusters create my-project \
    --bucket my-bucket \
    --project my-gcp-project \
    --region asia-east1 \
    --zone asia-east1-b \
    --image-version=2.0-ubuntu18 \
    --master-machine-type n1-highmem-8 \
    --master-boot-disk-size 30 \
    --worker-machine-type n1-highmem-8 \
    --worker-boot-disk-size 100 \
    --num-workers 6 \
    --metadata='PIP_PACKAGES=xxhash' \
    --optional-components=JUPYTER \
    --initialization-actions gs://goog-dataproc-initialization-actions-asia-east1/python/pip-install.sh
    --subnet=default

Error

This error occurs during specific PySpark code running.

java.io.IOException: Decompression error: Version not supported

Solution

Change image-version from 2.0-ubuntu18 to 2.1-ubuntu20 can solve this version not supported error.

--image-version=2.1-ubuntu20 \

破解 ChatGPT！實測 4 個可偵測 AI 文本的工具

2023-02-012023-02-01 Jumping發表留言

自從 ChatGPT 轟動全世界之後，很多人開始擔心會不會到處都充斥著 AI 寫的文章，於是最近很多偵測 AI 文本的工具慢慢出來了。

這次我決定實測一下這些工具，看看他們是不是真的能辨識我寫的文章和 AI 寫的文章、運算速度，以及他們是否有支援中文，同時也順便了解一下他們偵測的原理是什麼。

4 個偵測 AI 文本的工具

ZeroGPT

這應該是我最早看到可以來偵測 AI 文本的工具，我這次用我之前自己寫的英文文章來測試看看

他真的知道這是人類寫的文章，滿厲害的！
接著我拿一樣的文章但是由 ChatGPT 幫我修訂過的版本測試看看

哇！還真的直接被認定是 AI 寫的！

這個工具沒有字數的最低限制，但是給多一點字他會越準確。

可以輸入中文去測試，但是我拿自己的寫的會顯示是 AI 寫的，雖然網站上面說有支援多語言，但感覺準確度掉了很多。

ZeroGPT 連結：https://www.z erogpt.com/

DetectGPT

由史丹佛大學所開發，原理是基於 LLM (large language model) 產生的文本通常在對數機率 log-probability 上有特別的規律，所以可以藉此判斷文本是否由 AI 產生。

拿上去測試的文本必須要至少 40 字，太少的話他只會給你一行字「In order to get a meaningful result, enter at least 40 words.」

一樣拿我寫的文章來測試看看

很好，他說這段文章不太可能是 AI 產出的（Z-score < 0.25），那我一樣再拿曾經 AI 幫我修改過的版本測試

厲害！被偵測出來是 AI 寫的了！（Z-score > 1）

DetectGPT 執行的時間花費比 ZeroGPT 久一些，不到 100 字的一小段文章也需要大概 10-30 秒左右。

如果輸入的是中文，他按了就會沒反應，看來是還沒有支援多語言。

DetectGPT 連結：https://detectgpt.ericmitchell.ai/

GPTZero

由普林斯頓大學（Princeton University）的 22 歲學生所開發的（也太厲害了吧），原理是檢測文本的「困惑度」（Perplexity）和「突發性」（Burstiness）這 2 項指標，關於這部分有一篇商周文章有解釋，以下節錄並整理一些重點片段：

困惑度（Perplexity）

是指人類書寫語言的複雜性和隨機性。
主要衡量一個句子的隨機程度和構造，是否讓 GPTZero 感到困惑。

每當用戶在 GPTZero 輸入一段測試內容，它就會分別計算出：「文字總困惑度」、「所有句子的平均困惑度」、「每個句子的困惑度」。

數值越低，說明 GPTZero 對文本非常「熟悉」，那就很可能是由 AI 所生成。
數值越高，說明文本讓 GPTZero 感到「驚訝」，那麼它有更高的可能是出自人類之手。

突發性（Burstiness）

主要是比較句子複雜性的變化，衡量它們的一致性。

因為人類傾向於書寫高度複雜的文本，而AI產出的文本則是低複雜度的。

所以在選詞上「簡單」而「熟悉」，並使用「統一整齊」的句子，是 AI 生成作品的標誌特徵，複雜又多樣的則是人類寫的。這也是「困惑度」和「突發性」這 2 項指標可以作為衡量標準的原因。

接著就是來試用看看 GPTZero 啦！首先是我自己寫的

被認為是人類所寫，Bingo！

ChatGPT 修訂過的文本，也準確地被檢測出來啦！

這工具可以使用中文，但是…

…看起來準確率不高，我自己寫的文章被認定有部分是出自 AI，依照上面所說的原理，這是在嗆我用字遣詞太過簡單嗎哈哈！

另外，我發現這個工具比較特別的是還有支援檔案上傳，像是 pdf、docx 和 txt 檔，感覺很適合需要改作業的老師們，要檢查作業的話，直接把學生給的檔案上傳就好 XD

GPTZero 連結：https://gptzero.me/

AI Text Classifier

由開發 ChatGPT 的公司 OpenAI 所開發的，算是自己的產品自己破解的概念。

之前如果已經有玩過 ChatGPT，可以用同一個帳號去使用這個 AI 檢測工具，接下來就是實測時間！

首先是我自己寫的文章…

What！竟然至少要 1000 字才讓我用！好吧，那我只能放棄用我自己的文章來測試了。

OpenAI 很懂我們這些使用者，所以直接提供了範例文章給我們測試，下圖這是人類所寫的文章，檢測後顯示這篇是 AI 所寫的可能性非常低！

再試著用 AI 文章來測試，檢測結果說很有可能是由 AI 所創造的文本。

後來拿我最近寫的中文文章來試試，他竟然準確預測，認為不太可能是 AI 寫的！
果然只有 OpenAI 懂我（蛤？

看來要檢測中文文本的話，目前還是使用 OpenAI 的這個工具會比較好！

AI Text Classifier 連結：https://platform.openai.com/ai-text-classifier

綜合比較表

綜合所有的測試後，整理了一張表，大家可以依照這表來選擇符合自己需求的工具唷！

	字數限制	支援中文	支援檔案上傳	運算速度	便利性	開發者
ZeroGPT	–	有但不準	–	快	中	ZeroGPT
DetectGPT	至少 40 字	–	–	慢	中	史丹佛大學
GPTZero	–	有但不準	有	快	高	普林斯頓學生 Edward Tian
AI Text Classifier	至少 1000 字	有準確率不錯	–	快	低	OpenAI

總結

這次總共測試了四個偵測 AI 文本的工具，雖然我沒有拿很多文章來做實測，但我猜以準確率來說，應該還是以 OpenAI 自家的 AI Text Classifier 會是最好的，畢竟 ChatGPT 的強大應該大家都有目共睹，但因為它不僅要登入才能使用，還限制一定要超過 1000 字才能執行檢測，所以在便利性上扣了一點分數。

但這些都只是剛開始而已，之後 AI 還有什麼發展真的是很令人期待啊～

歡迎追蹤我的 IG 和 Facebook