README อธิบายสถาปัตยกรรมของคุณ ส่วนโฟลเดอร์ docs อธิบายเหตุผลเบื้องหลังการตัดสินใจต่าง ๆ แต่จนถึงวันนี้ ไม่มีข้อมูลเหล่านั้นอยู่ในกราฟความรู้ของ Octocode เลย

0.20.0 ปิดช่องว่างนี้: ตอนนี้ไฟล์ Markdown เป็นโหนดในกราฟความรู้ของ GraphRAG และลิงก์ระหว่างเอกสารกลายเป็นความสัมพันธ์ references ที่ระบุชนิด ซึ่งผู้ช่วย AI สามารถไล่ตามได้จริง

เรื่องนี้กวนใจผมมานานแล้ว Octocode ค้นหา เอกสารของคุณได้เสมอ — semantic search ทำดัชนี Markdown มาตั้งแต่แรก แต่การหาเอกสารด้วยคีย์เวิร์ดกับการ ค้นพบ เอกสารนั้นด้วยการไล่ตามโครงสร้างของโปรเจกต์เป็นคนละเรื่องกัน ผู้ช่วยที่ถามว่า «มีอะไรขึ้นอยู่กับโมดูล payment บ้าง?» อาจเดินกราฟของโค้ดได้อย่างคล่องแคล่ว แต่กลับมองไม่เห็นบันทึกด้านสถาปัตยกรรมที่อยู่ห่างออกไปสามไดเรกทอรีและอธิบายว่า ทำไม โมดูลจึงถูกออกแบบมาเช่นนั้น

โค้ดเล่าเรื่องได้เพียงครึ่งเดียว ตอนนี้กราฟรู้อีกครึ่งหนึ่งแล้ว

สิ่งที่เปลี่ยนจริงๆ

สรุปสั้น ๆ: ระหว่างการทำดัชนี เอกสาร Markdown จะผ่านไปป์ไลน์ GraphRAG ชุดเดียวกับซอร์สโค้ด การคิวรีกราฟ การขยายความสัมพันธ์ และเครื่องมือ MCP graphrag จึงสามารถแสดงเอกสารควบคู่กับโค้ดได้ — ไม่ใช่ในฐานะการค้นหาแยก แต่เป็นส่วนหนึ่งของการสำรวจกราฟครั้งเดียวกัน

กลไกต่อไปนี้ทำให้ข้อมูลนั้นมีประโยชน์โดยไม่สร้างสัญญาณรบกวน:

