คู่มือบริบทยาว Kimi K3: ป้อนหนังสือทั้งเล่มและทั้งรีโพใน 1 ล้านโทเคน

บริบทยาวคือความสามารถ signature ของสายผลิตภัณฑ์ Kimi และ kimi-k3 ดันหน้าต่างไปถึง 1,000,000 โทเคนที่แบ่งปันระหว่างอินพุตและเอาต์พุต ลองรู้สึกถึงขนาดนี้: คำขอเดียวจุหนังสือเทคนิคทั้งเล่ม ไฟล์หลักทั้งชุดของโค้ดรีโพขนาดเล็ก หรือบันทึกประชุมทั้งปีของทีมได้ทั้งหมด แต่ "ใส่ได้" กับ "ใช้เป็น" เป็นคนละเรื่อง — ยิ่งหน้าต่างใหญ่ ยิ่งต้องจัดการคุณภาพอินพุตและต้นทุนอย่างมีสติ

1 ล้านโทเคนใส่ได้แค่ไหน

ความหนาแน่นโทเคนต่างกันมากตามภาษา ตารางนี้เป็นการประมาณเชิงวิศวกรรม ให้ตรวจด้วย tokenizer จริง:

งานแบบไหนที่คุ้มใช้เต็มหน้าต่าง

งานที่หนึ่ง: เข้าใจเอกสารทั้งฉบับที่มีการอ้างอิงข้ามบท สัญญา หนังสือชี้ชวน รายงานวิจัยยาว — ข้อสรุปกระจายอยู่หลายบท ข้อกำหนดอ้างอิงกันไปมา การหั่นเป็นชิ้นทำให้สัญญาณอ้างอิงข้ามหายไป การอ่านทั้งฉบับในหน้าต่างเดียวจึงสร้างบริบทครบถ้วน

งานที่สอง: ถาม-ตอบระดับทั้งรีโพ เอาไฟล์หลักของโปรเจ็กต์ขนาดกลางใส่บริบททั้งหมด โมเดลตอบคำถามข้ามไฟล์ได้ว่า "ฟังก์ชันนี้ถูกเรียกจากที่ไหน" "แก้ interface นี้แล้วโมดูลไหนพัง" โดยไม่ต้องมีท่อ retrieval ก่อน

งานที่สาม: ประวัติสนทนาหรือบริบทสะสมจากไปป์ไลน์ ในโปรเจ็กต์ระยะยาว การตัดสินใจและข้อสรุปก่อนหน้าต้องอยู่ครบ 1 ล้านโทเคนเก็บห่วงโซ่การตัดสินใจหลายเดือนได้

รูปแบบสองขั้น: หาตำแหน่งก่อน อ่านละเอียดทีหลัง

ขั้นแรก: กรอง. ใช้โมเดลเล็กหรือค้นด้วยคีย์เวิร์ด เลือกส่วนที่เกี่ยวข้อง เป้าหมายไม่ใช่ตอบคำถาม แต่ย่อวัสดุจาก "ทั้งหมด" เหลือ "ที่เกี่ยวข้อง"

ขั้นที่สอง: อ่านละเอียด. ป้อนวัสดุที่เลือกทั้งหมดให้ kimi-k3 วิเคราะห์ด้วยบริบทครบ

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EXAIV_API_KEY"],
    base_url="https://exaiv.com/api/ai/v1",
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You are a contract review assistant. Answer only from the given text."},
        {"role": "user", "content": f"Below is the full agreement. List every clause unfavorable to party B:\n\n{contract_text}"},
    ],
)
print(resp.choices[0].message.content)

ผลตอบแทนหลักคือความแม่น: ขั้นอ่านละเอียดไม่มีวัสดุรบกวน ความสนใจของโมเดลไม่เจือจาง คำตอบนิ่งกว่าแบบเททั้งหมดลงไป

คุมต้นทุน

โครงสร้างต้นทุนชัดเจน: อินพุตโทเคนคือตัวใหญ่ สี่คันโยกคุมบิล:

หนึ่ง: ป้อนตามต้องการ ถามว่าฟังก์ชันเดียวทำอะไร ไม่ต้องใช้ทั้งรีโพ ส่งไฟล์ที่เกี่ยวข้องพอ

สอง: ใช้ prefix ซ้ำ วาง system prompt และส่วนคงที่ของเอกสารไว้ต้นข้อความและไม่เปลี่ยน ให้แคช prefix ทำงาน kimi-k3 รองรับการแคช prefix อัตโนมัติ คำขอซ้ำบนเอกสารยาวเดียวกันถูกลงชัดเจน

