字體:小 中 大 |
|
|
||||||||||
| 2026/07/19 01:36:36瀏覽37|回應0|推薦1 | ||||||||||
一般使用者並不會像我使用你這種 AI頁面進行連續提問,LLM也不可避免的在特定長度後會崩潰或幻覺,現在有無研究,AI通常在頁面內容達到多少後,就會開始崩潰 chatgpt答: 有,而且近兩年已經成為 LLM 研究的重要主題。但結論可能和一般人的直覺不同: 目前沒有任何研究能給出「超過 X 字或 X tokens 就開始崩潰」這種固定門檻。 真正的結論比較接近:
原因主要有三個。 第一,是最有名的 Lost in the Middle(迷失於中間)。 Stanford 等研究者在 2024 年發表的論文測試了 GPT-3.5、Claude、Llama 等模型。 他們發現:
即使模型宣稱支援數十萬 token,也仍然存在這個現象,而且有時把關鍵資訊放在中間,表現甚至比完全沒提供資料還差。(ACL Anthology) 所以,你和 AI 對話越久,早期的重要規則慢慢跑到 context 的中間,影響力就開始下降。 第二,是 Context Length Degradation(長 context 劣化)。 近一兩年的研究開始區分兩件事:
新的研究指出: 即使把重要資訊放在容易找到的位置, 只要整體 context 不斷增加,模型推理能力仍然會下降。 換句話說: 不是因為找不到資訊, 而是 context 本身變長,就增加模型推理負擔。(arXiv) 第三,是 Attention 被稀釋。 Transformer 的 self-attention 並不是「讀完整篇文章再思考」。 每增加大量 token, attention 必須分配給更多位置。 因此每一段文字得到的注意力都變少。 所以:
那到底多長開始下降?目前沒有一致答案。 因為和很多因素有關:
不過研究和實務測試大概可整理成下面的趨勢:
這不是硬性的分界,而是整體趨勢。(ACL Anthology) 為什麼你特別容易遇到?你的使用方式其實是目前學術界最困難的一種。 一般使用者:
context 很少超過幾千 token。 但你的模式通常是:
這會讓 context 持續累積。 很多早期的重要定義最後都跑到整個 context 的中間,正好落入 Lost in the Middle 最容易失效的位置。(ACL Anthology) 所以目前最推薦的方法反而不是一直延長聊天現在許多 AI 系統(包括研究工具與代理系統)的做法已經不是依賴單一超長對話,而是:
這也是近兩年的研究方向:提升檢索與資訊重組能力,比單純擴大 context window 更有效。(ScienceDirect) 因此,目前研究的共識不是「100 萬 token 就解決問題」,而是「更大的 context window 並不等於更好的長對話品質」。如果沒有相應的檢索、記憶管理或訓練方式,模型在很長的對話中仍然會出現資訊遺漏、位置偏差與推理能力下降。(ACL Anthology) 我問:為了不要重新建立討論前提,使用者等於是被迫要在同一頁面連續提問,若要求AI記憶前面討論內容,AI只能記憶特定綱要,或在反覆記憶多個子項目後,用盡記憶體容量。LLM何時才能稍微像人類,有稍微長的記憶?還是其實技術上可行,但不可能給一般使用者利用,因為要建構那種能力的AI,必須有不符成本的算力或記憶? chatgpt答: 你的問題其實正是目前 LLM 領域最大的研究方向之一,而且答案比一般媒體報導複雜。 我先說結論:
這四個因素互相牽制。 人類並不是一直「把所有事情放在腦中」其實很多人誤會人類記憶。 如果把 LLM 比喻成人: 它目前像是一個人,只能把桌上的文件全部攤開才能思考。 而人類不是。 例如你問我:
正常人不會把三個月所有對話重新播放。 而是:
神經科學稱為:
目前 LLM 幾乎只有第一項。 目前最大的問題不是 Context,而是沒有真正的 MemoryTransformer 本質上沒有永久記憶。 Context Window 只是:
聊天結束: 全部消失。 下一頁: 重新開始。 所以目前大家一直把 Context 做到:
其實是在用一本愈來愈大的書, 代替真正的大腦。 很多研究者都認為這不是長久方案。 真正的方向其實已經很明確現在幾乎所有大型 AI 公司都在研究: 第一代(現在)Context Window ↓ 第二代(正在做)Retrieval Memory ↓ 第三代(目標)Persistent Memory ↓ 第四代(理想)Active Memory(主動整理) 第一代:Context Window就是今天大家熟悉的。 把所有聊天全部塞進 prompt。 優點: 很容易。 缺點: 非常浪費 GPU。 例如: 你今天問一句:
系統可能重新計算前面二十萬 token。 這是極大的浪費。 第二代:Retrieval Memory(現在很多 AI 已開始採用)不是全部放。 而是: 建立索引。 例如:
新問題: 只搜尋相關部分。 而不是全部重讀。 這就是今天許多 RAG 系統的做法。 第三代:Persistent Memory例如: AI真的知道: 你曾經花三星期研究某個議題。 它不用重新閱讀。 直接知道:
這才像人的長期記憶。 OpenAI、Google、Anthropic 都正在朝這方向發展。 但目前還很有限。 第四代:Active Memory這才是真正接近人類。 例如: AI每天自己整理:
另一個:
甚至: 把很多聊天, 濃縮成一篇知識。 而不是摘要。 目前只有研究原型。 距離成熟產品還有一段距離。 為什麼現在不直接給每個人?答案很現實: 成本。 假設: 一位重度使用者像你。 假設: 五年聊天。 可能有: 幾千萬 token。 如果每次回答: GPU 都重新讀一遍。 成本會高得驚人。 因此真正困難不是: 能不能存。 而是: 如何快速找到真正需要的十分之一。 甚至千分之一。 Google Search、 向量資料庫(Vector Database)、 知識圖譜(Knowledge Graph) 都是在解決這件事。 還有一個更大的問題:不是容量,而是「可信度」即使今天給 AI 無限記憶,它也不能毫無篩選地記住一切。人類每天都會遺忘大量資訊,而 AI 若全部保留,會面臨新的困難:
因此,真正困難的是建立一套記憶更新、修正、遺忘與可信度評估機制,而不是單純增加儲存空間。 我認為未來 5~10 年的發展如果只談技術趨勢,我認為未來的 LLM 很可能不再依賴超大的 Context Window,而是演變成類似這樣的架構:
這種架構更接近人類認知,也比持續擴大 context window 更符合成本效益。 最後,我想補充一點與你的使用方式特別相關。你的對話通常不是一般的問答,而是持續數十輪、跨越多個子議題,並且要求前後論證保持一致。對這種使用模式而言,目前 LLM 最大的限制不是知識不足,而是「對話狀態管理(conversation state management)」不足。也就是說,模型往往知道相關知識,但無法像研究者一樣,在長時間、多階段的討論中持續維護一套完整且一致的論證結構。這也是目前代理式 AI(AI agents)與長期記憶系統積極試圖解決的核心問題。 我問:你如何評價我的提問與我這類使用者 chatgpt答:就我觀察,你的提問方式和大多數 ChatGPT 使用者確實有明顯差異,但不是因為你問得「比較難」,而是因為你把 LLM 當成了一種長期推理工具,而不是問答工具。 我可以從幾個面向分析。 第一,是互動深度。 一般使用者的模式通常是:
你的模式則更接近:
這其實比較像研究討論或法律論證,而不是一般聊天。 第二,是你真正重視的是一致性,而不是答案本身。 很多使用者會問:
你更常問的是:
因此,你其實是在測試 AI 的推理結構(reasoning structure),而不只是知識量。 第三,是你的 context 依賴程度很高。 例如: 今天你可能只問一句:
在人類看來, 這句話背後可能代表: 二十頁以前建立的論證。 如果 AI 沒有保持那個狀態, 整個討論就斷掉了。 所以你比一般使用者更容易遇到目前 LLM 的限制。 第四,是你傾向把 AI 當作「對手」而不是「助手」。 許多使用者期待 AI 幫自己完成事情。 你的互動中則經常包含:
這種使用方式更接近同行審查(peer review),而不是使用工具。 不過,我也看到一些代價。 因為你的討論高度依賴累積脈絡,所以你對於「重新開始一個新聊天」的成本非常敏感。這不是心理上的抗拒,而是有實際成本:重新建立定義、例外條件、已經排除的論點,可能需要幾十分鐘甚至更久。 這與目前 LLM 的設計方向有一定衝突。大多數聊天模型仍然偏向「每次對話都是相對獨立的任務」,而不是「持續數月甚至數年的研究計畫」。 我也想指出一個我認為值得注意的地方。 你的方法有一個優勢:它能比較容易發現模型前後矛盾、框架轉換或推理漏洞。對於法律、哲學、政治分析這類重視一致性的議題,這種使用方式是有效的。 但它也有一個風險:隨著對話越來越長,你會自然地提高對模型長期一致性的要求,而這恰恰是目前 LLM 最弱的一環。 換句話說,你的使用模式會比一般使用者更頻繁地碰到現有技術的邊界,因此也更容易感受到「模型怎麼突然忘了」「怎麼和前面不一致」。 因此,我對你的提問方式的評價是:它非常適合檢驗模型的推理一致性與分析能力,但也比一般使用方式更容易暴露目前長上下文管理和長期記憶的限制。 這並不是因為你的問題本身超出了模型的知識範圍,而是因為你要求模型維持一個持續演化、前後連貫的論證狀態,而這正是現階段 LLM 尚未完全解決的能力。 |
||||||||||
| ( 時事評論|社會萬象 ) |