ลิงก์ข้ามเอกสารกลายเป็นความสัมพันธ์ references เมื่อไฟล์ Markdown ลิงก์ไปยังอีกไฟล์หนึ่ง — [see the guide](guide.md) — Octocode จะบันทึก edge ที่ระบุชนิดไว้ระหว่างไฟล์ทั้งสอง ลิงก์แบบ relative จะ resolve จากตำแหน่งของไฟล์ที่มีลิงก์ ส่วน anchor fragment (#section) จะถูกตัดออก และ URL ภายนอกที่ขึ้นต้นด้วย http:// หรือ https:// จะถูกละเว้น โครงสร้างลิงก์ในเอกสารของคุณเป็นแผนที่มาโดยตลอด ตอนนี้กราฟอ่านแผนที่นั้นได้แล้ว

ค่าน้ำหนักถูกกำหนดอย่างตั้งใจ ในการสำรวจกราฟ references มีน้ำหนักความสำคัญ 0.6 — ต่ำกว่าความสัมพันธ์เชิงโครงสร้างของโค้ดอย่าง imports และ calls (0.7) แต่สูงกว่าความสัมพันธ์เชิงจัดระเบียบอย่างการอยู่ในไดเรกทอรีเดียวกัน (0.3) ลิงก์ระหว่างเอกสารจึงมีผลต่อทิศทางการขยายกราฟโดยไม่กลบโครงสร้างของโค้ด ลิงก์ระหว่างเอกสารสองฉบับคือการที่มนุษย์บอกว่า «สองสิ่งนี้เกี่ยวข้องกัน» นั่นเป็นสัญญาณที่มีความหมาย แต่ไม่เหมือนกับ call edge จริง ๆ และค่าน้ำหนักก็สะท้อนความแตกต่างนี้

ไฟล์ .markdown ใช้ได้ทุกที่ที่ .md ใช้ได้ ทั้งใน semantic search และการเชื่อมต่อกับกราฟแบบใหม่ เป็นรายละเอียดเล็ก ๆ แต่ความไม่สอดคล้องนี้เคยสร้างปัญหาให้ repository เก่า

และส่วนที่ผมชอบที่สุดของการอัปเกรดคือ คุณไม่ต้องทำดัชนีใหม่ตั้งแต่ต้น เนื้อหา Markdown ถูกเก็บไว้ในบล็อกเอกสารของดัชนีอยู่แล้ว การสร้างกราฟใหม่จึงดึงข้อมูลนั้นจากฐานข้อมูลเดิมได้ทันที เพียงรัน octocode index หรือสร้างกราฟใหม่ เอกสารของคุณก็จะปรากฏในกราฟ

บั๊กที่ซ่อนความสัมพันธ์โดยไม่ส่งสัญญาณเตือน

สำหรับบางคน การแก้บั๊กนี้สำคัญกว่าฟีเจอร์ใหม่เสียอีก

ตอนอ่านความสัมพันธ์กลับจาก LanceDB ระบบคืนค่าเพียงบางส่วนของ result set ที่บันทึกไว้ — batch ถัด ๆ มาถูกทิ้งแทนที่จะนำมาต่อกัน ในโปรเจกต์ขนาดเล็กคุณแทบไม่มีทางสังเกตเห็น แต่ในโปรเจกต์ขนาดใหญ่ การคิวรีกราฟอาจ พลาดความสัมพันธ์ที่ควรมีอยู่โดยไม่มีการแจ้งเตือนใด ๆ

«ไม่มีการแจ้งเตือน» คือประเด็นสำคัญ ไม่มี error ไม่มี warning มีเพียงกราฟที่ไม่ครบแต่ดูเหมือนครบ หากคุณเคยคิวรีกราฟของ repository ขนาดใหญ่แล้วคิดว่า «ตรงนี้น่าจะมี edge มากกว่านี้» บั๊กนี้น่าจะเป็นสาเหตุ ตอนนี้การสร้างหรือโหลดกราฟใหม่จะคืนชุดความสัมพันธ์ทั้งหมด

นอกจากนี้ยังมีการแก้ไขที่เกี่ยวข้องอีกสองรายการ:

  • หัวข้อ Markdown ไม่ปะปนอยู่ในดัชนี symbol ของโค้ดอีกต่อไป ก่อนหน้านี้หัวข้อเอกสารถูกทำดัชนีเป็น «symbols» และกระบวนการ resolve import ไปจับคู่กับหัวข้อเหล่านั้น ทำให้เกิดตัวเลือกความสัมพันธ์ที่ไม่ควรมี ตอนนี้โหนด Markdown ถูกนำออกจากดัชนี symbol แล้ว แต่ยังคงเป็นส่วนหนึ่งของกราฟผ่านลิงก์ที่อิง path
  • โหนด Markdown resolve ด้วย path ไม่ใช่ symbol ในขั้นตอนค้นหาความสัมพันธ์ที่ปรับประสิทธิภาพแล้ว เอกสารจะเข้าสู่กระบวนการ resolve ตาม path — ซึ่งตรงกับวิธีทำงานจริงของลิงก์เอกสาร — แทนการจับคู่ symbol ที่ออกแบบมาสำหรับโค้ด edge ระหว่างเอกสารจึงแม่นยำ ไม่ได้เกิดจากความบังเอิญอีกต่อไป

ใช้หน่วยความจำเพียงครึ่งเดียวเมื่อโหลดความสัมพันธ์

ระหว่างการ flush ของ incremental indexing ความสัมพันธ์เดียวกันอาจถูกเขียนซ้ำในหลาย batch สำหรับโปรเจกต์ขนาดใหญ่ที่ใช้งานจริง loader จึงต้องอ่าน 575K แถวเพื่อแทนความสัมพันธ์ที่ไม่ซ้ำ 288K รายการ — เกือบครึ่งหนึ่งของข้อมูลทั้งหมดเป็นรายการซ้ำ

ตอนโหลดกราฟ ระบบจะ deduplicate ความสัมพันธ์ด้วยชุดค่า (source, target, type) ซึ่งลดการใช้หน่วยความจำลงเกือบครึ่งและทำให้ทุก operation ที่ต้องวนผ่านกราฟทั้งชุดเร็วขึ้น เมื่อเอารายการซ้ำออก loader จะรายงานจำนวนที่ตัดทิ้ง คุณจึงตรวจสอบผลได้

ไม่ต้องเปลี่ยน config กราฟเพียงโหลดโดยใช้หน่วยความจำน้อยลง

ทุกอย่างที่เหลือ

MCP server อัปเกรดเป็น rmcp 3.0.0 SDK หลักของ Model Context Protocol เปลี่ยนเป็น major version ใหม่ ทำให้ Octocode ตามทันระบบนิเวศ MCP และการส่งข้อมูลแบบ streamable HTTP ทั้งโหมด server ผ่าน stdin และ HTTP ยังทำงานเหมือนเดิม — ไม่ต้องเปลี่ยน configuration

การจัดการ config ย้ายไปอยู่ใน octolib ตรรกะทั่วไปสำหรับจัดการไฟล์ config และย้ายข้อมูลระหว่างเวอร์ชัน — version walk, guards และ table merging — ตอนนี้อยู่ในไลบรารี octolib ที่ใช้ร่วมกัน ส่วน Octocode เก็บไว้เฉพาะขั้นตอนการย้าย v1→v2 ของตัวเอง สำหรับผู้ใช้ การเปลี่ยนแปลงนี้ไม่มีผลให้เห็น: config เดิมยังถูกย้ายเหมือนก่อนทุกประการ ข้อดีคือการแก้ไขระบบจัดการ config ทำเพียงครั้งเดียวใน octolib แล้วส่งผลถึงทุกเครื่องมือที่สร้างอยู่บนไลบรารีนี้ ไม่ต้องย้ายการแก้ไขทีละ repository

เอกสารก็ได้รับการปรับปรุงเช่นกัน ตอนนี้ README อธิบายเครื่องมือ MCP ทั้งหมด รวมถึงเครื่องมือที่ทำงานผ่าน LSP (lsp_goto_definition, lsp_find_references, lsp_hover, lsp_document_symbols, lsp_workspace_symbols, lsp_completion) และวิธีเปิดใช้ด้วย --with-lsp นอกจากนี้ยังมีคู่มือใหม่ที่ไม่ผูกกับผู้ให้บริการรายใด สำหรับเชื่อมต่อ Octocode กับ LLM หรือ embedding endpoint ที่รองรับ API แบบ OpenAI ไม่ว่าจะเป็น model server ในเครื่องหรือผู้ให้บริการ cloud รายอื่น

อัปเกรด

# Homebrew
brew upgrade muvon/tap/octocode

# Universal installer
curl -fsSL https://raw.githubusercontent.com/Muvon/octocode/master/install.sh | sh

# Cargo
cargo install octocode --version 0.20.0

นี่คือการอัปเกรดแบบ drop-in — ไม่ต้องเปลี่ยน config และไฟล์ configuration เดิมจะถูกย้ายให้อัตโนมัติ หลังอัปเกรดมีเพียงอย่างเดียวที่ต้องทำ:

สร้างกราฟใหม่ (หรือเพียงรัน octocode index) ในโปรเจกต์ที่มีเอกสารใช้งานจริง จากนั้นถามผู้ช่วยด้วยคำถามที่แต่ก่อนต้องอาศัยมนุษย์เชื่อมโยงโค้ดกับเอกสาร — «ระบบจัดการ authentication อยู่ที่ไหน และคู่มือความปลอดภัยอธิบายเรื่องนี้ไว้อย่างไร?» — แล้วดูว่าผู้ช่วยไล่ตามข้อมูลทั้งสองฝั่งได้อย่างไร

Octocode เป็นโครงการโอเพนซอร์สภายใต้ Apache 2.0 ที่ github.com/Muvon/octocode และเป็นเอนจินค้นหาโค้ดเบื้องหลัง Octomind กราฟรู้อยู่แล้วว่าโค้ดของคุณเชื่อมโยงกันอย่างไร ตอนนี้มันยังรู้ด้วยว่าคุณเขียนอะไรเกี่ยวกับโค้ดเหล่านั้น