- Meta เปิดตัว Code Llama ซึ่งเป็น โมเดลเฉพาะทางสำหรับโค้ดบนฐาน Llama 2 และเปิดให้ใช้งานฟรีทั้งเพื่อการวิจัยและเชิงพาณิชย์ ภายใต้ไลเซนส์ชุมชนแบบเดียวกัน
- Code Llama รับได้ทั้งโค้ดและพรอมป์ต์ภาษาธรรมชาติ เพื่อรองรับ การสร้างโค้ด การเติมโค้ดให้สมบูรณ์ และการดีบัก พร้อมรองรับ Python, C++, Java, PHP, TypeScript, C#, Bash และอื่น ๆ
- โมเดลมีขนาด 7B, 13B, 34B, 70B โดยรุ่นเล็กเหมาะกับงานที่ต้องการ latency ต่ำ ส่วน 34B และ 70B มุ่งให้การช่วยเขียนโค้ดที่ดีกว่า
- มีทั้งโมเดลพื้นฐาน โมเดลเฉพาะทาง Python และ รุ่น Instruct ที่ปรับให้เข้าใจคำสั่งภาษาธรรมชาติ โดยแนะนำให้ใช้ Instruct สำหรับการสร้างโค้ดจริง
- ในการประเมินภายใน Code Llama 34B ทำได้ HumanEval 53.7%, MBPP 56.2% และเป็นแนวทางที่ต้องการเปิดโมเดลเฉพาะทางด้านโค้ดให้ชุมชนช่วยประเมินและปรับปรุงช่องโหว่
วิธีการเปิดเผยและอัปเดต 70B
- Meta เปิดตัว Code Llama โมเดลภาษาขนาดใหญ่ที่สามารถสร้างโค้ดจาก text prompt ได้
- Code Llama ตั้งเป้าประสิทธิภาพระดับแนวหน้าสำหรับ LLM ด้านโค้ดที่เปิดให้ใช้งานสาธารณะ โดยมุ่งทำให้ workflow ของนักพัฒนาเร็วและมีประสิทธิภาพมากขึ้น พร้อมลดอุปสรรคในการเริ่มต้นสำหรับผู้เรียนเขียนโค้ด
- เปิดให้ใช้ฟรีทั้งเพื่อการวิจัยและการใช้งานเชิงพาณิชย์ และเผยแพร่ภายใต้ ไลเซนส์ชุมชนแบบเดียวกับ Llama 2
- ในอัปเดตวันที่ 29 มกราคม 2024 ได้เพิ่ม Code Llama 70B ซึ่งเป็นรุ่นที่ใหญ่และมีประสิทธิภาพดีที่สุดในตระกูล Code Llama
- CodeLlama - 70B: โมเดลโค้ดพื้นฐาน
- CodeLlama - 70B - Python: โมเดล 70B เฉพาะทาง Python
- Code Llama - 70B - Instruct: โมเดล 70B ที่ปรับละเอียดมาเพื่อเข้าใจคำสั่งภาษาธรรมชาติ
โมเดลที่ปรับ Llama 2 ให้เหมาะกับงานโค้ด
- Code Llama คือ เวอร์ชันเฉพาะทางด้านโค้ด ของ Llama 2 ที่ถูกฝึกเพิ่มด้วยชุดข้อมูลเฉพาะด้านโค้ด
- รับได้ทั้งโค้ดและพรอมป์ต์ภาษาธรรมชาติเป็นอินพุต เพื่อนำไปใช้กับงานเขียนโค้ดหลายรูปแบบ
- การสร้างโค้ด
- การสร้างข้อความภาษาธรรมชาติเกี่ยวกับโค้ด
- การเติมโค้ดให้สมบูรณ์
- การดีบัก
- ตัวอย่างพรอมป์ต์คือคำขอภาษาธรรมชาติอย่าง “ช่วยเขียนฟังก์ชันที่พิมพ์ลำดับฟีโบนัชชีให้หน่อย”
- ภาษาที่รองรับได้แก่ Python, C++, Java, PHP, TypeScript(JavaScript), C#, Bash
ขนาดโมเดล ข้อมูลฝึก และตัวเลือกด้าน latency
- Code Llama มีให้เลือกขนาดพารามิเตอร์ 7B, 13B, 34B, 70B
- รุ่นที่ไม่ใช่ 70B ถูกฝึกด้วยโค้ดและข้อมูลที่เกี่ยวข้องกับโค้ดจำนวน 500B โทเค็น ส่วน 70B ถูกฝึกด้วย 1T โทเค็น
- โมเดลพื้นฐานและรุ่น Instruct ของ 7B และ 13B ถูกฝึกด้วยความสามารถ fill-in-the-middle(FIM) เพื่อแทรกโค้ดใหม่เข้าไปกลางโค้ดเดิมได้
- รองรับงานอย่างการเติมโค้ดแบบทันที
- แต่ละขนาดโมเดลมีคุณสมบัติด้านต้นทุนการเสิร์ฟและ latency แตกต่างกัน
- โมเดล 7B สามารถเสิร์ฟได้บน GPU เดียว
- รุ่น 34B และ 70B ให้ผลลัพธ์ดีที่สุดและช่วยงานเขียนโค้ดได้ดีกว่า
- รุ่น 7B และ 13B เร็วกว่า จึงเหมาะกับงานที่ต้องการ latency ต่ำ เช่น การเติมโค้ดแบบเรียลไทม์
- โมเดล Code Llama ให้การสร้างผลลัพธ์ที่เสถียรในบริบทสูงสุด 100,000 โทเค็น
- ทุกโมเดลถูกฝึกด้วยลำดับความยาว 16,000 โทเค็น
- และแสดงการปรับปรุงเมื่อรับอินพุตสูงสุด 100,000 โทเค็น
- ลำดับอินพุตที่ยาวช่วยได้ไม่เพียงกับการสร้างโปรแกรมที่ยาวขึ้น แต่ยังช่วยส่งบริบทจาก codebase ให้โมเดลได้มากขึ้น ทำให้ผลลัพธ์ที่สร้างมีความเกี่ยวข้องมากขึ้น
- ในการดีบัก codebase ขนาดใหญ่ อาจยากที่จะมองเห็นโค้ดทั้งหมดที่เกี่ยวข้องกับปัญหาเฉพาะจุด นักพัฒนาจึงสามารถส่งโค้ดก้อนใหญ่ทั้งชุดให้โมเดลได้
สามรูปแบบ: พื้นฐาน, Python และ Instruct
- ตระกูล Code Llama นอกจากโมเดลพื้นฐานแล้ว ยังมี โมเดลเฉพาะทาง Python และ รุ่น Instruct ด้วย
- Code Llama - Python เป็นโมเดลเฉพาะภาษาที่ถูกปรับละเอียดเพิ่มเติมด้วยโค้ด Python จำนวน 100B โทเค็น
- Python เป็นภาษาที่ถูกนำไป benchmark ด้านการสร้างโค้ดมากที่สุด
- Python และ PyTorch มีบทบาทสำคัญในชุมชน AI
- Code Llama - Instruct เป็นรุ่นที่ผ่าน instruction tuning และ alignment
- ฝึกต่อด้วยอินพุตคำสั่งภาษาธรรมชาติและเอาต์พุตที่คาดหวัง
- ออกแบบมาให้เข้าใจผลลัพธ์ที่มนุษย์คาดหวังจากพรอมป์ต์ได้ดียิ่งขึ้น
- สำหรับการสร้างโค้ดจริง แนะนำให้ใช้ Code Llama - Instruct
- เพราะถูกปรับละเอียดให้สร้างคำตอบที่มีประโยชน์และปลอดภัยในภาษาธรรมชาติ
- ไม่แนะนำให้ใช้ Code Llama และ Code Llama - Python กับงานภาษาธรรมชาติทั่วไป
- ทั้งสองโมเดลไม่ได้ถูกออกแบบมาให้ทำตามคำสั่งภาษาธรรมชาติ
- Code Llama ถูกออกแบบสำหรับงานเฉพาะด้านโค้ด และไม่เหมาะเป็นโมเดลฐานสำหรับงานประเภทอื่น
- ผู้ใช้ต้องปฏิบัติตามไลเซนส์และนโยบายการใช้งานที่อนุญาต
การประเมิน benchmark และความปลอดภัย
- Meta ใช้ benchmark HumanEval และ MBPP เพื่อประเมินประสิทธิภาพของ Code Llama
- ใน benchmark ภายใน Code Llama แสดงประสิทธิภาพดีกว่า LLM เฉพาะทางด้านโค้ดแบบโอเพนซอร์สและดีกว่า Llama 2
- Code Llama 34B ทำได้ HumanEval 53.7%, MBPP 56.2%
- เป็นคะแนนสูงสุดเมื่อเทียบกับโซลูชันสาธารณะระดับแนวหน้าอื่น ๆ
- ถูกประเมินว่าอยู่ในระดับเทียบเท่า ChatGPT
- ก่อนเปิดตัว ได้มีการใช้มาตรการด้านความปลอดภัยหลายอย่าง และมีการประเมินเชิงปริมาณความเสี่ยงในการสร้างโค้ดอันตรายระหว่างกระบวนการ red team
- สร้างพรอมป์ต์ที่ขอให้สร้างโค้ดอันตรายอย่างชัดเจน
- นำคำตอบของ Code Llama ไปเปรียบเทียบและให้คะแนนกับคำตอบของ ChatGPT(GPT3.5 Turbo)
- ผลลัพธ์ระบุว่า Code Llama ให้คำตอบที่ปลอดภัยกว่า
- รายละเอียดการทำ red team โดยผู้เชี่ยวชาญด้าน Responsible AI, offensive security engineering, การพัฒนามัลแวร์ และ software engineering สามารถดูได้ในงานวิจัย
เอกสารที่เปิดเผยและการใช้งานอย่างรับผิดชอบ
- ปัจจุบันนักพัฒนาใช้ LLM กับงานหลากหลายตั้งแต่การเขียนซอฟต์แวร์ใหม่ไปจนถึงการดีบักโค้ดเดิม
- Code Llama มีเป้าหมายทำให้ workflow ของนักพัฒนามีประสิทธิภาพขึ้น เพื่อให้โฟกัสกับงานที่เน้นมนุษย์มากกว่างานซ้ำ ๆ
- Meta มองว่า LLM สำหรับงานโค้ดสามารถได้รับประโยชน์อย่างมากจาก แนวทางแบบเปิด ทั้งในด้านนวัตกรรมและความปลอดภัย
- โมเดลเฉพาะทางด้านโค้ดที่เปิดเผยสู่สาธารณะช่วยให้ชุมชนประเมินความสามารถของโมเดล ค้นหาปัญหา และแก้ไขช่องโหว่ได้
- สูตรการฝึกของ Code Llama ถูกเปิดเผยใน GitHub repository
- ค่าน้ำหนักโมเดลมีให้ที่ หน้า Llama
- งานวิจัย ครอบคลุมรายละเอียดการพัฒนา วิธีทดสอบ benchmark ข้อจำกัด ความท้าทายที่ทราบแล้ว มาตรการบรรเทา และประเด็นสำหรับการศึกษาต่อ
- Responsible Use Guide ก็ได้รับการอัปเดตเพื่อให้แนวทางสำหรับการพัฒนาโมเดล downstream อย่างรับผิดชอบ
- การกำหนดนโยบายเนื้อหาและมาตรการบรรเทา
- การเตรียมข้อมูล
- การปรับละเอียดโมเดล
- การประเมินและปรับปรุงประสิทธิภาพ
- การรับมือความเสี่ยงในระดับอินพุตและเอาต์พุต
- การสร้างความโปร่งใสและกลไกการรายงานในปฏิสัมพันธ์กับผู้ใช้
- นักพัฒนาควรประเมินโมเดลด้วย benchmark เฉพาะทางด้านโค้ด และทำวิจัยความปลอดภัยสำหรับกรณีใช้งานอย่างการสร้างมัลแวร์ ไวรัสคอมพิวเตอร์ และโค้ดที่มีเจตนาร้าย
- ยังแนะนำให้ใช้ชุดข้อมูลด้านความปลอดภัยสำหรับการประเมินทั้งแบบอัตโนมัติและโดยมนุษย์ รวมถึงการทำ red team ด้วย adversarial prompt
ขั้นต่อไปและแหล่งอ้างอิง
- Code Llama ถูกออกแบบมาเพื่อสนับสนุนวิศวกรซอฟต์แวร์ในหลายภาคส่วน เช่น งานวิจัย อุตสาหกรรม โครงการโอเพนซอร์ส NGO และองค์กรธุรกิจ
- ยังมีกรณีใช้งานอีกมากที่เกินกว่าความสามารถที่โมเดลพื้นฐานและรุ่น Instruct มอบให้ได้ในตอนนี้
- Meta คาดหวังว่า Code Llama จะเป็นจุดเริ่มให้ผู้อื่นนำ Llama 2 ไปสร้างเครื่องมือใหม่สำหรับงานวิจัยและผลิตภัณฑ์เชิงพาณิชย์
- เอกสารที่เกี่ยวข้อง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ใช้งานกับ llama.cpp ได้แทบจะทันที จึงลองทดสอบบนเครื่องโลคัลได้ง่าย: https://github.com/ggerganov/llama.cpp/issues/2766
ลองรัน CodeLlama-7b-Python แบบควอนไทซ์ q4_0 แล้ว สำหรับพรอมป์ต์ Python ที่ว่า “จงพิมพ์จำนวนเฉพาะ 10 ตัวแรก” มันสร้างโค้ดที่ดูสมเหตุสมผล รวมถึง
print_primes,is_prime,mainน่าสนใจว่าโมเดลที่ใหญ่กว่านี้จะออกมาเป็นอย่างไร โดยเฉพาะหลังผ่านการจูนจากคอมมูนิตี้และมีบริบท/พรอมป์ต์ที่ดีขึ้น
ใน
primes_upto(limit: int)ให้ใช้แอร์เรย์บูลีนทำเครื่องหมายจำนวนประกอบ แล้วใช้itertools.isliceเพื่อพิมพ์เฉพาะ 10 ตัวแรก ก็จะได้2 3 5 7 11 13 17 19 23 29print("1, 2, 3, 5, 7, 11... and so on!Llama2 ก็ออกมากว่าหนึ่งเดือนแล้ว แต่ยังรอสิทธิ์เข้าถึงมาหลายสัปดาห์ และโมเดลนี้ก็ต้องผ่านฟอร์มเดียวกัน เลยไม่ค่อยคาดหวังเท่าไร
เลยสงสัยว่าได้มาด้วยวิธีอื่นหรือเปล่า
แน่นอนว่าเกือบจะเป็นเรื่องของนิยาม และอาจมีคอมมูนิตี้หรือสาขาที่ถือว่า 1 เป็นจำนวนเฉพาะได้ แต่ความละเอียดอ่อนแบบนี้จะโผล่ออกมาเวลาใช้โมเดลภาษา
¹) https://www.google.com/search?q=is+1+a+prime+number
โดยส่วนตัว จุดสำคัญคือส่วนที่ให้การสร้างผลลัพธ์ที่เสถียรใน บริบทสูงสุด 100,000 โทเคน
โมเดลทั้งหมดถูกฝึกด้วยลำดับ 16,000 โทเคน และว่ากันว่าแสดงการปรับปรุงแม้กับอินพุตสูงสุด 100,000 โทเคน
แต่พออ่านเปเปอร์แล้ว ความแม่นยำในการค้นคืนข้อมูลสำคัญแย่ลงมากหลัง 16k โทเคน ดังนั้นต้องรอดูว่าบริบท 100k จะมีประโยชน์จริงแค่ไหน
ในเปเปอร์มี Unnatural Code Llama ซึ่งถ้าไม่นับกรณีที่แพ้ Code Llama Python เล็กน้อยใน MBPP pass@100 และแพ้ GPT-4 เล็กน้อยใน HumanEval pass@1 ก็เหนือกว่าโมเดล/การปรับจูนอื่น ๆ ในทุกเบนช์มาร์ก
Meta บอกเพียงว่าจะไม่ปล่อยโมเดลนี้ในภายหลังโดยไม่อธิบาย เลยสงสัยว่าทำไมถึงไม่ปล่อยโมเดลที่ดูยอดเยี่ยมขนาดนั้นออกมา
การใช้ชั้น Transformer ที่กว้าง 100k ตรง ๆ คงเป็นไปไม่ได้ในแง่ต้นทุน แล้วใช้ทริกอะไรนะ
แม้แต่ โมเดล 7B ของ Code Llama ก็ดูจะแข่งขันกับ Codex ซึ่งเป็นโมเดลเบื้องหลัง Copilot ได้
https://ai.meta.com/blog/code-llama-large-language-model-cod...
GitHub เองก็พูดหลายครั้งแล้วว่าจะขยับไปทาง GPT-4 พร้อมกับ “Copilot X”[1][2]
[0] https://github.blog/2023-07-28-smarter-more-efficient-coding...
[1] https://github.com/features/preview/copilot-x
[2] https://github.blog/2023-07-20-github-copilot-chat-beta-now-...
ผมเปิด 7B ค้างไว้ในแท็บเทอร์มินัลตลอดเวลาระหว่างเขียนโค้ด เพื่อถามอะไรประมาณว่า “ของสุ่ม ๆ แบบนี้ต้องทำยังไง?” และโดยส่วนตัวแล้วมันแทบจะแทน Google/Stack Overflow ได้เลย
Code Llama Python น่าสนใจมาก เพราะถูกจูนมาโดยเฉพาะสำหรับ Python
สงสัยว่าจะสร้าง LLM เฉพาะสาขาได้ไหม เช่น โมเดลที่เก่ง Rust โดยรวม โมเดลที่เก่ง Linux โดยรวม โมเดลที่เก่งจีโนมิกส์โดยรวม โมเดลที่เก่งการสร้างแบบจำลองทางฟิสิกส์โดยรวม แล้วให้พวกมันคุยกันเพื่อแก้ปัญหาร่วมกัน
น่าจะเป็นอนาคตที่ค่อนข้างบ้าบิ่นในการทำให้เครื่องจักรทำงานจริง ๆ
แต่เป็นไปได้สูงว่าจะใช้โมเดลขนาดใหญ่ไม่กี่ตัว มากกว่าจะใช้โมเดลขนาดเล็กจำนวนมาก
เมื่อไม่กี่เดือนก่อนมีความพยายามคล้าย ๆ กันสำหรับสคริปต์ Godot และว่ากันว่าค่อนข้างดี: https://github.com/minosvasilias/godot-dodo
ผมคิดว่าสาเหตุที่ยังไม่มีความพยายามมากกว่านี้ เพราะ Llama พื้นฐานไม่ได้เก่งด้านโค้ดนักเมื่อเทียบกับจุดแข็งด้านอื่น ๆ และสิ่งอย่าง Starcoder ก็ถูกกลบไปพอสมควร
ถ้ายังไม่รู้จัก ลองค้นหา Society of Mind ดูก็ดี
C มีระดับต่ำพอสมควร แต่ในบางช่วงที่หายากก็ยังอ่านได้
โมเดลที่ดีที่สุดอย่าง Unnatural Code Llama ไม่ได้ถูกเปิดเผยต่อสาธารณะ
น่าจะเป็นเพราะอาจถูกฝึกด้วยข้อมูลที่อิงจาก GPT-4 ซึ่งอาจละเมิดข้อกำหนดการใช้งานของ OpenAI
ตามบทความ “Unnatural”[1] ข้อมูล “unnatural” ถูกสร้างขึ้นด้วยความช่วยเหลือจาก LLM บางตัว และถ้าเป็นไปได้ก็คงอยากใช้ LLM ที่ดีที่สุด
[1] https://arxiv.org/pdf/2212.09689.pdf
TheBloke ไม่ใช่เล่น ๆ เลย[1]
คิดว่าน่าจะมีเวอร์ชัน quantized ออกมาภายในวันนี้ และตื่นเต้นมากที่จะได้ลองโมเดล 34B Python แบบ quantized 4 บิตที่น่าจะใส่ลง 3090 ได้พอดี
[1] https://huggingface.co/TheBloke/CodeLlama-13B-Python-fp16
ollama run codellama:7b-instructhttps://ollama.ai/blog/run-code-llama-locally
ตอนนี้ก็ยังมีโมเดลเพิ่มขึ้นเรื่อย ๆ: https://ollama.ai/library/codellama
ถ้าต้องการรัน Code Llama ในเครื่อง สามารถดาวน์โหลดและรันเวอร์ชัน quantized ของโมเดลพารามิเตอร์ 7B ด้วยเครื่องมือโอเพนซอร์ส Ollama ได้: https://github.com/jmorganca/ollama
ollama run codellama "write a python function to add two numbers"โมเดลสำหรับ completion, โมเดล Python และโมเดลที่มีจำนวนพารามิเตอร์หลากหลายกว่านี้จะถูกเพิ่มเข้ามาเร็ว ๆ นี้
context window 100,000 โทเคนก็ไม่เลว แต่สงสัยว่าโมเดลโค้ดแบบฝังในตัวจะเลือกบริบทแบบไหนเมื่อต้องจัดการกับ codebase ที่ใหญ่กว่า 100K โทเคน
ถ้าเรารู้ว่าเครื่องมือแบบนี้จะถูกใช้อย่างแพร่หลายและพึ่งพามากขึ้น ก็สงสัยว่าจะมีประเด็นใหม่ ๆ ที่ต้องคิดตอนเขียนโค้ดหรือไม่
ควรเขียนคอมเมนต์มากขึ้นหรือน้อยลง ควรเขียนโค้ดให้สั้นลงและอ่านยากขึ้นเพื่อใช้โทเคนน้อยลง ควรเปลี่ยนโครงสร้างไฟล์หรือกฎการตั้งชื่อหรือไม่ สุดท้ายแล้วเพื่อใช้ประโยชน์จากเครื่องมือเหล่านี้ให้เต็มที่ เราควรปรับตัวอย่างไร
เราอาจทำให้โค้ดไม่พึ่งพาบริบทและย่อให้ใช้โทเคนน้อยลงได้ แต่แบบนั้นจะยิ่งทำให้ทั้งคนและโมเดลภาษาสับสนกว่าเดิม
ถ้าสุดโต่งถึงขั้นใช้แต่ฟังก์ชันและตัวแปรชื่ออักษรเดียวอย่าง
i,j,kโมเดลก็จะอนุมานอะไรไม่ได้เลยและสร้างเรื่องมั่ว ๆ ขึ้นมาทางแก้คือแยกงานใหญ่เป็น โมดูล black-box และ API เล็ก ๆ เหมือนที่เราทำกันอยู่แล้วเวลาจัดการความซับซ้อน เพื่อซ่อน implementation ที่กินโทเคนเยอะและทำให้ไม่เกี่ยวข้องกับการใช้งาน
ถ้าให้ function signature, คำอธิบายดี ๆ และตัวอย่างการใช้ไม่กี่ตัวอย่างกับ LLM มันก็สามารถใช้ฟังก์ชันนั้นได้โดยไม่ต้องรู้ implementation
ความกระชับมีแต่จะลดความสามารถของ LLM ในการจัดการโค้ด ไม่ได้แก้ปัญหาความยาวบริบท และถึงอย่างดีที่สุดก็ไม่ขยายสเกล
100k โทเคนถือว่าเยอะพอแล้ว จึงไม่จำเป็นต้องทำแบบนั้น
ข้อมูลนี้สามารถบีบอัดให้อยู่ในรูปแบบที่เหมาะกับการแสดงให้ LLM ดูได้
เช่น หากต้องการสร้าง implementation ของเมธอดในคลาส C++ ก็สามารถให้ LLM ดูเวอร์ชันย่อของไฟล์ header ที่คอมไพเลอร์จะเห็นตอนคอมไพล์คลาสนั้นได้
การลบ whitespace และคอมเมนต์ รวมถึงย่อ macro จะช่วยประหยัดโทเคนได้มาก
header ของไลบรารีมาตรฐานมีโอกาสสูงที่ LLM จะรู้จักดีจากกระบวนการ fine-tune จึงอาจตัดออกได้
ไฟล์ C++ ที่ผ่านการ preprocess ทั่วไปอาจแตะขีดจำกัด 100K ได้แม้จะ optimize ไปบ้างแล้ว ดังนั้นจึงจำเป็นต้องมี middleware ที่ช่วยกลั่นกรองเพิ่มเติมก่อนส่งให้ LLM
โมเดลจะให้เหตุผลและข้อเสนอแนะได้ดีขึ้น
ในด้านข้อมูลก็คล้ายกัน ข้อมูลที่ติดแท็กอย่างถูกต้องและชื่อฟิลด์ที่สื่อความหมายทำให้คำตอบของ LLM มีประโยชน์ขึ้นมาก
แอบหวังว่าการแพร่หลายของเครื่องมือเหล่านี้จะทำให้เพื่อนร่วมทีมพัฒนาหันมาเขียนคอมเมนต์ในโค้ดสักที และเลิกใช้ชื่อตัวแปรสามตัวอักษร
วิธีเลือกว่าจะใส่ไฟล์ไหนให้ GPT-4 ใช้ embedding เป็นฐาน
ใช้ embedding ของแต่ละไฟล์ และ embedding ที่สร้างจากคำสั่งแล้วผ่านการประมวลผลง่าย ๆ เพื่อเลือกไฟล์ที่ดูเกี่ยวข้องมากที่สุด
มันไม่สมบูรณ์แบบ แต่สำหรับ codebase ขนาดกลางส่วนใหญ่ก็เพียงพอ และไม่เหมาะกับ codebase ขนาดใหญ่มาก
implementation นี้ทำให้เริ่มทำไฟล์ให้สั้นลงและย้ายเนื้อหาไปไฟล์อื่น
ไฟล์ที่ยาวเกิน 1,000 บรรทัดกิน context window ไปหมดจนหนักมาก และถึงจะเบาลงเมื่อมี context window 100k แต่โดยพื้นฐานแล้วคิดว่าควรรักษาไฟล์ให้สั้นอยู่ดี
ยังมีวิธีที่ฉลาดกว่านี้ เช่น embedding แล้วส่งเฉพาะฟังก์ชัน/คลาสแต่ละตัวแทนที่จะส่งทั้งไฟล์ ดังนั้นอีกไม่นานคงมีใครทำของที่ดีกว่านี้ออกมา
มีความเป็นไปได้สูงว่าแทบไม่จำเป็นต้องเปลี่ยนแพตเทิร์นการเขียนโค้ดเพื่อใช้ AI
งานอย่างรวมโค้ดที่แยกกันไว้ให้เป็นไฟล์ใหญ่ไฟล์เดียว ลดคอมเมนต์ และลบ whitespace สามารถให้ preprocessor สำหรับ LLM ทำได้
Copilot ทำงานได้ดีมาจนถึงตอนนี้ แต่ข้อจำกัดอยู่ที่ อินเทอร์เฟซ
ดูเหมือนมันรู้แค่การคาดเดาชิ้นส่วนข้อความถัดไปเท่านั้น
สงสัยว่ามีใครกำลังสร้าง AI สำหรับโค้ดที่เสนอการรีแฟกเตอร์อย่างเช่น “บรรทัดเหล่านี้ซ้ำกัน ควรแยกออกเป็นฟังก์ชัน” หรือ “ถ้าเปลี่ยนโครงสร้างนี้เป็นแบบนี้จะใช้ง่ายขึ้น” อยู่บ้าง
ที่ Cody.dev สามารถสร้าง embedding สำหรับทั้ง repository ได้ จึงมี context ที่ใหญ่กว่ามากเกี่ยวกับ codebase และปัญหาที่กำลังจะแก้
อนึ่ง ฉันเพิ่งเข้าร่วม Sourcegraph เมื่อไม่กี่สัปดาห์ก่อน
ผมมองว่ายังไม่มีอะไรที่แข็งแรงพอ
แค่ไฮไลต์โค้ดแล้วสั่ง และยังรองรับการใช้ Code Llama ด้วย: https://continue.dev/docs/walkthroughs/codellama
IntelliJ IDEA เสนอทั้งสองอย่างให้ในเครื่องอยู่แล้ว
มันสามารถหาก้อนโค้ดซ้ำขนาดใหญ่และรีแฟกเตอร์เป็นฟังก์ชันให้อัตโนมัติได้ และยังมี inspection จำนวนมากที่เสนอการรีแฟกเตอร์เพื่อทำให้โค้ดชัดเจนขึ้น
ครั้งล่าสุดที่ได้ยินยังเป็นเบต้าอยู่ และทำงานได้ไม่ดีนัก
แม้แต่ในหน้าตัวอย่าง brush “add types” ก็เข้มงวดเกินไป เพราะ
aกับbต้องถูกตรวจnullและ “fix simple bug” ก็ใกล้เคียงกับการแก้พิมพ์ผิดมากกว่าในมุมของมือใหม่เต็มตัวที่ไม่เคยรันโมเดลแบบนี้เอง อยากรู้ว่าต้องใช้ ฮาร์ดแวร์ แบบไหน
หาใน README ไม่ค่อยเจอ
ไอเดียที่ว่าสามารถใช้โมเดลแบบนี้ได้โดยไม่ต้องอัปโหลดซอร์สโค้ดไปยังบริษัทเทคโนโลยีขนาดใหญ่นั้นชอบมากจริง ๆ
แค่ติดตั้งแอปแล้วรันคำสั่ง shell ไม่กี่คำสั่งก็พอ
คิดว่าโมเดลนี้ก็คงจะมีให้ใช้เร็ว ๆ นี้ และถ้าเป็นเช่นนั้นก็น่าจะใช้ร่วมกับส่วนขยาย Continue ของ VS Code ได้
ถึงจะค่อนข้างช้า แต่ดูเหมือน swap จะเป็นตัวทดแทนที่พอใช้ได้ แม้ไม่มี RAM ขนาดใหญ่ตามที่ต้องการ
Ollama บอกว่าการรันโมเดล 13B ต้องใช้ 32GB แต่ผมกำลังรันโมเดล
llama2:13bบน MBP 16GB อยู่ส่วน 7B นี่ถึงขั้นน่าจะรันบนเครื่องปิ้งขนมปังอัจฉริยะได้
ไม่อย่างนั้น inference บน CPU ด้วย llama.cpp ก็น่าจะทำงานได้บนเครื่องส่วนใหญ่