ผู้ช่วยสถาปัตยกรรมที่พูดคุยกับข้อมูลบริษัท

กำไร:

• การออกแบบส่วนประกอบและการไหลของข้อมูลของผู้ช่วย RAG ระดับองค์กรแบบครบวงจร
• การรวมข้อมูลหลายแหล่ง (wiki, ตั๋ว, PDF, ฐานข้อมูล) ไว้ในผู้ช่วยตัวเดียว
• ตัดสินใจทางสถาปัตยกรรมเกี่ยวกับความสามารถในการปรับขนาด การแคช และเวลาในการตอบสนอง

ในหน่วยก่อนหน้านี้ เราได้เรียนรู้ส่วนต่างๆ ทีละส่วน: การฝัง ฐานข้อมูลเวกเตอร์ การแยกส่วน การดึงข้อมูล ตอนนี้เรามารวมสิ่งเหล่านี้เข้าด้วยกันและสร้างสถาปัตยกรรมแบบ end-to-end ของผู้ช่วยที่พูดคุยกับข้อมูลบริษัทของคุณเอง เป้าหมายคือให้พนักงานถามว่า “นโยบายการลาของเราเป็นอย่างไร” ระบบที่ผู้คนสามารถถามคำถาม คำตอบจะขึ้นอยู่กับเอกสารภายในจริง การอ้างอิง และรวมแหล่งข้อมูลหลายแหล่ง หน่วยนี้จะประมวลผลสถาปัตยกรรมทั้งหมด กระแสข้อมูล และการตัดสินใจระดับการผลิต

ส่วนประกอบแบบครบวงจร

ผู้ช่วย RAG ขององค์กรประกอบด้วยสองสายแยกกัน บรรทัดการจัดทำดัชนี (ออฟไลน์) เตรียมข้อมูล บรรทัดแบบสอบถาม (ออนไลน์) ตอบคำถาม

ส่วนประกอบของเส้นดัชนี:

1. ตัวเชื่อมต่อ: ตัวเชื่อมต่อที่ดึงข้อมูลจากแหล่งที่มา เช่น วิกิ ระบบตั๋ว ที่เก็บไฟล์ ฐานข้อมูล อีเมล
2. การทำให้เป็นมาตรฐาน: การแปลงรูปแบบต่างๆ (PDF, HTML, DOCX) เพื่อล้างข้อความ การทำความสะอาดส่วนหัว/ส่วนท้าย
3. การแยกส่วน + ข้อมูลเมตา: การแบ่งส่วนและการแท็ก (แหล่งที่มา วันที่ อำนาจ)
4. การฝัง + การโหลด: การเขียนเวกเตอร์และข้อมูลเมตาลงในฐานข้อมูลเวกเตอร์

ส่วนประกอบไปป์ไลน์แบบสอบถาม:

1. การประมวลผลแบบสอบถามล่วงหน้า: การเขียนใหม่ การกระจายอำนาจ
2. การดึงข้อมูล: การค้นหาแบบไฮบริด + ตัวกรองข้อมูลเมตา + การจัดอันดับใหม่
3. การสร้างพร้อมท์: การวางบริบท + คำถาม + คำแนะนำลงในเทมเพลต
4. การสร้าง: คำตอบที่ต่อสายดิน (ตามบริบท) จากโมเดล + แหล่งที่มา
5. หลังการประมวลผล: การจัดรูปแบบการอ้างอิง การตรวจสอบความปลอดภัย การบันทึก

เคล็ดลับ: แยกบรรทัดการจัดทำดัชนีออกจากบรรทัดการสืบค้นทางกายภาพ การจัดทำดัชนีช้าและเป็นงวด (ทำงานเป็นชุดในชั่วข้ามคืน) สายการสอบสวนควรเบาและทันที การผสมทั้งสองบรรทัดจะทำให้การประมวลผลหนักในขณะที่ผู้ใช้รอ

