AI การสนทนาได้รับการพัฒนาไปไกลในช่วงไม่กี่ปีที่ผ่านมา เนื่องจากการพัฒนาอย่างรวดเร็วใน generative AI โดยเฉพาะอย่างยิ่งการปรับปรุงประสิทธิภาพของโมเดลภาษาขนาดใหญ่ (LLM) ที่แนะนำโดยเทคนิคการฝึกอบรม เช่น การปรับแต่งคำสั่งอย่างละเอียด และการเสริมการเรียนรู้จากความคิดเห็นของมนุษย์ เมื่อได้รับแจ้งอย่างถูกต้อง โมเดลเหล่านี้สามารถดำเนินการสนทนาที่สอดคล้องกันโดยไม่มีข้อมูลการฝึกอบรมเฉพาะงาน อย่างไรก็ตาม พวกเขาไม่สามารถสรุปคำถามเฉพาะขององค์กรได้ดีนัก เนื่องจากในการหาคำตอบ พวกเขาอาศัยข้อมูลสาธารณะที่พวกเขาเปิดเผยระหว่างก่อนการฝึกอบรม ข้อมูลดังกล่าวมักจะขาดความรู้เฉพาะทางที่มีอยู่ในเอกสารภายในที่มีอยู่ในธุรกิจยุคใหม่ ซึ่งโดยทั่วไปจำเป็นสำหรับการได้รับคำตอบที่ถูกต้องในขอบเขตต่างๆ เช่น การวิจัยทางเภสัชกรรม การสืบสวนทางการเงิน และการสนับสนุนลูกค้า
ในการสร้างผู้ช่วย AI ที่สามารถสนทนาโดยอาศัยความรู้เฉพาะทางขององค์กร เราจำเป็นต้องเชื่อมต่อ LLM ที่ทรงพลังแต่ทั่วไปเหล่านี้เข้ากับฐานความรู้ภายในของเอกสาร วิธีการเพิ่มคุณค่าบริบทการสร้าง LLM ด้วยข้อมูลที่ดึงมาจากแหล่งข้อมูลภายในของคุณนี้เรียกว่าการเรียกข้อมูล Augmented Generation (RAG) และสร้างผู้ช่วยที่มีเฉพาะโดเมนและน่าเชื่อถือมากขึ้น ดังที่แสดงโดย การดึงข้อมูล- Augmented Generation สำหรับงาน NLP ที่เน้นความรู้. แรงผลักดันอีกประการหนึ่งที่อยู่เบื้องหลังความนิยมของ RAG คือความง่ายในการใช้งานและการมีอยู่ของโซลูชันการค้นหาเวกเตอร์ที่ครบถ้วน เช่น ที่นำเสนอโดย อเมซอน เคนดรา (ดู Amazon Kendra เปิดตัว API การดึงข้อมูล) and บริการ Amazon OpenSearch (ดู การค้นหา k-Nearest Neighbor (k-NN) ใน Amazon OpenSearch Service), ท่ามกลางคนอื่น ๆ.
อย่างไรก็ตาม รูปแบบการออกแบบ RAG ยอดนิยมพร้อมการค้นหาเชิงความหมายไม่สามารถตอบคำถามทุกประเภทที่เป็นไปได้ในเอกสาร โดยเฉพาะอย่างยิ่งสำหรับคำถามที่ต้องใช้เหตุผลเชิงวิเคราะห์ในเอกสารหลายฉบับ ตัวอย่างเช่น จินตนาการว่าคุณกำลังวางแผนกลยุทธ์ของบริษัทการลงทุนในปีหน้า ขั้นตอนสำคัญประการหนึ่งคือการวิเคราะห์และเปรียบเทียบผลลัพธ์ทางการเงินและความเสี่ยงที่อาจเกิดขึ้นของบริษัทผู้สมัคร งานนี้เกี่ยวข้องกับการตอบคำถามการใช้เหตุผลเชิงวิเคราะห์ ตัวอย่างเช่น ข้อความค้นหา "Give me the 5 top companies with the maximum Revenue in the 2 years andระบุความเสี่ยงหลัก" ต้องใช้หลายขั้นตอนในการให้เหตุผล ซึ่งบางขั้นตอนสามารถใช้การเรียกข้อมูลการค้นหาเชิงความหมาย ในขณะที่คำอื่นๆ ต้องใช้ความสามารถในการวิเคราะห์
ในโพสต์นี้ เราจะแสดงวิธีการออกแบบผู้ช่วยเอกสารอัจฉริยะที่สามารถตอบคำถามเชิงวิเคราะห์และการใช้เหตุผลแบบหลายขั้นตอนได้ในสามส่วน ในส่วนที่ 1 เราจะตรวจสอบรูปแบบการออกแบบ RAG และข้อจำกัดของคำถามเชิงวิเคราะห์ จากนั้นเราจะแนะนำให้คุณรู้จักกับสถาปัตยกรรมที่หลากหลายมากขึ้นซึ่งเอาชนะข้อจำกัดเหล่านี้ ส่วนที่ 2 ช่วยให้คุณเจาะลึกลงไปในไปป์ไลน์การแยกเอนทิตีที่ใช้ในการเตรียมข้อมูลที่มีโครงสร้าง ซึ่งเป็นองค์ประกอบสำคัญสำหรับการตอบคำถามเชิงวิเคราะห์ ส่วนที่ 3 จะอธิบายวิธีการใช้งานให้คุณทราบ อเมซอน เบดร็อค LLM เพื่อสืบค้นข้อมูลนั้นและสร้างตัวแทน LLM ที่ปรับปรุง RAG ด้วยความสามารถในการวิเคราะห์ ดังนั้นจึงช่วยให้คุณสร้างผู้ช่วยเอกสารอัจฉริยะที่สามารถตอบคำถามเฉพาะโดเมนที่ซับซ้อนในเอกสารหลายฉบับ
ส่วนที่ 1: ข้อจำกัดของ RAG และภาพรวมโซลูชัน
ในส่วนนี้ เราจะตรวจสอบรูปแบบการออกแบบ RAG และหารือเกี่ยวกับข้อจำกัดของคำถามเชิงวิเคราะห์ นอกจากนี้เรายังนำเสนอสถาปัตยกรรมที่หลากหลายมากขึ้นซึ่งเอาชนะข้อจำกัดเหล่านี้
ภาพรวมของ RAG
โซลูชั่น RAG ได้รับแรงบันดาลใจจาก การเรียนรู้การเป็นตัวแทน และ การค้นหาความหมาย แนวคิดที่ค่อยๆ นำมาใช้ในปัญหาการจัดอันดับ (เช่น การแนะนำและการค้นหา) และงานการประมวลผลภาษาธรรมชาติ (NLP) ตั้งแต่ปี 2010
แนวทางที่นิยมใช้กันในปัจจุบันประกอบด้วยสามขั้นตอน:
- งานการประมวลผลแบบออฟไลน์เป็นชุดนำเข้าเอกสารจากฐานความรู้อินพุต แบ่งออกเป็นส่วนๆ สร้างการฝังสำหรับแต่ละส่วนเพื่อแสดงความหมายโดยใช้โมเดลการฝังที่ได้รับการฝึกอบรมล่วงหน้า เช่น อเมซอนไททัน การฝังโมเดล จากนั้นใช้การฝังเหล่านี้เป็นอินพุตเพื่อสร้างดัชนีการค้นหาความหมาย
- เมื่อตอบคำถามใหม่แบบเรียลไทม์ คำถามที่ป้อนจะถูกแปลงเป็นการฝัง ซึ่งใช้เพื่อค้นหาและแยกส่วนเอกสารที่คล้ายกันมากที่สุดโดยใช้ตัวชี้วัดความคล้ายคลึงกัน เช่น ความคล้ายคลึงของโคไซน์ และอัลกอริธึมเพื่อนบ้านที่ใกล้ที่สุดโดยประมาณ ความแม่นยำในการค้นหาสามารถปรับปรุงได้ด้วยการกรองข้อมูลเมตา
- พรอมต์ถูกสร้างขึ้นจากการต่อข้อความระบบเข้ากับบริบทที่ประกอบขึ้นจากส่วนเอกสารที่เกี่ยวข้องซึ่งแยกออกมาในขั้นตอนที่ 2 และคำถามที่ป้อนเข้าไปเอง จากนั้นระบบจะนำเสนอพร้อมท์นี้ให้กับโมเดล LLM เพื่อสร้างคำตอบสุดท้ายสำหรับคำถามจากบริบท
ด้วยโมเดลการฝังพื้นฐานที่ถูกต้อง สามารถสร้างการแสดงความหมายที่ถูกต้องของชิ้นส่วนเอกสารอินพุตและคำถามอินพุต และโมดูลการค้นหาความหมายที่มีประสิทธิภาพ โซลูชันนี้สามารถตอบคำถามที่ต้องการดึงข้อมูลที่มีอยู่ในฐานข้อมูลของเอกสารได้ ตัวอย่างเช่น หากคุณมีบริการหรือผลิตภัณฑ์ คุณสามารถเริ่มต้นด้วยการจัดทำดัชนีส่วนคำถามที่พบบ่อยหรือเอกสารประกอบ และทำให้ AI การสนทนาเบื้องต้นได้รับการปรับแต่งให้เหมาะกับข้อเสนอเฉพาะของคุณ
ข้อจำกัดของ RAG ตามการค้นหาความหมาย
แม้ว่า RAG จะเป็นองค์ประกอบสำคัญในผู้ช่วย AI เฉพาะโดเมนสมัยใหม่ และเป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับการสร้าง AI การสนทนารอบฐานความรู้เฉพาะทาง แต่ก็ไม่สามารถตอบคำถามที่ต้องใช้การสแกน การเปรียบเทียบ และการให้เหตุผลในเอกสารทั้งหมดในฐานความรู้ของคุณ พร้อมกัน โดยเฉพาะอย่างยิ่งเมื่อการเสริมขึ้นอยู่กับการค้นหาความหมายเพียงอย่างเดียว
เพื่อให้เข้าใจถึงข้อจำกัดเหล่านี้ เราจะมาพิจารณาตัวอย่างการตัดสินใจว่าจะลงทุนที่ไหนตามรายงานทางการเงินอีกครั้ง หากเราใช้ RAG เพื่อพูดคุยกับรายงานเหล่านี้ เราอาจถามคำถามเช่น "บริษัท X ต้องเผชิญกับความเสี่ยงอะไรบ้างในปี 2022" หรือ "รายได้สุทธิของบริษัท Y ในปี 2022 เป็นเท่าใด" สำหรับแต่ละคำถามเหล่านี้ เวกเตอร์การฝังที่สอดคล้องกัน ซึ่งเข้ารหัสความหมายเชิงความหมายของคำถาม จะถูกใช้เพื่อดึงข้อมูลชิ้นเอกสารที่คล้ายกันเชิงความหมายระดับบนสุดที่มีอยู่ในดัชนีการค้นหา โดยทั่วไปจะสำเร็จได้โดยใช้โซลูชันเพื่อนบ้านที่ใกล้ที่สุดโดยประมาณ เช่น FAISS, NMSLIB, pgvector หรืออื่นๆซึ่งมุ่งมั่นที่จะสร้างสมดุลระหว่างความเร็วในการดึงข้อมูลและการเรียกคืนเพื่อให้ได้ประสิทธิภาพแบบเรียลไทม์ในขณะที่ยังคงความแม่นยำที่น่าพอใจ
อย่างไรก็ตาม วิธีการก่อนหน้านี้ไม่สามารถตอบคำถามเชิงวิเคราะห์ได้อย่างแม่นยำในเอกสารทั้งหมด เช่น "บริษัท 5 อันดับแรกที่มีรายได้สุทธิสูงสุดในปี 2022 คือบริษัทใดบ้าง"
เนื่องจากการค้นหาเชิงความหมายพยายามค้นหา K ชิ้นเอกสารที่คล้ายกันมากที่สุดกับคำถามอินพุต แต่เนื่องจากไม่มีเอกสารใดที่มีสรุปรายได้ที่ครอบคลุม จึงส่งคืนเอกสารบางส่วนที่มีการกล่าวถึง "รายได้สุทธิ" และอาจเป็น "2022" เท่านั้น โดยไม่ปฏิบัติตามเงื่อนไขที่สำคัญในการมุ่งเน้นไปที่บริษัทที่มีรายได้สูงสุด หากเรานำเสนอผลการดึงข้อมูลเหล่านี้แก่ LLM เพื่อเป็นบริบทในการตอบคำถามที่ป้อนเข้า อาจกำหนดคำตอบที่ทำให้เข้าใจผิดหรือปฏิเสธที่จะตอบ เนื่องจากข้อมูลที่ถูกต้องที่จำเป็นขาดหายไป
ข้อจำกัดเหล่านี้เกิดขึ้นจากการออกแบบ เนื่องจากการค้นหาเชิงความหมายไม่ได้ทำการสแกนเวกเตอร์ที่ฝังทั้งหมดอย่างละเอียดเพื่อค้นหาเอกสารที่เกี่ยวข้อง แต่จะใช้วิธีการใกล้เคียงที่ใกล้ที่สุดโดยประมาณเพื่อรักษาความเร็วการดึงข้อมูลที่เหมาะสม กลยุทธ์สำคัญสำหรับประสิทธิภาพในวิธีการเหล่านี้คือการแบ่งส่วนพื้นที่ฝังออกเป็นกลุ่มในระหว่างการจัดทำดัชนี ซึ่งช่วยให้ระบุได้อย่างรวดเร็วว่ากลุ่มใดอาจมีการฝังที่เกี่ยวข้องระหว่างการดึงข้อมูล โดยไม่จำเป็นต้องเปรียบเทียบแบบคู่ นอกจากนี้ แม้แต่เทคนิคเพื่อนบ้านที่ใกล้ที่สุดแบบดั้งเดิมอย่าง KNN ซึ่งสแกนเอกสารทั้งหมด จะคำนวณเฉพาะการวัดระยะทางพื้นฐานเท่านั้น และไม่เหมาะสำหรับการเปรียบเทียบที่ซับซ้อนซึ่งจำเป็นสำหรับการให้เหตุผลเชิงวิเคราะห์ ดังนั้น RAG ที่มีการค้นหาเชิงความหมายจึงไม่ได้รับการออกแบบมาเพื่อตอบคำถามที่เกี่ยวข้องกับการใช้เหตุผลเชิงวิเคราะห์ในเอกสารทั้งหมด
เพื่อเอาชนะข้อจำกัดเหล่านี้ เราขอเสนอโซลูชันที่รวม RAG เข้ากับการแยกข้อมูลเมตาและเอนทิตี การสอบถาม SQL และตัวแทน LLM ตามที่อธิบายไว้ในส่วนต่อไปนี้
เอาชนะข้อจำกัดของ RAG ด้วยเอเจนต์ข้อมูลเมตา, SQL และ LLM
เรามาตรวจสอบคำถามที่ RAG ล้มเหลวอย่างลึกซึ้งยิ่งขึ้น เพื่อที่เราจะได้สามารถย้อนกลับไปหาเหตุผลที่จำเป็นในการตอบคำถามได้อย่างมีประสิทธิภาพ การวิเคราะห์นี้ควรชี้ให้เราทราบถึงแนวทางที่ถูกต้องซึ่งสามารถเสริม RAG ในโซลูชันโดยรวมได้
พิจารณาคำถาม: “5 อันดับบริษัทที่มีรายได้สูงสุดในปี 2022 มีอะไรบ้าง”
เพื่อให้สามารถตอบคำถามนี้ได้ เราจะต้อง:
- ระบุรายได้ของแต่ละบริษัท
- กรองลงเพื่อเก็บรายได้ปี 2022 ไว้แต่ละรายการ
- จัดเรียงรายได้ตามลำดับจากมากไปน้อย
- แบ่งรายได้ 5 อันดับแรกควบคู่ไปกับชื่อบริษัท
โดยทั่วไปแล้ว การดำเนินการวิเคราะห์เหล่านี้จะดำเนินการกับข้อมูลที่มีโครงสร้าง โดยใช้เครื่องมือ เช่น แพนด้าหรือกลไก SQL หากเรามีสิทธิ์เข้าถึงตาราง SQL ที่มีคอลัมน์ต่างๆ company
, revenue
และ year
เราสามารถตอบคำถามของเราได้อย่างง่ายดายด้วยการเรียกใช้แบบสอบถาม SQL คล้ายกับตัวอย่างต่อไปนี้:
SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;
การจัดเก็บข้อมูลเมตาที่มีโครงสร้างในตาราง SQL ที่มีข้อมูลเกี่ยวกับเอนทิตีที่เกี่ยวข้องทำให้คุณสามารถตอบคำถามเชิงวิเคราะห์ได้หลายประเภทโดยการเขียนแบบสอบถาม SQL ที่ถูกต้อง นี่คือเหตุผลที่เราเสริม RAG ในโซลูชันของเราด้วยโมดูลการสืบค้น SQL แบบเรียลไทม์เทียบกับตาราง SQL ซึ่งบรรจุโดยข้อมูลเมตาที่แยกออกมาในกระบวนการออฟไลน์
แต่เราจะนำไปใช้และบูรณาการแนวทางนี้กับ AI การสนทนาแบบ LLM ได้อย่างไร
มีสามขั้นตอนในการเพิ่มการใช้เหตุผลเชิงวิเคราะห์ SQL:
- การแยกข้อมูลเมตา – แยกข้อมูลเมตาจากเอกสารที่ไม่มีโครงสร้างลงในตาราง SQL
- ข้อความเป็น SQL – กำหนดคำสั่ง SQL จากคำถามที่ป้อนเข้าอย่างแม่นยำโดยใช้ LLM
- การเลือกเครื่องมือ – ระบุว่าต้องตอบคำถามโดยใช้ RAG หรือการสืบค้น SQL หรือไม่
เพื่อดำเนินการตามขั้นตอนเหล่านี้ ขั้นแรกเรารับรู้ว่าการแยกข้อมูลจากเอกสารที่ไม่มีโครงสร้างเป็นงาน NLP แบบดั้งเดิมที่ LLM แสดงให้เห็นถึงคำมั่นสัญญาในการบรรลุความแม่นยำสูงผ่านการเรียนรู้แบบ Zero-shot หรือไม่กี่ครั้ง ประการที่สอง ความสามารถของโมเดลเหล่านี้ในการสร้างคำสั่ง SQL จากภาษาธรรมชาติ ได้รับการพิสูจน์มานานหลายปี ดังที่เห็นใน เปิดตัว 2020 of Amazon QuickSight Q. สุดท้ายนี้ การเลือกเครื่องมือที่เหมาะสมสำหรับคำถามเฉพาะโดยอัตโนมัติจะช่วยเพิ่มประสบการณ์ผู้ใช้และช่วยให้สามารถตอบคำถามที่ซับซ้อนโดยใช้เหตุผลหลายขั้นตอนได้ เพื่อใช้งานคุณสมบัตินี้ เราจะเจาะลึกตัวแทน LLM ในส่วนต่อๆ ไป
โดยสรุป โซลูชันที่เราเสนอประกอบด้วยองค์ประกอบหลักดังต่อไปนี้:
- การเรียกค้นความหมายเพื่อเพิ่มบริบทการสร้าง
- การแยกข้อมูลเมตาที่มีโครงสร้างและการสืบค้นด้วย SQL
- ตัวแทนที่สามารถใช้เครื่องมือที่เหมาะสมในการตอบคำถาม
ภาพรวมโซลูชัน
แผนภาพต่อไปนี้แสดงสถาปัตยกรรมที่เรียบง่ายของโซลูชัน ช่วยให้คุณระบุและเข้าใจบทบาทของส่วนประกอบหลักและวิธีที่ส่วนประกอบเหล่านี้โต้ตอบเพื่อปรับใช้พฤติกรรมผู้ช่วย LLM เต็มรูปแบบ การกำหนดหมายเลขจะสอดคล้องกับลำดับการดำเนินการเมื่อใช้โซลูชันนี้
ในทางปฏิบัติ เราได้นำโซลูชันนี้ไปใช้ตามที่ระบุไว้ในสถาปัตยกรรมโดยละเอียดต่อไปนี้
สำหรับสถาปัตยกรรมนี้ เราขอเสนอการดำเนินการบน GitHubโดยมีส่วนประกอบที่เชื่อมต่อกันอย่างหลวมๆ โดยที่แบ็กเอนด์ (5), ไปป์ไลน์ข้อมูล (1, 2, 3) และส่วนหน้า (4) สามารถพัฒนาแยกกันได้ นี่คือการลดความซับซ้อนของการทำงานร่วมกันข้ามความสามารถเมื่อปรับแต่งและปรับปรุงโซลูชันสำหรับการผลิต
ปรับใช้โซลูชัน
หากต้องการติดตั้งโซลูชันนี้ในบัญชี AWS ของคุณ ให้ทำตามขั้นตอนต่อไปนี้:
- โคลน พื้นที่เก็บข้อมูลบน GitHub.
- ติดตั้งแบ็กเอนด์ ชุดพัฒนา AWS Cloud (AWS ซีดีเค) app:
- เปิด
backend
โฟลเดอร์ - วิ่ง
npm install
เพื่อติดตั้งการพึ่งพา - หากคุณไม่เคยใช้ AWS CDK ในบัญชีปัจจุบันและภูมิภาค ให้เรียกใช้ ความร่วมมือ กับ
npx cdk bootstrap
. - วิ่ง
npx cdk deploy
เพื่อปรับใช้สแต็ก
- เปิด
- ทางเลือก รันไฟล์
streamlit-ui
ดังต่อไปนี้:- เราขอแนะนำให้โคลนที่เก็บนี้ลงในไฟล์ สตูดิโอ Amazon SageMaker สิ่งแวดล้อม. สำหรับข้อมูลเพิ่มเติม โปรดดูที่ เริ่มต้นใช้งานโดเมน Amazon SageMaker โดยใช้การตั้งค่าด่วน.
- ภายใน
frontend/streamlit-ui
โฟลเดอร์เรียกใช้bash run-streamlit-ui.sh
. - เลือกลิงก์ที่มีรูปแบบต่อไปนี้เพื่อเปิดการสาธิต:
https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/
.
- ในที่สุดคุณสามารถเรียกใช้ อเมซอน SageMaker ไปป์ไลน์ที่กำหนดไว้ใน
data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb
notebook เพื่อประมวลผลเอกสาร PDF อินพุตและเตรียมตาราง SQL และดัชนีการค้นหาความหมายที่ใช้โดยผู้ช่วย LLM
ในส่วนที่เหลือของโพสต์นี้ เรามุ่งเน้นไปที่การอธิบายองค์ประกอบที่สำคัญที่สุดและตัวเลือกการออกแบบ เพื่อหวังว่าจะเป็นแรงบันดาลใจให้คุณในการออกแบบผู้ช่วย AI ของคุณเองบนฐานความรู้ภายใน เราถือว่าองค์ประกอบที่ 1 และ 4 นั้นเข้าใจได้ง่าย และมุ่งเน้นไปที่องค์ประกอบหลักที่ 2, 3 และ 5
ส่วนที่ 2: ไปป์ไลน์การแยกเอนทิตี
ในส่วนนี้ เราจะเจาะลึกไปป์ไลน์การแยกเอนทิตีที่ใช้ในการเตรียมข้อมูลที่มีโครงสร้าง ซึ่งเป็นองค์ประกอบสำคัญสำหรับการตอบคำถามเชิงวิเคราะห์
การแยกข้อความ
โดยทั่วไปเอกสารจะถูกจัดเก็บในรูปแบบ PDF หรือเป็นรูปภาพที่สแกน อาจประกอบด้วยเค้าโครงย่อหน้าธรรมดาหรือตารางที่ซับซ้อน และมีข้อความดิจิทัลหรือข้อความที่เขียนด้วยลายมือ เพื่อดึงข้อมูลอย่างถูกต้อง เราจำเป็นต้องแปลงเอกสารดิบเหล่านี้เป็นข้อความธรรมดา โดยที่ยังคงโครงสร้างดั้งเดิมไว้ คุณสามารถใช้ได้ Amazon Textซึ่งเป็นบริการแมชชีนเลิร์นนิง (ML) ที่ให้บริการ API ที่สมบูรณ์สำหรับข้อความ ตาราง และการแยกแบบฟอร์มจากอินพุตดิจิทัลและอินพุตที่เขียนด้วยลายมือ
ในองค์ประกอบที่ 2 เราแยกข้อความและตารางดังนี้:
- สำหรับแต่ละเอกสาร เราเรียก Amazon Textract เพื่อแยกข้อความและตาราง
- เราใช้สิ่งต่อไปนี้ สคริปต์ Python เพื่อสร้างตารางใหม่เป็น DataFrames ของแพนด้า
- เรารวมผลลัพธ์ไว้ในเอกสารเดียวและแทรกตารางเป็นมาร์กดาวน์
กระบวนการนี้สรุปไว้ในแผนภาพการไหลต่อไปนี้ และแสดงให้เห็นอย่างเป็นรูปธรรมใน notebooks/03-pdf-document-processing.ipynb
.
การแยกเอนทิตีและการสืบค้นโดยใช้ LLM
เพื่อตอบคำถามเชิงวิเคราะห์อย่างมีประสิทธิภาพ คุณจะต้องแยกข้อมูลเมตาและเอนทิตีที่เกี่ยวข้องจากฐานความรู้ของเอกสารของคุณเป็นรูปแบบข้อมูลที่มีโครงสร้างที่สามารถเข้าถึงได้ เราขอแนะนำให้ใช้ SQL เพื่อจัดเก็บข้อมูลนี้และดึงคำตอบเนื่องจากความนิยม ความง่ายในการใช้งาน และความสามารถในการปรับขนาด ตัวเลือกนี้ยังได้ประโยชน์จากความสามารถของโมเดลภาษาที่ได้รับการพิสูจน์แล้วในการสร้างคำสั่ง SQL จากภาษาธรรมชาติ
ในส่วนนี้ เราจะเจาะลึกองค์ประกอบต่อไปนี้ที่ทำให้เกิดคำถามเชิงวิเคราะห์:
- กระบวนการแบบแบตช์ที่แยกข้อมูลที่มีโครงสร้างออกจากข้อมูลที่ไม่มีโครงสร้างโดยใช้ LLM
- โมดูลแบบเรียลไทม์ที่แปลงคำถามภาษาธรรมชาติเป็นการสืบค้น SQL และดึงผลลัพธ์จากฐานข้อมูล SQL
คุณสามารถแยกข้อมูลเมตาที่เกี่ยวข้องเพื่อสนับสนุนคำถามเชิงวิเคราะห์ได้ดังนี้:
- กำหนดสคีมา JSON สำหรับข้อมูลที่คุณต้องการแยกออกมา ซึ่งมีคำอธิบายของแต่ละช่องและประเภทข้อมูล และรวมถึงตัวอย่างของค่าที่คาดหวัง
- สำหรับเอกสารแต่ละฉบับ ให้แจ้ง LLM ด้วยสคีมา JSON และขอให้แยกข้อมูลที่เกี่ยวข้องอย่างถูกต้อง
- เมื่อความยาวของเอกสารเกินความยาวของบริบท และเพื่อลดต้นทุนในการดึงข้อมูลด้วย LLM คุณสามารถใช้การค้นหาเชิงความหมายเพื่อดึงข้อมูลและนำเสนอชิ้นเอกสารที่เกี่ยวข้องไปยัง LLM ระหว่างการดึงข้อมูล
- แยกวิเคราะห์เอาต์พุต JSON และตรวจสอบความถูกต้องของการแยก LLM
- หรือสำรองผลลัพธ์บน Amazon S3 เป็นไฟล์ CSV
- โหลดลงในฐานข้อมูล SQL เพื่อการสืบค้นในภายหลัง
กระบวนการนี้ได้รับการจัดการโดยสถาปัตยกรรมต่อไปนี้ โดยที่เอกสารในรูปแบบข้อความจะถูกโหลดด้วยสคริปต์ Python ที่ทำงานในรูปแบบ การประมวลผล Amazon SageMaker งานเพื่อดำเนินการสกัด
สำหรับเอนทิตีแต่ละกลุ่ม เราสร้างพรอมต์แบบไดนามิกที่มีคำอธิบายที่ชัดเจนของงานการแยกข้อมูล และรวมสคีมา JSON ที่กำหนดผลลัพธ์ที่คาดหวังและรวมส่วนเอกสารที่เกี่ยวข้องเป็นบริบท นอกจากนี้เรายังเพิ่มตัวอย่างอินพุตและเอาต์พุตที่ถูกต้องเพื่อปรับปรุงประสิทธิภาพการแยกด้วยการเรียนรู้แบบไม่กี่ช็อต สิ่งนี้แสดงให้เห็นใน notebooks/05-entities-extraction-to-structured-metadata.ipynb
.
ส่วนที่ 3: สร้างผู้ช่วยเอกสารตัวแทนด้วย Amazon Bedrock
ในส่วนนี้ เราจะสาธิตวิธีใช้ Amazon Bedrock LLM เพื่อสืบค้นข้อมูลและสร้างตัวแทน LLM ที่ปรับปรุง RAG ด้วยความสามารถในการวิเคราะห์ ซึ่งช่วยให้คุณสามารถสร้างผู้ช่วยเอกสารอัจฉริยะที่สามารถตอบคำถามเฉพาะโดเมนที่ซับซ้อนในเอกสารหลายฉบับได้ คุณสามารถอ้างถึง ฟังก์ชันแลมบ์ดาบน GitHub สำหรับการใช้งานตัวแทนและเครื่องมือที่อธิบายไว้ในส่วนนี้อย่างเป็นรูปธรรม
กำหนดคำสั่ง SQL และตอบคำถามเชิงวิเคราะห์
ตอนนี้เรามีที่เก็บข้อมูลเมตาที่มีโครงสร้างซึ่งมีเอนทิตีที่เกี่ยวข้องแยกและโหลดลงในฐานข้อมูล SQL ที่เราสามารถสืบค้นได้ คำถามที่ยังคงอยู่คือจะสร้างการสืบค้น SQL ที่ถูกต้องจากคำถามที่เป็นภาษาธรรมชาติที่ป้อนเข้าไปได้อย่างไร
LLM สมัยใหม่สามารถสร้าง SQL ได้ดี ตัวอย่างเช่น หากคุณร้องขอจาก Anthropic Claude LLM ผ่าน อเมซอน เบดร็อค ในการสร้างแบบสอบถาม SQL คุณจะเห็นคำตอบที่น่าเชื่อถือ อย่างไรก็ตาม เราต้องปฏิบัติตามกฎบางประการเมื่อเขียนข้อความแจ้งเพื่อเข้าถึงคำสั่ง SQL ที่แม่นยำยิ่งขึ้น กฎเหล่านี้มีความสำคัญอย่างยิ่งสำหรับข้อความค้นหาที่ซับซ้อนเพื่อลดภาพหลอนและข้อผิดพลาดทางไวยากรณ์:
- อธิบายงานได้อย่างถูกต้องภายในข้อความแจ้ง
- รวมสคีมาของตาราง SQL ภายในพร้อมท์ พร้อมอธิบายแต่ละคอลัมน์ของตารางและระบุประเภทข้อมูล
- บอก LLM อย่างชัดเจนให้ใช้เฉพาะชื่อคอลัมน์และประเภทข้อมูลที่มีอยู่เท่านั้น
- เพิ่มตาราง SQL สองสามแถว
คุณยังสามารถประมวลผลแบบสอบถาม SQL ที่สร้างขึ้นภายหลังได้โดยใช้ linter เช่น sqlfluff เพื่อแก้ไขการจัดรูปแบบหรือ parser เช่น sqlglot เพื่อตรวจจับข้อผิดพลาดทางไวยากรณ์และเพิ่มประสิทธิภาพการสืบค้น นอกจากนี้ เมื่อประสิทธิภาพไม่เป็นไปตามข้อกำหนด คุณสามารถจัดเตรียมตัวอย่างบางส่วนภายในพร้อมท์เพื่อกำหนดทิศทางโมเดลด้วยการเรียนรู้เพียงไม่กี่ขั้นตอนเพื่อสร้างการสืบค้น SQL ที่แม่นยำยิ่งขึ้น
จากมุมมองของการนำไปปฏิบัติ เราใช้ AWS แลมบ์ดา ทำหน้าที่ประสานกระบวนการต่อไปนี้:
- เรียกโมเดล Anthropic Claude ใน Amazon Bedrock ด้วยคำถามอินพุตเพื่อรับการสืบค้น SQL ที่เกี่ยวข้อง ในที่นี้เราใช้. ฐานข้อมูล SQL จาก LangChain เพื่อเพิ่มคำอธิบายสคีมาของตาราง SQL ที่เกี่ยวข้อง และใช้พรอมต์ที่กำหนดเอง
- แยกวิเคราะห์ ตรวจสอบ และเรียกใช้แบบสอบถาม SQL กับ Amazon Aurora PostgreSQL-รุ่นที่เข้ากันได้ ฐานข้อมูล
สถาปัตยกรรมสำหรับโซลูชันส่วนนี้ถูกเน้นไว้ในแผนภาพต่อไปนี้
ข้อควรพิจารณาด้านความปลอดภัยเพื่อป้องกันการโจมตีแบบแทรก SQL
เมื่อเราเปิดใช้งานผู้ช่วย AI เพื่อสืบค้นฐานข้อมูล SQL เราจะต้องตรวจสอบให้แน่ใจว่าสิ่งนี้จะไม่ทำให้เกิดช่องโหว่ด้านความปลอดภัย เพื่อให้บรรลุเป้าหมายนี้ เราเสนอมาตรการรักษาความปลอดภัยต่อไปนี้เพื่อป้องกันการโจมตีแบบแทรก SQL:
- ใช้สิทธิ์ IAM สิทธิ์ขั้นต่ำ – จำกัดสิทธิ์ของฟังก์ชัน Lambda ที่เรียกใช้คำสั่ง SQL โดยใช้ไฟล์ AWS Identity และการจัดการการเข้าถึง (IAM) นโยบายและบทบาทที่เป็นไปตาม หลักการอภิสิทธิ์น้อยที่สุด. ในกรณีนี้ เราให้สิทธิ์การเข้าถึงแบบอ่านอย่างเดียว
- จำกัดการเข้าถึงข้อมูล – ให้การเข้าถึงตารางและคอลัมน์ขั้นต่ำเท่านั้นเพื่อป้องกันการโจมตีการเปิดเผยข้อมูล
- เพิ่มเลเยอร์การกลั่นกรอง – แนะนำเลเยอร์การควบคุมที่ตรวจจับความพยายามในการฉีดทันทีตั้งแต่เนิ่นๆ และป้องกันไม่ให้แพร่กระจายไปยังส่วนที่เหลือของระบบ อาจอยู่ในรูปแบบของตัวกรองตามกฎ การจับคู่ความคล้ายคลึงกับฐานข้อมูลของตัวอย่างการแทรกพร้อมต์ที่รู้จัก หรือตัวแยกประเภท ML
การเรียกค้นความหมายเพื่อเพิ่มบริบทการสร้าง
โซลูชันที่เราเสนอใช้ RAG พร้อมการค้นหาเชิงความหมายในองค์ประกอบ 3 คุณสามารถใช้โมดูลนี้โดยใช้ ฐานความรู้สำหรับ Amazon Bedrock. นอกจากนี้ยังมีตัวเลือกอื่นๆ มากมายในการใช้งาน RAG เช่น API การดึงข้อมูลของ Amazon Kendra, ฐานข้อมูลเวกเตอร์ Amazon OpenSearchและ Amazon Aurora PostgreSQL พร้อม pgvector, ท่ามกลางคนอื่น ๆ. แพ็คเกจโอเพ่นซอร์ส aws-genai-llm-chatbot สาธิตวิธีใช้ตัวเลือกการค้นหาเวกเตอร์จำนวนมากเหล่านี้เพื่อใช้งานแชทบอตที่ขับเคลื่อนด้วย LLM
ในโซลูชันนี้ เนื่องจากเราต้องการทั้งการสืบค้น SQL และการค้นหาเวกเตอร์ เราจึงตัดสินใจใช้ Amazon Aurora PostgreSQL กับ pgvector ส่วนขยายซึ่งรองรับทั้งสองคุณสมบัติ ดังนั้นเราจึงใช้ส่วนประกอบ RAG การค้นหาเชิงความหมายด้วยสถาปัตยกรรมต่อไปนี้
กระบวนการตอบคำถามโดยใช้สถาปัตยกรรมก่อนหน้านั้นเสร็จสิ้นในสองขั้นตอนหลัก
ขั้นแรก กระบวนการแบบแบตช์ออฟไลน์ซึ่งทำงานเป็นงานการประมวลผลของ SageMaker จะสร้างดัชนีการค้นหาความหมายดังนี้:
- งาน SageMaker จะถูกรันเป็นระยะๆ หรือเมื่อได้รับเอกสารใหม่
- โดยจะโหลดเอกสารข้อความจาก Amazon S3 และแบ่งออกเป็นส่วนที่ทับซ้อนกัน
- สำหรับแต่ละชิ้นจะใช้โมเดลการฝัง Amazon Titan เพื่อสร้างเวกเตอร์การฝัง
- มันใช้ PGVector จาก LangChain เพื่อนำเข้าการฝังที่มีชิ้นเอกสารและข้อมูลเมตาลงใน Amazon Aurora PostgreSQL และสร้างดัชนีการค้นหาความหมายบนเวกเตอร์ที่ฝังทั้งหมด
ประการที่สอง แบบเรียลไทม์และสำหรับคำถามใหม่แต่ละข้อ เราสร้างคำตอบดังนี้:
- ผู้เรียบเรียงที่ทำงานบนฟังก์ชัน Lambda ได้รับคำถามนี้
- ผู้เรียบเรียงฝังคำถามด้วยโมเดลการฝังเดียวกัน
- โดยจะดึงข้อมูลชิ้นส่วนเอกสารที่เกี่ยวข้องมากที่สุดในระดับ Top-K จากดัชนีการค้นหาความหมาย PostgreSQL นอกจากนี้ยังใช้การกรองข้อมูลเมตาเพื่อปรับปรุงความแม่นยำอีกด้วย
- ส่วนเหล่านี้จะถูกแทรกแบบไดนามิกในพรอมต์ LLM ควบคู่ไปกับคำถามอินพุต
- ข้อความแจ้งจะแสดงต่อ Anthropic Claude บน Amazon Bedrock เพื่อสั่งให้ตอบคำถามอินพุตตามบริบทที่มีอยู่
- ในที่สุด คำตอบที่สร้างขึ้นจะถูกส่งไปยังผู้เรียบเรียง
ตัวแทนที่สามารถใช้เครื่องมือในการให้เหตุผลและดำเนินการ
จนถึงตอนนี้ในโพสต์นี้ เราได้พูดคุยถึงการรักษาคำถามที่ต้องใช้ RAG หรือการใช้เหตุผลเชิงวิเคราะห์แยกกัน อย่างไรก็ตาม คำถามในโลกแห่งความเป็นจริงจำนวนมากต้องการความสามารถทั้งสองอย่าง ซึ่งบางครั้งก็ต้องใช้เหตุผลหลายขั้นตอน เพื่อที่จะได้คำตอบสุดท้าย เพื่อสนับสนุนคำถามที่ซับซ้อนมากขึ้น เราจำเป็นต้องแนะนำแนวคิดของตัวแทน
ตัวแทน LLM เช่น ตัวแทนของ Amazon Bedrockเมื่อเร็ว ๆ นี้กลายเป็นวิธีแก้ปัญหาที่มีแนวโน้มว่าสามารถใช้ LLM เพื่อหาเหตุผลและปรับเปลี่ยนโดยใช้บริบทปัจจุบัน และเลือกการดำเนินการที่เหมาะสมจากรายการตัวเลือก ซึ่งนำเสนอกรอบการทำงานการแก้ปัญหาทั่วไป ตามที่กล่าวไว้ใน ตัวแทนอิสระที่ขับเคลื่อนด้วย LLMมีกลยุทธ์การกระตุ้นเตือนและรูปแบบการออกแบบมากมายสำหรับตัวแทน LLM ที่สนับสนุนการใช้เหตุผลที่ซับซ้อน
รูปแบบการออกแบบรูปแบบหนึ่งคือเหตุผลและการกระทำ (ReAct) ซึ่งนำมาใช้ ReAct: การประสานการใช้เหตุผลและการแสดงในรูปแบบภาษา. ใน ReAct เอเจนต์จะป้อนเป้าหมายที่สามารถเป็นคำถามได้ ระบุส่วนที่ขาดหายไปเพื่อตอบคำถาม และเสนอเครื่องมือที่เหมาะสมซ้ำๆ เพื่อรวบรวมข้อมูลตามคำอธิบายของเครื่องมือที่มีอยู่ หลังจากได้รับคำตอบจากเครื่องมือที่กำหนด LLM จะประเมินอีกครั้งว่ามีข้อมูลทั้งหมดที่จำเป็นในการตอบคำถามอย่างครบถ้วนหรือไม่ ถ้าไม่เช่นนั้น ก็จะใช้เหตุผลอีกขั้นตอนหนึ่งและใช้เครื่องมือเดียวกันหรือเครื่องมืออื่นเพื่อรวบรวมข้อมูลเพิ่มเติม จนกว่าคำตอบสุดท้ายจะพร้อมหรือถึงขีดจำกัด
แผนภาพลำดับต่อไปนี้อธิบายวิธีการทำงานของตัวแทน ReAct เพื่อตอบคำถาม “ขอรายชื่อบริษัท 5 อันดับแรกที่มีรายได้สูงสุดในช่วง 2 ปีที่ผ่านมา และระบุความเสี่ยงที่เกี่ยวข้องกับบริษัทอันดับต้นๆ”
รายละเอียดของการนำแนวทางนี้ไปใช้ใน Python มีอธิบายไว้ใน ตัวแทน LLM แบบกำหนดเอง. ในโซลูชันของเรา เอเจนต์และเครื่องมือได้รับการปรับใช้ด้วยสถาปัตยกรรมบางส่วนที่ไฮไลต์ต่อไปนี้
เพื่อตอบคำถามอินพุต เราใช้บริการของ AWS ดังต่อไปนี้:
- ผู้ใช้ป้อนคำถามผ่าน UI ซึ่งเรียกใช้ API Amazon API Gateway Amazon.
- API Gateway ส่งคำถามไปยังฟังก์ชัน Lambda ที่ใช้งานตัวดำเนินการตัวแทน
- ตัวแทนเรียก LLM พร้อมพร้อมต์ที่มีคำอธิบายของเครื่องมือที่มีอยู่ รูปแบบคำสั่ง ReAct และคำถามอินพุต จากนั้นแยกวิเคราะห์การดำเนินการถัดไปที่ต้องดำเนินการให้เสร็จสิ้น
- การดำเนินการประกอบด้วยเครื่องมือที่จะเรียกใช้และอินพุตของการดำเนินการคืออะไร
- หากเครื่องมือที่ใช้คือ SQL ตัวดำเนินการเอเจนต์จะเรียก SQLQA เพื่อแปลงคำถามเป็น SQL และรัน จากนั้นจะเพิ่มผลลัพธ์ลงในพรอมต์และเรียก LLM อีกครั้งเพื่อดูว่าสามารถตอบคำถามเดิมได้หรือไม่ หรือจำเป็นต้องดำเนินการเพิ่มเติมหรือไม่
- ในทำนองเดียวกัน หากเครื่องมือที่ใช้คือการค้นหาเชิงความหมาย อินพุตการดำเนินการจะถูกแยกวิเคราะห์และใช้เพื่อดึงข้อมูลจากดัชนีการค้นหาเชิงความหมายของ PostgreSQL โดยจะเพิ่มผลลัพธ์ลงในข้อความแจ้งและตรวจสอบว่า LLM สามารถตอบหรือต้องการการดำเนินการอื่นได้หรือไม่
- หลังจากที่ข้อมูลทั้งหมดเพื่อตอบคำถามพร้อมใช้งานแล้ว ตัวแทน LLM จะกำหนดคำตอบสุดท้ายและส่งกลับไปยังผู้ใช้
คุณสามารถขยายเอเจนต์ด้วยเครื่องมือเพิ่มเติมได้ ในการนำไปปฏิบัติได้เมื่อ GitHubเราสาธิตวิธีที่คุณสามารถเพิ่มเครื่องมือค้นหาและเครื่องคิดเลขเป็นเครื่องมือพิเศษให้กับกลไก SQL และเครื่องมือค้นหาเชิงความหมายดังกล่าวข้างต้น เพื่อจัดเก็บประวัติการสนทนาที่กำลังดำเนินอยู่ เราใช้ อเมซอน ไดนาโมดีบี ตาราง
จากประสบการณ์ของเราจนถึงขณะนี้ เราพบว่าสิ่งต่อไปนี้เป็นกุญแจสู่ตัวแทนที่ประสบความสำเร็จ:
- LLM พื้นฐานที่สามารถให้เหตุผลด้วยรูปแบบ ReAct
- คำอธิบายที่ชัดเจนของเครื่องมือที่มีอยู่ เมื่อใดที่ควรใช้งาน และคำอธิบายอาร์กิวเมนต์อินพุตพร้อมตัวอย่างอินพุตและเอาต์พุตที่คาดหวัง
- โครงร่างที่ชัดเจนของรูปแบบ ReAct ที่ LLM ต้องปฏิบัติตาม
- เครื่องมือที่เหมาะสมสำหรับการแก้ปัญหาทางธุรกิจที่ตัวแทน LLM สามารถใช้งานได้
- แยกวิเคราะห์ผลลัพธ์จากการตอบสนองของตัวแทน LLM อย่างถูกต้องตามเหตุผล
เพื่อเพิ่มประสิทธิภาพต้นทุน เราขอแนะนำให้แคชคำถามที่พบบ่อยที่สุดพร้อมคำตอบ และอัปเดตแคชนี้เป็นระยะเพื่อลดการโทรไปยัง LLM ที่เกี่ยวข้อง ตัวอย่างเช่น คุณสามารถสร้างดัชนีการค้นหาเชิงความหมายด้วยคำถามที่พบบ่อยที่สุดตามที่อธิบายไว้ก่อนหน้านี้ และจับคู่คำถามของผู้ใช้ใหม่กับดัชนีก่อนที่จะเรียก LLM หากต้องการสำรวจตัวเลือกการแคชอื่นๆ โปรดดูที่ การรวมแคช LLM.
รองรับรูปแบบอื่นๆ เช่น ไฟล์วิดีโอ รูปภาพ เสียง และ 3D
คุณสามารถใช้โซลูชันเดียวกันนี้กับข้อมูลประเภทต่างๆ ได้ เช่น รูปภาพ วิดีโอ เสียง และไฟล์การออกแบบ 3 มิติ เช่น ไฟล์ CAD หรือไฟล์ Mesh สิ่งนี้เกี่ยวข้องกับการใช้เทคนิค ML ที่จัดตั้งขึ้นเพื่ออธิบายเนื้อหาไฟล์ในรูปแบบข้อความ ซึ่งสามารถนำเข้าไปยังโซลูชันที่เราสำรวจก่อนหน้านี้ได้ แนวทางนี้ช่วยให้คุณสามารถดำเนินการสนทนา QA กับประเภทข้อมูลที่หลากหลายเหล่านี้ได้ ตัวอย่างเช่น คุณสามารถขยายฐานข้อมูลเอกสารของคุณโดยการสร้างคำอธิบายที่เป็นข้อความของรูปภาพ วิดีโอ หรือเนื้อหาเสียง คุณยังสามารถปรับปรุงตารางข้อมูลเมตาได้ด้วยการระบุคุณสมบัติผ่านการจำแนกประเภทหรือการตรวจจับวัตถุในองค์ประกอบภายในรูปแบบเหล่านี้ หลังจากที่ข้อมูลที่แยกออกมานี้ได้รับการจัดทำดัชนีในที่เก็บข้อมูลเมตาหรือดัชนีการค้นหาเชิงความหมายสำหรับเอกสาร สถาปัตยกรรมโดยรวมของระบบที่นำเสนอยังคงมีความสอดคล้องกันเป็นส่วนใหญ่
สรุป
ในโพสต์นี้ เราได้แสดงให้เห็นว่าการใช้ LLM ที่มีรูปแบบการออกแบบ RAG จำเป็นสำหรับการสร้างผู้ช่วย AI เฉพาะโดเมนอย่างไร แต่ไม่เพียงพอที่จะไปถึงระดับความน่าเชื่อถือที่ต้องการเพื่อสร้างมูลค่าทางธุรกิจ ด้วยเหตุนี้ เราจึงเสนอให้ขยายรูปแบบการออกแบบ RAG ยอดนิยมด้วยแนวคิดของตัวแทนและเครื่องมือ โดยที่ความยืดหยุ่นของเครื่องมือช่วยให้เราสามารถใช้ทั้งเทคนิค NLP แบบดั้งเดิมและความสามารถ LLM ที่ทันสมัย เพื่อให้ผู้ช่วย AI มีตัวเลือกเพิ่มเติมในการค้นหาข้อมูลและช่วยเหลือ ผู้ใช้สามารถแก้ไขปัญหาทางธุรกิจได้อย่างมีประสิทธิภาพ
โซลูชันนี้สาธิตกระบวนการออกแบบสำหรับผู้ช่วย LLM ที่สามารถตอบคำถามประเภทต่างๆ ในการเรียกค้น การใช้เหตุผลเชิงวิเคราะห์ และการใช้เหตุผลแบบหลายขั้นตอนในฐานความรู้ทั้งหมดของคุณ นอกจากนี้เรายังเน้นถึงความสำคัญของการคิดย้อนกลับจากประเภทของคำถามและงานที่ผู้ช่วย LLM ของคุณคาดว่าจะช่วยเหลือผู้ใช้ ในกรณีนี้ เส้นทางการออกแบบนำเราไปสู่สถาปัตยกรรมที่มีองค์ประกอบสามส่วน ได้แก่ การค้นหาความหมาย การแยกข้อมูลเมตา และการสืบค้น SQL และเอเจนต์และเครื่องมือ LLM ซึ่งเราคิดว่าเป็นแบบทั่วไปและยืดหยุ่นเพียงพอสำหรับกรณีการใช้งานหลายกรณี นอกจากนี้เรายังเชื่อว่าด้วยการได้รับแรงบันดาลใจจากโซลูชันนี้และเจาะลึกความต้องการของผู้ใช้ คุณจะสามารถขยายโซลูชันนี้ไปสู่สิ่งที่ดีที่สุดสำหรับคุณได้
เกี่ยวกับผู้แต่ง
โมฮาเหม็ด อาลี จามาอุย เป็นสถาปนิกอาวุโสด้านการสร้างต้นแบบ ML ที่มีประสบการณ์ 10 ปีในด้านการเรียนรู้ของเครื่องการผลิต เขาสนุกกับการแก้ไขปัญหาทางธุรกิจด้วยการเรียนรู้ของเครื่องและวิศวกรรมซอฟต์แวร์ และช่วยให้ลูกค้าดึงมูลค่าทางธุรกิจออกมาด้วย ML ในฐานะส่วนหนึ่งของ AWS EMEA Prototyping และ Cloud Engineering เขาช่วยลูกค้าสร้างโซลูชันทางธุรกิจที่ใช้ประโยชน์จากนวัตกรรมใน MLOP, NLP, CV และ LLM
จูเซปเป้ ฮันเนน เป็นที่ปรึกษาร่วมของ ProServe Giuseppe ใช้ทักษะการวิเคราะห์ของเขาร่วมกับ AI&ML เพื่อพัฒนาโซลูชันที่ชัดเจนและมีประสิทธิภาพให้กับลูกค้าของเขา เขาชอบที่จะคิดวิธีแก้ปัญหาง่ายๆ สำหรับปัญหาที่ซับซ้อน โดยเฉพาะอย่างยิ่งปัญหาที่เกี่ยวข้องกับการพัฒนาและการวิจัยทางเทคโนโลยีล่าสุด
ลอเรนส์ เทน เคท เป็นนักวิทยาศาสตร์ข้อมูลอาวุโส Laurens ทำงานร่วมกับลูกค้าองค์กรใน EMEA เพื่อช่วยเร่งผลลัพธ์ทางธุรกิจโดยใช้เทคโนโลยี AWS AI/ML เขาเชี่ยวชาญด้านโซลูชัน NLP และมุ่งเน้นไปที่อุตสาหกรรมซัพพลายเชนและโลจิสติกส์ ในเวลาว่างเขาชอบอ่านหนังสือและศิลปะ
อิรินา ราดู เป็นผู้จัดการการมีส่วนร่วมในการสร้างต้นแบบ ซึ่งเป็นส่วนหนึ่งของ AWS EMEA Prototyping และ Cloud Engineering เธอช่วยให้ลูกค้าได้รับประโยชน์สูงสุดจากเทคโนโลยีใหม่ล่าสุด สร้างสรรค์สิ่งใหม่ๆ ได้เร็วขึ้น และคิดให้ใหญ่ขึ้น
- เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
- PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
- เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
- เพลโตESG. คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
- เพลโตสุขภาพ เทคโนโลยีชีวภาพและข่าวกรองการทดลองทางคลินิก เข้าถึงได้ที่นี่.
- ที่มา: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/
- :มี
- :เป็น
- :ไม่
- :ที่ไหน
- $ ขึ้น
- 1
- 10
- 100
- 2022
- 3d
- 7
- a
- ความสามารถ
- สามารถ
- เกี่ยวกับเรา
- เร่งความเร็ว
- เข้า
- สามารถเข้าถึงได้
- คล่องแคล่ว
- ลงชื่อเข้าใช้
- ความถูกต้อง
- ถูกต้อง
- แม่นยำ
- บรรลุ
- การบรรลุ
- ข้าม
- กระทำ
- การแสดง
- การกระทำ
- การปฏิบัติ
- ปรับ
- เพิ่ม
- นอกจากนี้
- เพิ่ม
- บุญธรรม
- หลังจาก
- อีกครั้ง
- กับ
- ตัวแทน
- ตัวแทน
- AI
- ผู้ช่วย AI
- AI / ML
- ขั้นตอนวิธี
- จัดแนว
- ทั้งหมด
- ช่วยให้
- คู่ขนาน
- ด้วย
- อเมซอน
- อเมซอน SageMaker
- Amazon Text
- Amazon Web Services
- ในหมู่
- an
- การวิเคราะห์
- วิเคราะห์
- วิเคราะห์
- และ
- อื่น
- คำตอบ
- คำตอบ
- มานุษยวิทยา
- ใด
- API
- APIs
- มีผลบังคับใช้
- ใช้
- เข้าใกล้
- เหมาะสม
- ประมาณ
- สถาปัตยกรรม
- เป็น
- ข้อโต้แย้ง
- รอบ
- ศิลปะ
- AS
- ถาม
- ช่วยเหลือ
- ผู้ช่วย
- ผู้ช่วย
- ภาคี
- ที่เกี่ยวข้อง
- สมมติ
- At
- การโจมตี
- ความพยายามในการ
- เสียง
- เสริม
- เติม
- แสงเงินแสงทอง
- อัตโนมัติ
- อิสระ
- ใช้ได้
- AWS
- กลับ
- แบ็กเอนด์
- ยอดคงเหลือ
- ฐาน
- ตาม
- ขั้นพื้นฐาน
- BE
- เพราะ
- รับ
- ก่อน
- พฤติกรรม
- หลัง
- เชื่อ
- ประโยชน์ที่ได้รับ
- ที่ดีที่สุด
- ระหว่าง
- เกิน
- ที่ใหญ่กว่า
- การส่งเสริม
- ทั้งสอง
- สร้าง
- การก่อสร้าง
- ธุรกิจ
- ธุรกิจ
- แต่
- by
- แคช
- ดอลลาร์แคนาดา
- โทรศัพท์
- ที่เรียกว่า
- โทร
- โทร
- CAN
- ผู้สมัคร
- ความสามารถในการ
- สามารถ
- พกพา
- กรณี
- กรณี
- โซ่
- chatbot
- การตรวจสอบ
- ทางเลือก
- ทางเลือก
- Choose
- ชั้น
- การจัดหมวดหมู่
- ชัดเจน
- เมฆ
- สอดคล้องกัน
- การทำงานร่วมกัน
- คอลัมน์
- คอลัมน์
- การผสมผสาน
- รวม
- อย่างไร
- ร่วมกัน
- บริษัท
- บริษัท
- เปรียบเทียบ
- เปรียบเทียบ
- เปรียบเทียบ
- ส่วนประกอบ
- สมบูรณ์
- ซับซ้อน
- ซับซ้อน
- ส่วนประกอบ
- ส่วนประกอบ
- สงบ
- ครอบคลุม
- คำนวณ
- แนวความคิด
- คอนกรีต
- สภาพ
- ความประพฤติ
- เชื่อมต่อ
- พิจารณา
- การพิจารณา
- คงเส้นคงวา
- รวบรวม
- สร้าง
- ผู้ให้คำปรึกษา
- บรรจุ
- ที่มีอยู่
- มี
- เนื้อหา
- สิ่งแวดล้อม
- การสนทนา
- การสนทนา
- AI สนทนา
- การสนทนา
- แปลง
- แปลง
- แกน
- แก้ไข
- ได้อย่างถูกต้อง
- ตรงกัน
- ราคา
- ค่าใช้จ่าย
- ได้
- ควบคู่
- สร้าง
- สร้าง
- การสร้าง
- ปัจจุบัน
- ประเพณี
- ลูกค้า
- Customer Support
- ลูกค้า
- ข้อมูล
- การเข้าถึงข้อมูล
- นักวิทยาศาสตร์ข้อมูล
- ฐานข้อมูล
- ตัดสินใจ
- กำลังตัดสินใจ
- ลึก
- ลึก
- กำหนด
- กำหนด
- คุ้ย
- ความต้องการ
- สาธิต
- สาธิต
- แสดงให้เห็นถึง
- แสดงให้เห็นถึง
- การอ้างอิง
- ปรับใช้
- บรรยาย
- อธิบาย
- อธิบาย
- ลักษณะ
- ออกแบบ
- รูปแบบการออกแบบ
- กระบวนการออกแบบ
- การออกแบบ
- รายละเอียด
- รายละเอียด
- ตรวจจับ
- การตรวจพบ
- พัฒนา
- พัฒนาการ
- การพัฒนา
- ดิจิตอล
- การเปิดเผย
- สนทนา
- กล่าวถึง
- การอภิปราย
- ระยะทาง
- การดำน้ำ
- หลาย
- การดำน้ำ
- do
- เอกสาร
- เอกสาร
- เอกสาร
- ทำ
- ไม่
- โดเมน
- โดเมน
- ทำ
- ลง
- คนขับรถ
- สอง
- ในระหว่าง
- แบบไดนามิก
- แต่ละ
- ก่อน
- ก่อน
- ความสะดวก
- สะดวกในการใช้
- อย่างง่ายดาย
- มีประสิทธิภาพ
- มีประสิทธิภาพ
- อย่างมีประสิทธิภาพ
- ที่มีประสิทธิภาพ
- อย่างมีประสิทธิภาพ
- ทั้ง
- องค์ประกอบ
- การฝัง
- EMEA
- โผล่ออกมา
- จ้าง
- ทำให้สามารถ
- ช่วยให้
- การเปิดใช้งาน
- ปลาย
- มีส่วนร่วม
- เครื่องยนต์
- ชั้นเยี่ยม
- เครื่องยนต์
- เสริม
- ช่วย
- พอ
- เพิ่มคุณค่า
- Enterprise
- หน่วยงาน
- เอกลักษณ์
- สิ่งแวดล้อม
- ข้อผิดพลาด
- โดยเฉพาะอย่างยิ่ง
- จำเป็น
- ที่จัดตั้งขึ้น
- แม้
- คาย
- ตรวจสอบ
- ตัวอย่าง
- ตัวอย่าง
- การดำรงอยู่
- ที่มีอยู่
- แสดง
- ที่คาดหวัง
- ประสบการณ์
- อธิบาย
- อธิบาย
- อธิบาย
- สำรวจ
- สำรวจ
- ที่เปิดเผย
- ขยายออก
- การขยาย
- นามสกุล
- พิเศษ
- สารสกัด
- การสกัด
- สารสกัดจาก
- ต้องเผชิญกับ
- ล้มเหลว
- คำถามที่พบบ่อย
- ไกล
- เร็วขึ้น
- ลักษณะ
- คุณสมบัติ
- ข้อเสนอแนะ
- สองสาม
- สนาม
- เนื้อไม่มีมัน
- ไฟล์
- กรอง
- ฟิลเตอร์
- สุดท้าย
- ในที่สุด
- ทางการเงิน
- หา
- ชื่อจริง
- ความยืดหยุ่น
- มีความยืดหยุ่น
- ไหล
- โฟกัส
- โดยมุ่งเน้น
- ดังต่อไปนี้
- ดังต่อไปนี้
- สำหรับ
- ฟอร์ม
- รูป
- ที่เกิดขึ้น
- รูปแบบ
- กรอบ
- ฟรี
- ราคาเริ่มต้นที่
- ด้านหน้า
- ปลายด้านหน้า
- การตอบสนอง
- เต็ม
- อย่างเต็มที่
- ฟังก์ชัน
- ต่อไป
- เกตเวย์
- รวบรวม
- General
- สร้าง
- สร้าง
- การสร้าง
- รุ่น
- กำเนิด
- กำเนิด AI
- ได้รับ
- ได้รับ
- GitHub
- กำหนด
- เป้าหมาย
- ดี
- ค่อยๆ
- ให้
- บัญชีกลุ่ม
- กลุ่ม
- มี
- มี
- มี
- he
- ช่วย
- การช่วยเหลือ
- จะช่วยให้
- โปรดคลิกที่นี่เพื่ออ่านรายละเอียดเพิ่มเติม
- จุดสูง
- ที่สูงที่สุด
- ไฮไลต์
- ของเขา
- ประวัติ
- หวังว่า
- สรุป ความน่าเชื่อถือของ Olymp Trade?
- ทำอย่างไร
- อย่างไรก็ตาม
- HTML
- HTTPS
- เป็นมนุษย์
- ความคิด
- ระบุ
- แยกแยะ
- ระบุ
- เอกลักษณ์
- if
- ภาพ
- ภาพ
- ภาพ
- การดำเนินการ
- การดำเนินงาน
- การดำเนินการ
- การดำเนินการ
- ความสำคัญ
- สำคัญ
- ปรับปรุง
- การปรับปรุง
- การปรับปรุง
- การปรับปรุง
- in
- รวมถึง
- ดัชนี
- การจัดทำดัชนี
- อุตสาหกรรม
- ข้อมูล
- การสกัดข้อมูล
- แรกเริ่ม
- เราสร้างสรรค์สิ่งใหม่ ๆ
- นวัตกรรม
- อินพุต
- ปัจจัยการผลิต
- แรงบันดาลใจ
- สร้างแรงบันดาลใจ
- แรงบันดาลใจ
- ติดตั้ง
- ตัวอย่าง
- แทน
- รวบรวม
- ฉลาด
- โต้ตอบ
- ภายใน
- เข้าไป
- แนะนำ
- แนะนำ
- ลงทุน
- การสอบสวน
- การลงทุน
- รวมถึง
- IT
- ITS
- ตัวเอง
- การสัมภาษณ์
- การเดินทาง
- jpg
- JSON
- เก็บ
- คีย์
- กุญแจ
- ความรู้
- ที่รู้จักกัน
- ภาษา
- ใหญ่
- ส่วนใหญ่
- ชื่อสกุล
- ต่อมา
- ล่าสุด
- การเปิดตัว
- ชั้น
- การเรียนรู้
- น้อยที่สุด
- นำ
- ความยาว
- ชั้น
- เลฟเวอเรจ
- กดไลก์
- LIMIT
- ข้อ จำกัด
- LINK
- รายการ
- LLM
- โหลด
- โลจิสติก
- อุตสาหกรรมโลจิสติกส์
- นาน
- รัก
- เครื่อง
- เรียนรู้เครื่อง
- ทำ
- หลัก
- เก็บรักษา
- การบำรุงรักษา
- ทำ
- การจัดการ
- ผู้จัดการ
- หลาย
- การจับคู่
- การจับคู่
- เป็นผู้ใหญ่
- อาจ..
- me
- ความหมาย
- มาตรการ
- พบ
- กล่าวถึง
- แค่
- ตาข่าย
- ข่าวสาร
- เมตาดาต้า
- วิธี
- วิธีการ
- เมตริก
- ตัวชี้วัด
- ขั้นต่ำ
- หลอกตา
- หายไป
- ML
- ม.ป.ป
- แบบ
- โมเดล
- การกลั่นกรอง
- ทันสมัย
- โมดูล
- ข้อมูลเพิ่มเติม
- ยิ่งไปกว่านั้น
- มากที่สุด
- หลาย
- ต้อง
- ชื่อ
- โดยธรรมชาติ
- ประมวลผลภาษาธรรมชาติ
- จำเป็น
- จำเป็นต้อง
- จำเป็น
- ความต้องการ
- เพื่อนบ้าน
- สุทธิ
- รายได้สุทธิ
- ไม่เคย
- ใหม่
- ถัดไป
- NLP
- ไม่มี
- สมุดบันทึก
- ความคิด
- วัตถุ
- การตรวจจับวัตถุ
- of
- เสนอ
- การเสนอ
- ออฟไลน์
- มักจะ
- on
- ONE
- ต่อเนื่อง
- เพียง
- เปิด
- โอเพนซอร์ส
- การดำเนินการ
- เพิ่มประสิทธิภาพ
- Options
- or
- ใบสั่ง
- เป็นต้นฉบับ
- อื่นๆ
- ผลิตภัณฑ์อื่นๆ
- ของเรา
- ออก
- ผลลัพธ์
- เค้าโครง
- ที่ระบุไว้
- เอาท์พุต
- เอาท์พุท
- เกิน
- ทั้งหมด
- เอาชนะ
- ของตนเอง
- แพ็คเกจ
- หมีแพนด้า
- ส่วนหนึ่ง
- ส่วน
- แบบแผน
- รูปแบบ
- รูปแบบไฟล์ PDF
- ดำเนินการ
- การปฏิบัติ
- การอนุญาต
- มุมมอง
- เภสัชกรรม
- ชิ้น
- ท่อ
- ที่ราบ
- การวางแผน
- เพลโต
- เพลโตดาต้าอินเทลลิเจนซ์
- เพลโตดาต้า
- น่าเชื่อถือ
- จุด
- นโยบาย
- ยอดนิยม
- ความนิยม
- ประชากร
- เป็นไปได้
- อาจ
- โพสต์
- postgresql
- ที่มีศักยภาพ
- ที่อาจเกิดขึ้น
- ขับเคลื่อน
- ที่มีประสิทธิภาพ
- การปฏิบัติ
- ความแม่นยำ
- เตรียมการ
- นำเสนอ
- นำเสนอ
- นำเสนอ
- การรักษา
- ป้องกัน
- ป้องกัน
- ก่อนหน้านี้
- สิทธิพิเศษ
- การแก้ปัญหา
- ปัญหาที่เกิดขึ้น
- กระบวนการ
- การประมวลผล
- ผลิต
- การผลิต
- ผลิตภัณฑ์
- การผลิต
- คำมั่นสัญญา
- แวว
- คุณสมบัติ
- เสนอ
- เสนอ
- เสนอ
- การสร้างต้นแบบ
- ที่พิสูจน์แล้ว
- ให้
- ให้
- สาธารณะ
- หลาม
- Q & A
- คำสั่ง
- คำถาม
- คำถาม
- รวดเร็ว
- อย่างรวดเร็ว
- อันดับ
- รวดเร็ว
- ดิบ
- มาถึง
- ถึง
- เกิดปฏิกิริยา
- การอ่าน
- พร้อม
- จริง
- โลกแห่งความจริง
- เรียลไทม์
- เหตุผล
- เหมาะสม
- ที่ได้รับ
- การได้รับ
- เมื่อเร็ว ๆ นี้
- เมื่อเร็ว ๆ นี้
- รับรู้
- แนะนำ
- แนะนำ
- ลด
- อ้างอิง
- ภูมิภาค
- ตรงประเด็น
- ความเชื่อถือได้
- วางใจ
- ซากศพ
- รายงาน
- กรุ
- แสดง
- ขอ
- ต้องการ
- จำเป็นต้องใช้
- ความต้องการ
- ต้อง
- การวิจัย
- คำตอบ
- การตอบสนอง
- REST
- ผล
- ผลสอบ
- กลับ
- รายได้
- รายได้
- ทบทวน
- ขวา
- ความเสี่ยง
- บทบาท
- กฎระเบียบ
- วิ่ง
- วิ่ง
- ทำงาน
- sagemaker
- เดียวกัน
- scalability
- การสแกน
- การสแกน
- นักวิทยาศาสตร์
- ต้นฉบับ
- ค้นหา
- เครื่องมือค้นหา
- ที่สอง
- Section
- ส่วน
- ความปลอดภัย
- มาตรการรักษาความปลอดภัย
- เห็น
- แสวงหา
- เห็น
- การเลือก
- การเลือก
- อรรถศาสตร์
- ส่ง
- ระดับอาวุโส
- ส่ง
- ลำดับ
- บริการ
- บริการ
- เธอ
- น่า
- โชว์
- แสดงให้เห็นว่า
- แสดง
- คล้ายคลึงกัน
- ง่าย
- ที่เรียบง่าย
- ลดความซับซ้อน
- พร้อมกัน
- ตั้งแต่
- เดียว
- ทักษะ
- So
- จนถึงตอนนี้
- ซอฟต์แวร์
- วิศวกรรมซอฟต์แวร์
- เพียงผู้เดียว
- ทางออก
- โซลูชัน
- การแก้
- บาง
- บางครั้ง
- แหล่ง
- แหล่งที่มา
- ช่องว่าง
- เฉพาะ
- ความเชี่ยวชาญ
- โดยเฉพาะ
- ความเร็ว
- แยก
- กอง
- ขั้นตอน
- เริ่มต้น
- ที่เริ่มต้น
- คัดท้าย
- ขั้นตอน
- ขั้นตอน
- จัดเก็บ
- เก็บไว้
- ซื่อตรง
- กลยุทธ์
- กลยุทธ์
- โขก
- มุ่งมั่น
- โครงสร้าง
- โครงสร้าง
- สตูดิโอ
- ที่ประสบความสำเร็จ
- อย่างเช่น
- แนะนำ
- เหมาะสม
- สรุป
- จัดหาอุปกรณ์
- ห่วงโซ่อุปทาน
- สนับสนุน
- รองรับ
- แน่ใจ
- วากยสัมพันธ์
- ระบบ
- ตาราง
- ปรับปรุง
- เอา
- ใช้เวลา
- งาน
- งาน
- เทคโนโลยี
- เทคนิค
- เทคโนโลยี
- เทคโนโลยี
- บอก
- สิบ
- ข้อความ
- เกี่ยวกับใจความ
- ขอบคุณ
- ที่
- พื้นที่
- ข้อมูล
- ของพวกเขา
- พวกเขา
- แล้วก็
- ที่นั่น
- ดังนั้น
- ดังนั้น
- ล้อยางขัดเหล่านี้ติดตั้งบนแกน XNUMX (มม.) ผลิตภัณฑ์นี้ถูกผลิตในหลายรูปทรง และหลากหลายเบอร์ความแน่นหนาของปริมาณอนุภาคขัดของมัน จะทำให้ท่านได้รับประสิทธิภาพสูงในการขัดและการใช้งานที่ยาวนาน
- พวกเขา
- คิด
- คิด
- นี้
- เหล่านั้น
- สาม
- ตลอด
- เวลา
- ยักษ์
- ไปยัง
- ในวันนี้
- เครื่องมือ
- เครื่องมือ
- ด้านบน
- ชั้น 5
- ไปทาง
- ไปทาง
- ติดตาม
- แบบดั้งเดิม
- การฝึกอบรม
- แปลง
- การรักษาเยียวยา
- จริง
- เชื่อถือได้
- สอง
- ชนิด
- ชนิด
- เป็นปกติ
- ui
- พื้นฐาน
- เข้าใจ
- จนกระทั่ง
- การปรับปรุง
- เมื่อ
- us
- ใช้
- มือสอง
- ผู้ใช้งาน
- ประสบการณ์ของผู้ใช้
- ผู้ใช้
- ใช้
- การใช้
- ตรวจสอบความถูกต้อง
- ความคุ้มค่า
- ความคุ้มค่า
- ความหลากหลาย
- ต่างๆ
- อเนกประสงค์
- วีดีโอ
- วิดีโอ
- ช่องโหว่
- เดิน
- ทาง..
- we
- เว็บ
- บริการเว็บ
- ดี
- คือ
- อะไร
- เมื่อ
- แต่ทว่า
- ว่า
- ที่
- ในขณะที่
- ทำไม
- วิกิพีเดีย
- จะ
- กับ
- ภายใน
- ไม่มี
- โรงงาน
- จะ
- การเขียน
- X
- ปี
- ปี
- คุณ
- ของคุณ
- ลมทะเล