สาม: ตัดเสียงรบกวน log, แท็ก HTML, ภาพ base64 เป็นเนื้อหาหนาโทเคนบางข้อมูล ล้างก่อนป้อน ถ้า 30% ของโทเคนเป็น log ที่ไร้ค่า ก็เท่ากับเผางบ 30%

สี่: จำกัดความยาวเอาต์พุต เอาต์พุตกินโควต้าเดียวกัน ตั้ง max_tokens ที่สมเหตุสมผล

กับดักที่ควรรู้

กับดักหนึ่ง: ข้อมูลกลางหน้าต่างถูกละเลย ในบริบทยาวมาก ข้อมูลกลางหน้าต่างบางครั้งถูกใช้ไม่เต็มที่เหมือนหัวท้าย แก้โดยวางคำสั่งสำคัญไว้ใน system prompt และท้ายข้อความผู้ใช้ วัสดุสำคัญไว้หัวท้าย

กับดักสอง: ป้อนประวัติทั้งหมด ประวัติสนทนาที่สะสมมากินหน้าต่าง สรุปเป็นระยะ เก็บข้อสรุปและการตัดสินใจ ลดรายละเอียดกระบวนการ

กับดักสาม: ใช้บริบทยาวเป็นหน่วยความจำ โมเดลไม่มีความจำข้ามคำขอ ทุกคำขอเริ่มใหม่ ต้องฝังวัสดุพื้นฐานทุกครั้งหรือดูแลไฟล์สรุปที่ฉีดต่อคำขอ

กับดักสี่: มองข้ามความต่าง tokenizer ข้อความผสมจีน-อังกฤษ โค้ด สัญลักษณ์พิเศษ ความหนาแน่นโทเคนต่างกันมาก ประเมินจากจำนวนตัวอักษรเชื่อถือไม่ได้ วัดจริงด้วยข้อมูลจริงก่อนตั้งงบ

คำถามที่พบบ่อย

บทความนี้ตอบอะไร

• บริบท 1 ล้านโทเคนใส่อะไรได้จริง
• วิเคราะห์เอกสารยาวอย่างไร
• ควบคุมต้นทุนบริบทยาวอย่างไร

แผนที่สถานการณ์โดยย่อ

มองข้างหน้า

แคตตาล็กและเวตยังคงเปลี่ยนแปลงต่อเนื่อง ข้อตกลงการเชื่อมต่อและการเรียกในที่นี้เป็นไปตามเอกสารทางการ ณ เวลาเผยแพร่

แหล่งที่มาและการตรวจสอบ

ข้อเท็จจริงสำคัญในบทความนี้มาจาก การ์ดโมเดล Kimi K3 ทางการ (สเปกบริบท) และการวัด tokenizer ของแพลตฟอร์ม และตรวจสอบเมื่อ 2026-11-09 รหัสโมเดล ราคา และความพร้อมใช้งานตามแคตตาล็อกสดของแพลตฟอร์ม โดยเจตนาไม่เขียนตัวเลขที่จะล้าสมัย โค้ดตัวอย่างตามสัญญา API ณ เวลาเผยแพร่ ตรวจสอบเอกสารทางการก่อนนำไปใช้งานจริง

ขอบเขตและกลุ่มผู้อ่าน

กลุ่มผู้อ่าน: นักพัฒนาที่จัดการเอกสารยาวหรือรีโพขนาดใหญ่ ครอบคลุม: รูปแบบการใช้บริบทยาว การควบคุมต้นทุน และขอบเขต ไม่ครอบคลุม: การออกแบบสถาปัตยกรรม RAG หรือการเลือก vector store

บันทึกบรรณาธิการและการแก้ไข

เขียนโดยทีมเนื้อหา EXAIV จากข้อเท็จจริงที่ตรวจสอบได้ ตรวจแหล่งที่มาและโค้ดก่อนเผยแพร่ หากมีข้อมูลล้าสมัยหรือผิดพลาด ให้ยึดหน้าเผยแพร่ทางการและแคตตาล็อกสด และแจ้งผ่านช่องข้อเสนอแนะของหน้าเพื่อให้เราอัปเดต

อ่านต่อ

• คู่มือเชื่อมต่อ Kimi K3
• คู่มือ RAG Knowledge Base
• Qwen KV Cache กับบริบทยาว
• การติดตาม Token และต้นทุน
• คู่มือ Structured Output