การแสดงภาพการไหลของข้อมูล

[จัดทำดัชนี - ออฟไลน์]ทรัพยากร → ทำให้เป็นมาตรฐาน → Chunk+ข้อมูลเมตา → ฝัง → Vector DB (wiki, ตั๋ว, PDF, DB)[QUERY - ออนไลน์] คำถามของผู้ใช้ → การประมวลผลล่วงหน้า → การดึงข้อมูล (ไฮบริด + ตัวกรอง + จัดอันดับใหม่) → พรอมต์ (บริบท + คำถาม + คำแนะนำ) → โมเดล → คำตอบ + แหล่งที่มา → ผู้ใช้

การรวมข้อมูลหลายแหล่ง

ในบริษัทที่แท้จริง คำตอบไม่ได้หยุดอยู่เพียงที่เดียว “จะคืนเงินให้กับลูกค้าได้อย่างไร” คำตอบสำหรับคำถามสามารถพบได้ทั้งในบทความช่วยเหลือ (ขั้นตอน) ในประวัติตั๋ว (ตัวอย่างจริง) และใน PDF นโยบาย (กฎ) ผู้ช่วยควรค้นหาทั้งหมดในกลุ่มเดียว

จุดสำคัญ: เมื่อรวมทรัพยากรไว้ในที่เก็บเวกเตอร์เดียว แต่ละส่วนจะต้องมีข้อมูลเมตา `source_tour` ดังนั้นคุณจึงสามารถค้นหาทั้งหมดและกรองได้หากจำเป็น เช่น "นำนโยบายอย่างเป็นทางการเท่านั้น" นอกจากนี้ แหล่งข้อมูลที่ต่างกันก็มีระดับความน่าเชื่อถือที่แตกต่างกัน: นโยบายอย่างเป็นทางการ > บทความช่วยเหลือ > บันทึกตั๋วของพนักงาน คุณสามารถระบุลำดับความสำคัญนี้ได้ในการจัดอันดับใหม่หรือพร้อมท์

แหล่งที่มา

ประเภทเนื้อหา

ไว้วางใจ

ความถี่ในการอัพเดต

นโยบาย PDF

กฎอย่างเป็นทางการ

สูง

รายเดือน

บทความช่วยเหลือ

ขั้นตอน

สูงปานกลาง

รายสัปดาห์

ประวัติตั๋ว

ตัวอย่างจริง

ปานกลาง

ต่อเนื่อง

วิกิ

โน้ตผสม/ปัจจุบัน

ตัวแปร

ต่อเนื่อง

ความสามารถในการปรับขนาด แคช และเวลาในการตอบสนอง

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

หลักทั่วไปในด้านต้นทุน: ขั้นตอนที่แพงที่สุดมักจะเป็นจำนวนโทเค็นที่จะไปยังโมเดลที่ใหญ่กว่า ดังนั้นการลดบริบทลงเหลือ 4 ส่วนที่ดีโดยการจัดอันดับใหม่ทำให้ทั้งคุณภาพและต้นทุนดีขึ้น การออกแบบทั่วไปคือการใช้แบบจำลองที่เล็กกว่า/เร็วกว่าสำหรับการจำแนกประเภทหรือการกำหนดเส้นทางอย่างง่าย และแบบจำลองที่ทรงพลังกว่าสำหรับคำตอบสุดท้าย (เช่น claude-opus-4-8)

ข้อควรระวัง: อย่าตั้งค่าการจัดทำดัชนีเป็น "ทำครั้งเดียว ลืมมันไปซะ" เอกสารมีการเปลี่ยนแปลง ลบ เพิ่ม สร้างกลยุทธ์การจัดทำดัชนีใหม่: ตรวจจับเอกสารที่เปลี่ยนแปลงและประมวลผลใหม่เฉพาะเอกสารเหล่านั้น ดัชนีเก่าสร้างคำตอบที่ปรากฏเป็นปัจจุบันแต่ผิด

