Önce sınırları netleştirin
Her şeyi üç sayı belirler:
- Bağlam penceresi toplamı 100,000 token, istem ve tamamlama birlikte.
max_tokensvarsayılan olarak 2048'dir; istek başına maksimum 16.000 token'a kadar çıkabilir.- İstek gövdesi 8 MB'ı geçmemelidir; saf metin için bu sınır nadirdir, asıl sınır token sayısıdır.
Bütçe formülü basittir: kullanılabilir istem = 100000 - max_tokens. Modelin bir seferde 4000 token üretmesini isterseniz, istem için kalan maksimum 60.000 token olur. Aşıldığında uç nokta 400 hatası döndürür, otomatik olarak kesmez. Bu nedenle "tüm kitabı içine sıkıştırıp sonra bak" strateji değil, şans oyunudur.
Başka bir yaygın yanılgı: max_tokens ne kadar büyükse o kadar güvenli. O aslında ayrılmış çıktı alanıdır; 16.000 ayarlamak, prompt'un 48.000 olabileceği anlamına gelir. İhtiyaca göre ayarlayın, maksimize etmeyin.
Hesap yapma örneği olarak, özetlemeniz gereken 300.000 kelimelik bir röportaj transkripsiyonunuz olduğunu varsayalım. Kelabe başına 1.3 token ile kabaca hesapladığımızda yaklaşık 390.000 token eder; bu da sınırın altı katından fazladır ve bu yüzden bütünüyle gönderilemez. Tek seferlik bir özet için 800 token çıktı gerektiğini varsayarsak, her bir parça için maksimum 63.000 token girebilirsiniz. Gerçek hayatta bir pay bırakırsanız bu sayı 50.000'in altına düşer. Ancak bu en iyi çözüm değildir; parçalar çok büyük olduğında model orta kısımlardaki içeriğe daha az dikkat eder. Bu nedenle aşağıdaki yaklaşım parçaları daha küçük tutmaktır; birkaç kez daha fazla çağırmaktan çekinmeyin.
Token tahmini: Yaklaşık algoritma
Yerel tokenizasyon yoksa aşağıdaki değerleri tahmin için kullanın. Bunlar yaklaşık değerlerdir, kesin değildir ve metin türüne göre %10-20 sapma olabilir:
| Metin türü | Yaklaşık dönüşüm |
|---|---|
| Çince kurgu olmayan metin | Karakter başına yaklaşık 1 ile 1,5 token |
| İngilizce | Karakter başına yaklaşık 4 karakterde 1 token veya kelime başına yaklaşık 1,3 token |
| Kod, JSON, sembol ağırlıklı metin | Normal metinden daha fazla token harcar; muhafazakar yüksek değerle tahmin edin. |
Kullanılabilir bir tahmin fonksiyonu ve tamponlu bütçe hesabı aşağıdadır:
CONTEXT = 100000
def est_tokens(text: str) -> int:
"""粗估：中文按每字 1.3 token，其余字符按每 4 个字符 1 token。仅为近似。"""
zh = sum(1 for c in text if "\u4e00" <= c <= "\u9fff")
other = len(text) - zh
return int(zh * 1.3 + other / 4) + 1
def max_prompt_budget(max_tokens: int, margin: float = 0.1) -> int:
"""给定计划的 max_tokens，返回 prompt 最多能用多少 token（留 margin 余量）。"""
return int((CONTEXT - max_tokens) * (1 - margin))
# 例：计划让模型写 3000 token，prompt 预算
print(max_prompt_budget(3000)) # 54900Kalibrasyon: Tipik bir girdi ile tek istek gönderin, yanıtın usage.prompt_tokens alanını okuyun ve tahmininizle karşılaştırarak kendi verileriniz için gerçek çarpanı bulun. Tahmin sadece "parçalama gerekip gerekmediğine" karar vermek içindir; kesin hesap için usage alanına bakın.
Uzun belge özetleme: Parçalama ve birleştirme
Belge bütçeyi aşarsa standart yöntem map-reduce'tur: önce blokları özetle, sonra özetleri birleştir. Aşağıdaki detaylara dikkat edin:
- Paragraf sınırlarına göre bölün; sabit kelime sayısına göre kesme cümleleri ikiye bölebilir.
- Her blok için yeterli bütçe bırakın; sınırın üçte birini geçmeyin, talimatlar ve çıktı için yer açın.
- Parça özetlerinde isimleri, sayıları ve kritik olayları koruyun; yoksa birleştirme sırasında bilgi kaybolur.
- Özetin özet hâlâ uzunsa, bir katman daha özetleme yapın.
import os
from openai import OpenAI
client = OpenAI(base_url="https://api.wushenchaapi.com/v1", api_key=os.environ["API_KEY"])
def split_paragraphs(text, budget):
"""按段落切块，每块估算不超过 budget token。"""
chunks, cur, used = [], [], 0
for p in text.split("\n"):
t = int(len(p) * 1.3) + 1 # 中文粗估
if used + t > budget and cur:
chunks.append("\n".join(cur))
cur, used = [], 0
cur.append(p)
used += t
if cur:
chunks.append("\n".join(cur))
return chunks
def ask(prompt, max_tokens=800):
r = client.chat.completions.create(
model="uncensored",
temperature=0.3,
max_tokens=max_tokens,
messages=[{"role": "user", "content": prompt}],
)
return r.choices[0].message.content
def summarize_long(text, budget=12000):
parts = split_paragraphs(text, budget)
partial = [ask("用不超过 200 字概括下面这段，保留人名和关键事件：\n\n" + p) for p in parts]
merged = "\n".join(f"第{i+1}部分：{s}" for i, s in enumerate(partial))
return ask("下面是分段摘要，请合并成一份 400 字以内的整体摘要：\n\n" + merged, max_tokens=900)Burada temperature değeri 0,3 olarak ayarlanmıştır; özetleme görevleri için kararlılık önemlidir. Her parça için yapılan çağrılar birbirinden bağımsızdır ve eşzamanlı olarak gönderilebilir. Ancak her API anahtarı için dakikada 300 istek hız limiti olduğunu unutmayın; onlarca parçalık bir metin bu sınırı aşmaz.
Blok boyutu için standart bir cevap yoktur. Deneyime göre blok başına 10.000-15.000 token, detay koruma ve çağrı sayısı arasında denge kurar. Örnek bir belgeyi 5000, 12000 ve 25000 token blok boyutlarıyla çalıştırıp özetlerde kaybolan kritik bilgi sayısını karşılaştırarak en uygun değeri seçin. Yüksek bilgi yoğunluğu olan sözleşmeler ve teknik dokümanlar için daha küçük bloklar; fazla yinelenen diyalog kayıtları için daha büyük bloklar önerilir.
Roman devamı: kayan pencere ve kayan taslak
Onuncu bölümden sonra tüm metin sığmaz ve sığmaya da gerek yoktur. İki katmanlı hafıza yaklaşımı:
- Yakın görünüm: Son iki veya üç bölümün orijinal metni; üslup, diyalog ritmi ve sahne detaylarını tutarlı kılar.
- Uzun vadede:Daha önceki bölümler özetlenerek bir taslağa dönüştürülür; karakter ilişkileri, gerilim unsurları ve çözülmemiş ipuçları korunur.
Her bölümü bitirdiğinizde, modele o bölümü üç ila beş cümleyle özetletip taslağa ekletin. Taslak 3000 token'ı aşarsa, tüm taslağı yeniden sıkıştırın.
def continue_story(chapters, outline, new_hint, keep_last=3):
"""chapters: 已写章节列表。只带最近 keep_last 章原文，更早的用 outline（滚动大纲）代替。"""
recent = "\n\n".join(chapters[-keep_last:])
prompt = (
f"【全书大纲（早期章节摘要）】\n{outline}\n\n"
f"【最近章节原文】\n{recent}\n\n"
f"【下一章要求】\n{new_hint}\n\n请写下一章，约 2000 字。"
)
return ask(prompt, max_tokens=4000)Gerilim unsurları en kolay kaybolan şeylerdir. Taslakta "çözülmemiş gerilim unsurları" için ayrı bir bölüm oluşturmanız önerilir; devam yazımında bu bölümün bu unsurlardan birini ele alması açıkça belirtilmelidir. Karakter ve yer isimleri de sabit bir liste halinde sistem mesajında tutulmalıdır; böylece pencere dışına çıkıldığında model kendi kendine isimleri değiştiremez.
Devam yazarken gözden kaçırılan bir sorun daha vardır: üslup kayması. Model, yazdıkça son birkaç bölüme daha çok benzer hale gelir. Eğer önceki bölümlerin üslubu sonrakilerle uyuşmuyorsa bu durum daha da belirginleşir. Çözüm olarak system mesajına bir "üslup örneği" ekleyin; en beğendiğiniz orijinal metinden bir parça seçin ve bunu sabit bir çapa olarak kullanın. Pencere kaydırıldığında bu örnek değişmez.
max_tokens ve kesme
Yanıtın kesilmesinin iki nedeni vardır:
finish_reasondeğerilengthise: max_tokens sınırına takıldınız. Çözüm: max_tokens değerini artırın veya modeli bloklar halinde yazmaya zorlayın ("burada dur, devam etmemi söylersen devam et").- İstek doğrudan 400 hatası verir: prompt ve max_tokens toplamı 100.000'i aştı. Çözüm olarak girdiyi kısaltın veya max_tokens değerini düşürün.
Pratik bir bütçe tablosu:
| Görev | Önerilen max_tokens | istem kullanılabilir (yaklaşık) |
|---|---|---|
| özet, çıkarma | 800 | 63,200 |
| Tek bölüm devamı (yaklaşık 2000 karakter) | 4000 | 60,000 |
| 10.000 kelime uzunluğunda uzun çıktılar | 16000 (üst sınır) | 48,000 |
uzun çıktılar ayrıca yanıt süresinden de etkilenir; akış çıktısını kullanmanız ve oluşturulurken gösterilmesi önerilir.
Devam yazma kesildiğinde, yarım kalan içeriği modele "devam et" diyerek basitçe atmayın. Daha güvenli bir yaklaşım, oluşturulan kısmı assistant mesajı olarak messages dizisine eklemek ve ardından user mesajı olarak "bir önceki cümlenin devamını yaz, tekrar etme" yazmaktır. Bu şekilde geçiş en doğal şekilde sağlanır. Bu adım prompt'u uzatacağından bütçeyi yeniden kontrol etmeyi unutmayın.
uzun bağlam penceresi için kontrol listesi
- Her istek öncesi istemi tahmin etmek için bir fonksiyon kullanın; bütçeyi aşarsanız bölme mantığına geçin.
- Her yanıt için usage verisini kaydedin ve tahmin katsayılarını sürekli olarak kalibre edin.
- system mesajını ve taslağı en başa yerleştirin; talimatların kritik kısımlarını en sonda tekrarlayın.
- finish_reason değerini kontrol edin; length ise uyarı verin veya devamı oluşturun.
- geçmiş konuşmalar için bir üst sınır belirleyin; bu sınırı aştığınızda en eski mesajları silin, API'nin 400 hatası vermesini beklemeyin.
İlgili içerik: İstem yapısı için İstem Yazımı, hata işleme için Hata Kodları ve Sorun Giderme Kılavuzu, fiyatlandırma için Fiyat Sayfası.
Son bir hatırlatma: Uzun bağlam penceresi uzun bellek anlamına gelmez. Model her istekte size sunduğu içeriği sıfırdan okur; önceki çağrıda neler olduğunu hatırlamaz. Sürekliliği sağlamak için geçmiş verileri kendiniz iletmelisiniz.