สถาปัตยกรรมที่อ่อนแอ / สถาปัตยกรรมที่แข็งแกร่ง

อ่อนแอ (สคริปต์เดียว ทุกอย่างผสมกัน):

เมื่อผู้ใช้ถาม: อ่านเอกสารในขณะนั้น ฉีก ฝัง ค้นหา และตอบ # ปัญหา: การจัดทำดัชนีทั้งหมดทำซ้ำสำหรับแต่ละคำถาม วินาทีแห่งความล่าช้า # ไม่มีการแยกแหล่งที่มา ไม่มีตัวกรอง ไม่มีการรีเฟรช

ทรงพลัง (แยกไปป์ + ข้อมูลเมตา + แคช + สตรีมมิ่ง):

การจัดทำดัชนี: แบทช์ทำงานในเวลากลางคืน รีเฟรชเอกสารที่เปลี่ยนแปลง ข้อความค้นหา: เส้นน้ำหนักเบา — การประมวลผลล่วงหน้า → การดึงข้อมูลแบบไฮบริด+ตัวกรอง → จัดอันดับใหม่ → พรอมต์ → โมเดล (สตรีมมิ่ง) → การอ้างอิง → บันทึก คำถามที่พบบ่อยและแหล่งที่มาจะถูกแคชไว้

มินิเคสสามอัน

กรณีที่ 1 — เส้นสับสน ดีเลย์หนัก สตาร์ทอัพเขียนสคริปต์ที่ประมวลผล PDF ซ้ำกับคำถามแต่ละข้อ แต่ละคำตอบใช้เวลาเฉลี่ย 11 วินาที เมื่อแยกบรรทัดการจัดทำดัชนีและข้อมูลถูกถ่ายโอนไปยังร้านค้าเวกเตอร์ก่อนหน้านี้ เวลาในการสืบค้นลดลงเหลือ 1.3 วินาที และเมื่อมีการสตรีม "คำแรก" จะปรากฏขึ้นใน 400 มิลลิวินาที

กรณีที่ 2 — มีทรัพยากรมากเกินไป มีลำดับความสำคัญไม่ถูกต้อง ผู้ช่วยฝ่ายสนับสนุนให้น้ำหนักเท่ากันกับนโยบาย PDF และบันทึกตั๋วเก่า บางครั้งแบบจำลองนี้แสดงการให้คะแนนที่ไม่ถูกต้องของพนักงานเมื่อสองปีที่แล้วตามกฎอย่างเป็นทางการ เมื่อเพิ่มข้อมูลเมตาของ source_tour และคำสั่ง "พิจารณานโยบายอย่างเป็นทางการในกรณีที่มีข้อขัดแย้ง" ลงในพรอมต์ ข้อผิดพลาดที่มีลำดับความสำคัญลวงก็ลดลง 89%

กรณีที่ 3 — ดัชนีเก่า ผู้ช่วยฝ่ายทรัพยากรบุคคลกำลังทำงานกับดัชนีที่ไม่ได้อัปเดตเป็นเวลา 3 เดือน นโยบายการลาเปลี่ยนไปแต่ผู้ช่วยก็บอกแต่วันเก่าๆ เมื่อมีการติดตั้งการรีเฟรชรายวัน ซึ่งตรวจพบไฟล์ที่เปลี่ยนแปลง อัตราการตอบสนองปัจจุบันเพิ่มขึ้นจาก 70% เป็น 99%

ข้อผิดพลาดทั่วไป

• การผสมการจัดทำดัชนีและบรรทัดการสืบค้น: การประมวลผลจำนวนมากเสร็จสิ้นในขณะที่ผู้ใช้รอ ความล่าช้าระเบิด
• ไม่ใส่ประเภทแหล่งที่มาในข้อมูลเมตา: ไม่มีการจัดลำดับความสำคัญและการกรอง แหล่งข่าวที่ไม่น่าเชื่อถือดูเหมือนเป็นทางการ
• ไม่สร้างกลยุทธ์การรีเฟรช: ดัชนีเริ่มเก่า คำตอบที่ผิดซึ่งปรากฏอยู่ในปัจจุบันถูกสร้างขึ้น
• ข้ามการสตรีม: ผู้ใช้ดูหน้าจอว่าง การรับรู้ความล่าช้าจะสูง
• การใช้แบบจำลองที่ใหญ่ที่สุดในแต่ละขั้นตอน: ต้นทุนเพิ่มขึ้นโดยไม่จำเป็น ปล่อยพวงมาลัยไปที่รุ่นเล็ก

โดยสรุป

• ผู้ช่วย RAG ขององค์กรประกอบด้วยสองบรรทัดแยกกัน: การทำดัชนีออฟไลน์และการสืบค้นออนไลน์ แยกพวกเขาออกจากกันทางร่างกาย
• การทำดัชนี = ตัวเชื่อมต่อ + ทำให้เป็นมาตรฐาน + กลุ่ม/ข้อมูลเมตา + ฝัง/อัปโหลด; แบบสอบถาม = ก่อนกระบวนการ + การดึงข้อมูล + พรอมต์ + สร้าง + หลังกระบวนการ
• ข้อมูลหลายแหล่งจะรวมกันเป็นพื้นที่เก็บข้อมูลเดียว แต่ข้อมูลเมตา source_type และลำดับความสำคัญของความน่าเชื่อถือจะยังคงอยู่
• การสตรีมและแคชสำหรับเวลาแฝง การควบคุมบริบท และการเลือกโมเดลสำหรับต้นทุนเป็นสิ่งสำคัญ
• หากไม่มีการจัดทำดัชนีใหม่ ดัชนีจะเก่า ประมวลผลการเปลี่ยนแปลงเอกสารซ้ำอย่างสม่ำเสมอ

งานสมัคร

วาดแผนผังสถาปัตยกรรมของผู้ช่วยสำหรับทีมของคุณเอง (1) ระบุแหล่งข้อมูลจริงอย่างน้อยสามแหล่ง และจดความต้องการตัวเชื่อมต่อ ความถี่ในการอัปเดต และระดับความน่าเชื่อถือสำหรับแต่ละแหล่งข้อมูล (2) วาดบรรทัดการจัดทำดัชนีและแบบสอบถามแยกกันด้วยแผนภาพลูกศรแบบกล่อง (3) “ฉันจะลดเวลาแฝงและต้นทุนในผู้ช่วยนี้ได้ที่ไหน” เขียนการตัดสินใจที่เป็นรูปธรรมอย่างน้อยสองครั้งสำหรับคำถาม (4) อธิบายกลยุทธ์การรีเฟรชของคุณในหนึ่งประโยค: ทรัพยากรใดที่จะถูกจัดทำดัชนีใหม่และบ่อยแค่ไหน?

รายการตรวจสอบ

• [ ] ฉันสามารถวาดบรรทัดการจัดทำดัชนีและแบบสอบถามแยกกันและมีส่วนประกอบที่ถูกต้องได้
• [ ] ฉันสามารถรวมข้อมูลหลายแหล่งเข้ากับ source_type และลำดับความสำคัญของความน่าเชื่อถือได้
• [ ] ฉันสามารถตัดสินใจเรื่องการสตรีม/แคชสำหรับเวลาแฝงและการเลือกรุ่นตามต้นทุนได้
• [ ] ฉันรู้ว่าเหตุใดกลยุทธ์การจัดทำดัชนีใหม่จึงมีความสำคัญ
• [ ] ฉันจำไว้ว่าขั้นตอนที่แพงที่สุดในสถาปัตยกรรมของฉันมักจะเป็นโทเค็นที่ส่งไปยังโมเดลที่ใหญ่กว่า