full stack on prem cv mlops

ระบบ MLOps ภายในองค์กรเต็มรูปแบบสำหรับ Computer Vision

1 การกำหนดค่า 1 คำสั่งจาก Jupyter Notebook เพื่อรองรับผู้ใช้หลายล้านคน

สารบัญ

• ภาพรวม
• วิดีโอสาธิต
• เครื่องมือ/เทคโนโลยี
• แนวปฏิบัติที่นำมาใช้
• พอร์ตบริการ
• วิธีใช้
  • ตั้งค่า
  • การใช้งานน้อยที่สุด
  • การปรับแต่ง
• ทุกอย่างทำงานร่วมกันอย่างไร
• จากภายในองค์กรสู่บนคลาวด์
• สคีมาฐานข้อมูล
• การแก้ไขปัญหา

ภาพรวม

ยินดีต้อนรับสู่ระบบนิเวศ MLOps ภายในองค์กรที่ครอบคลุมของเรา ซึ่งออกแบบมาโดยเฉพาะสำหรับงาน Computer Vision โดยเน้นที่การจัดหมวดหมู่รูปภาพเป็นหลัก พื้นที่เก็บข้อมูลนี้จัดเตรียมทุกสิ่งที่คุณต้องการ ตั้งแต่พื้นที่ทำงานด้านการพัฒนาใน Jupyter Lab/Notebook ไปจนถึงบริการระดับการผลิต ส่วนที่ดีที่สุด? ใช้เวลาเพียง "1 config และ 1 command" เพื่อรันทั้งระบบตั้งแต่การสร้างแบบจำลองไปจนถึงการใช้งาน! เราได้รวมแนวทางปฏิบัติที่ดีที่สุดมากมายเพื่อให้มั่นใจถึงความสามารถในการปรับขนาดและความน่าเชื่อถือ ในขณะเดียวกันก็รักษาความยืดหยุ่นไว้ด้วย แม้ว่ากรณีการใช้งานหลักของเราเกี่ยวข้องกับการจำแนกรูปภาพ โครงสร้างโปรเจ็กต์ของเราสามารถปรับให้เข้ากับการพัฒนา ML/DL ที่หลากหลายได้อย่างง่ายดาย แม้กระทั่งการเปลี่ยนจากในองค์กรไปสู่ระบบคลาวด์!

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

ระบบทั้งหมดถูกรวมไว้ในไฟล์ Docker Compose ไฟล์เดียว ในการตั้งค่า สิ่งที่คุณต้องทำคือเรียกใช้ docker-compose up ! นี่คือระบบภายในองค์กรเต็มรูปแบบ ซึ่งหมายความว่าไม่จำเป็นต้องมีบัญชีคลาวด์ และ ไม่มีค่าใช้จ่ายแม้แต่เล็กน้อย ในการใช้ทั้งระบบ!

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

วิดีโอสาธิต

สาธิต: https://youtu.be/NKil4uzmmQc
คำแนะนำทางเทคนิคเชิงลึก: https://youtu.be/l1S5tHuGBA8

แหล่งข้อมูลในวิดีโอ:

• ไฟล์โมเดล (รุ่นที่ใช้ ResNet50): ลิงก์
• สไลด์: ลิงค์

เครื่องมือ/เทคโนโลยี

หากต้องการใช้พื้นที่เก็บข้อมูลนี้ คุณจำเป็นต้องมี Docker เท่านั้น เพื่อเป็นข้อมูลอ้างอิง เราใช้ Docker เวอร์ชัน 24.0.6, build ed223bc และ Docker Compose เวอร์ชัน v2.21.0-desktop.1 บน Mac M1

• แพลตฟอร์ม: นักเทียบท่า
• พื้นที่ทำงาน: Jupyter Lab
• กรอบการเรียนรู้เชิงลึก: TensorFlow
• การกำหนดเวอร์ชันข้อมูล: DvC
• การตรวจสอบข้อมูล: DeepChecks
• แพลตฟอร์มแมชชีนเลิร์นนิง / การติดตามการทดลอง: MLflow
• ผู้เรียบเรียงไปป์ไลน์: นายอำเภอ
• การปรับใช้บริการ Machine Learning: FastAPI, Uvicorn, Gunicorn, Nginx (+ HTML, CSS, JS สำหรับ UI แบบธรรมดา)
• ฐานข้อมูล: PostgreSQL (SQL), Prometheus (อนุกรมเวลา)
• การตรวจสอบโมเดลการเรียนรู้ของเครื่องและการตรวจจับดริฟท์: ชัดเจน
• การตรวจสอบระบบและแดชบอร์ดโดยรวม: Grafana

แนวปฏิบัติที่นำมาใช้

เราได้นำแนวทางปฏิบัติที่ดีที่สุดหลายประการไปใช้ในโครงการนี้:

• ตัวโหลดข้อมูล/ไปป์ไลน์ที่มีประสิทธิภาพโดยใช้ tf.data สำหรับ TensorFlow
• การเพิ่มรูปภาพด้วย imgaug lib เพื่อความยืดหยุ่นที่มากขึ้นในตัวเลือกการเพิ่มมากกว่าฟังก์ชันหลักจาก TensorFlow
• การใช้ os.env สำหรับการกำหนดค่าที่สำคัญหรือระดับบริการ
• การบันทึกด้วยโมดูล logging แทน print
• การจัดเก็บฐานข้อมูลสำหรับผลการตอบกลับการบริการ
• การกำหนดค่าแบบไดนามิกผ่าน .env สำหรับตัวแปรใน docker-compose.yml
• การใช้ default.conf.template สำหรับ Nginx เพื่อใช้ตัวแปรสภาพแวดล้อมในการกำหนดค่า Nginx อย่างหรูหรา (คุณสมบัติใหม่ใน Nginx 1.19)
• การกำหนดค่า Nginx สำหรับการแสดงบันทึกเทอร์มินัล
• การตั้งค่าผู้ปฏิบัติงาน Prefect เพื่อรองรับการทำงานบนคลัสเตอร์

พอร์ตบริการ

พอร์ตส่วนใหญ่สามารถปรับแต่งได้ในไฟล์ .env ที่รากของที่เก็บนี้ นี่คือค่าเริ่มต้น:

• JupyterLab: 8888 (ข้อมูล: 123456789 )
• MLflow: 5050
• นายอำเภอ: 4200
• PostgreSQL: 5432
• pgAdmin: 16543 (ผู้ใช้: [email protected] , pw: SuperSecurePwdHere )
• บริการการเรียนรู้เชิงลึก: 4242
• อินเทอร์เฟซ Web UI สำหรับบริการ Deep Learning: 4243
• งิงซ์: 80
• เห็นได้ชัดว่า: 8000
• โพรมีธีอุส: 9090
• Grafana: 3000 (ผู้ใช้: admin , pw: admin )

วิธีใช้

คุณต้องพิจารณาแสดงความคิดเห็นเกี่ยวกับ platform: linux/arm64 ใน docker-compose.yml หากคุณไม่ได้ใช้คอมพิวเตอร์ที่ใช้ ARM (เราใช้ Mac M1 เพื่อการพัฒนา) ไม่เช่นนั้นระบบนี้จะใช้งานไม่ได้

ตั้งค่า

1. โคลนที่เก็บนี้ repo นี้มี 2 โมดูลย่อย ดังนั้นให้พิจารณาใช้ --recurse-submodules flag ในคำสั่งของคุณ: git clone --recurse-submodules https://github.com/jomariya23156/full-stack-on-prem-cv-mlops
2. [สำหรับผู้ใช้ที่มี CUDA] หากคุณมี GPU ที่รองรับ CUDA คุณสามารถยกเลิกการใส่ข้อคิดเห็นส่วน deploy ภายใต้บริการ jupyter ใน docker-compose.yml และเปลี่ยนอิมเมจพื้นฐานใน services/jupyter/Dockerfile จาก ubuntu:18.04 เป็น nvidia/cuda:11.4.3-cudnn8-devel-ubuntu20.04 (ข้อความอยู่ในไฟล์ คุณเพียงแค่ต้องแสดงความคิดเห็นและ ไม่แสดงความคิดเห็น) เพื่อใช้ประโยชน์จาก GPU ของคุณ คุณอาจต้องติดตั้ง nvidia-container-toolkit บนเครื่องโฮสต์เพื่อให้ทำงานได้ สำหรับผู้ใช้ Windows/WSL2 เราพบว่าบทความนี้มีประโยชน์มาก
3. ที่รากของไดเร็กทอรี repo ให้รัน docker-compose up หรือ docker-compose up -d เพื่อแยกเทอร์มินัลออก
4. ในครั้งแรกอาจใช้เวลาสักครู่เนื่องจากขนาดของรูปภาพ โดยเฉพาะ jupyter เนื่องจากมีแพ็คเกจและไลบรารีจำนวนมาก โดยทั่วไปอาจใช้เวลาประมาณ 5 ถึง 20 นาที
5. ไปที่โมดูลย่อย DvC ที่ datasets/animals10-dvc และทำตามขั้นตอนในส่วน วิธีใช้

การใช้งานน้อยที่สุด

1. เปิด Jupyter lab บนพอร์ต 8888 http://localhost:8888/lab
2. ไปที่ไดเร็กทอรีเวิร์กสเปซ cd ~/workspace/
3. เปิดใช้งานสภาพแวดล้อม conda (ชื่อสามารถกำหนดค่าได้ใน docker-compose.yml ) conda activate computer-viz-dl
4. เรียกใช้ python run_flow.py --config configs/full_flow_config.yaml
5. เอนหลังและดูตัวแยกประเภทใหม่ล่าสุดของคุณที่ถูกสร้างขึ้น ฝึกอบรม ประเมินผล ปรับใช้ (ตามขนาด) และตรวจสอบบนระบบปฏิบัติการเต็มรูปแบบ!

การปรับแต่ง

• มีหลายสิ่งที่ทำงานร่วมกัน และเป็นการยากที่จะพูดคุยในรายละเอียดทุกส่วน ไม่มีวิธีใดที่ดีไปกว่าการทำให้มือของคุณสกปรกหรืออ่านโค้ด พยายามทำความเข้าใจ และลองปรับแต่งมันด้วยตัวเอง!
• อย่างไรก็ตาม มีแนวทางบางประการที่คุณสามารถปฏิบัติตามได้เพื่อทำให้ส่วนประกอบต่างๆ ทำงานร่วมกันได้อย่างราบรื่นตามที่ควร:
  • งานของคุณควรถูกสร้างขึ้นภายในไดเร็กทอรี tasks
  • งานทั้งหมดของคุณควรถูกเรียกจากโฟลว์ที่สร้างขึ้นภายในไดเร็กทอรี flows
  • ควรเรียกโฟลว์ของคุณด้วย run_flow.py ที่รูทของ repo
  • ในการที่จะเรียกด้วยวิธีนี้ คุณจะต้องใช้ฟังก์ชัน start(config) ในไฟล์โฟลว์ของคุณ ฟังก์ชันนี้ยอมรับการกำหนดค่าเป็น Python dict จากนั้นเรียกโฟลว์เฉพาะในไฟล์นั้นโดยทั่วไป
  • ชุดข้อมูลควรอยู่ภายในไดเร็กทอรี datasets และทั้งหมดควรมีโครงสร้างไดเร็กทอรีเดียวกันกับที่อยู่ใน repo นี้
  • central_storage ที่ ~/ariya/ ควรมีไดเร็กทอรีย่อยอย่างน้อย 2 ไดเร็กทอรีชื่อ models และ ref_data central_storage นี้ทำหน้าที่ในการจัดเก็บอ็อบเจ็กต์ในการจัดเก็บไฟล์ที่จัดฉากทั้งหมดเพื่อใช้ในการพัฒนาและปรับใช้สภาพแวดล้อม (นี่คือหนึ่งในสิ่งที่คุณควรพิจารณาเปลี่ยนเป็นบริการจัดเก็บข้อมูลบนคลาวด์ ในกรณีที่คุณต้องการปรับใช้บนคลาวด์และทำให้สามารถปรับขนาดได้มากขึ้น)

ข้อตกลง สำคัญ ที่ต้อง ระมัดระวังเป็นพิเศษ หากคุณต้องการเปลี่ยนแปลง (เนื่องจากสิ่งเหล่านี้เชื่อมโยงและใช้ในส่วนต่าง ๆ ของระบบ):

• central_storage path -> ภายในควรมี models/ ref_data/ subdirectories
• การตั้งชื่อไฟล์ใน central_storage เช่น <model_name>.yaml , <model_name>_uae , <model_name>_bbsd , <model_name>_ref_data.parquet
• สคีมาฐานข้อมูลทั้งหมด (คอลัมน์) -> มีการเชื่อมโยงในหลาย ๆ ที่ (ส่วนใหญ่เป็น dl_service, prefect_worker/repo อย่างเห็นได้ชัด)
• คีย์/ชื่อของตัวแปรพรีเฟ็ค current_model_metadata_file และ monitor_pool_name
• Prefect เวอร์ชัน 2.13.2 มีข้อบกพร่องในไฟล์ template prefect.yaml และได้รับการแก้ไขแล้วในเวอร์ชันนี้ ดังนั้นหากไม่จำเป็น อย่าใช้เวอร์ชันต่ำกว่านี้ ไม่เช่นนั้น คุณจะต้องทำการเปลี่ยนแปลงไฟล์ที่เกี่ยวข้องกับพรีเฟ็ค
• เห็นได้ชัดว่าเวอร์ชัน 0.4.5 ซึ่งเป็นข้อบกพร่องของ mmd ซึ่งเราใช้เป็นวิธีการฝังการตรวจจับดริฟท์ ได้รับการแก้ไขแล้วในเวอร์ชันนี้ อีกครั้งหากคุณต้องการเปลี่ยนเวอร์ชัน พยายามอย่าให้ต่ำกว่า 0.4.5

ทุกอย่างทำงานร่วมกันอย่างไร

• Jupyter Lab ทำหน้าที่เป็นพื้นที่ทำงานสำหรับการเขียนโค้ด ประกอบด้วยสภาพแวดล้อม Conda ที่ติดตั้งไว้ล่วงหน้าชื่อ computer-viz-dl (ค่าเริ่มต้น) พร้อมด้วยแพ็คเกจที่จำเป็นทั้งหมดสำหรับพื้นที่เก็บข้อมูลนี้ คำสั่ง/รหัส Python ทั้งหมดควรจะทำงานภายใน Jupyter นี้
• พรีเฟ็ คประสานโค้ดการดำเนินการหลักทั้งหมด รวมถึงงานและโฟลว์
• ไดรฟ์ข้อมูล central_storage ทำหน้าที่เป็นพื้นที่จัดเก็บไฟล์ส่วนกลางที่ใช้ตลอดการพัฒนาและการปรับใช้ โดยส่วนใหญ่ประกอบด้วยไฟล์โมเดล (รวมถึงเครื่องตรวจจับดริฟท์) และข้อมูลอ้างอิงในรูปแบบปาร์เก้ เมื่อสิ้นสุดขั้นตอนการฝึกโมเดล โมเดลใหม่จะถูกบันทึกที่นี่ และบริการปรับใช้จะดึงโมเดลจากตำแหน่งนี้ ( หมายเหตุ : นี่เป็นสถานที่ที่เหมาะสมที่สุดที่จะแทนที่ด้วยบริการจัดเก็บข้อมูลบนคลาวด์เพื่อความสามารถในการขยายขนาด)
• ต่อไปนี้คือคำอธิบายทีละขั้นตอนของสิ่งที่เกิดขึ้นเมื่อคุณเรียกใช้โฟลว์ทั้งหมด โฟลว์ทั้งหมดประกอบด้วย 3 โฟลว์ย่อย; ฝึกอบรม ประเมิน และปรับใช้การวิ่งตามลำดับ แต่ละโฟลว์มีชุดไฟล์กำหนดค่าของตัวเอง โดยอาจเป็นไฟล์ .yaml เฉพาะสำหรับแต่ละโฟลว์ หรืออาจเป็นไฟล์ .yaml ได้เพียง 1 ไฟล์เท่านั้นสำหรับโฟลว์ทั้งหมด (ดูไฟล์ในโฟลเดอร์ การกำหนดค่า ):
  1. การไหลของรถไฟ
     1. อ่านการกำหนดค่า
     2. ใช้ส่วน model ในการกำหนดค่าเพื่อสร้างโมเดลตัวแยกประเภท โมเดลนี้สร้างขึ้นด้วย TensorFlow และสถาปัตยกรรมของโมเดลนั้นได้รับการฮาร์ดโค้ดที่ tasks/model.py:build_model
     3. ใช้ส่วนชุด dataset ในการกำหนดค่าเพื่อเตรียมชุดข้อมูลสำหรับการฝึก ขั้นตอนนี้ใช้ DvC เพื่อตรวจสอบความสอดคล้องของข้อมูลในดิสก์เปรียบเทียบกับเวอร์ชันที่ระบุในการกำหนดค่า หากมีการเปลี่ยนแปลง ระบบจะแปลงกลับเป็นเวอร์ชันที่ระบุโดยทางโปรแกรม หากคุณต้องการเก็บการเปลี่ยนแปลงไว้ ในกรณีที่คุณกำลังทดลองกับชุดข้อมูล คุณสามารถตั้งค่าฟิลด์ dvc_checkout ในการกำหนดค่าเป็น false เพื่อที่ DvC จะไม่ดำเนินการดังกล่าว
     4. จากนั้น DeepChecks จะตรวจสอบชุดข้อมูลที่เตรียมไว้และบันทึกรายงานผลลัพธ์ คุณสามารถเพิ่มเงื่อนไขบางอย่างในขั้นตอนนี้ ตัวอย่างเช่น หากการทดสอบร้ายแรงล้มเหลว ให้ยุติกระบวนการเพื่อไม่ให้ฝึกโมเดลที่ไม่ดี
     5. ใช้ส่วน train ในการกำหนดค่าเพื่อสร้างตัวโหลดข้อมูลและเริ่มกระบวนการฝึกอบรม ข้อมูลการทดลองและสิ่งประดิษฐ์ได้รับการติดตามและบันทึกด้วย MLflow หมายเหตุ: รายงานผลลัพธ์ (ในไฟล์ .html ) จาก DeepChecks จะถูกอัปโหลดไปยังการทดสอบการฝึกบน MLflow สำหรับแบบแผนด้วย
     6. สร้างไฟล์ข้อมูลเมตาของโมเดลจากส่วน model ในการกำหนดค่า
     7. บันทึกโมเดลที่ได้รับการฝึกอบรมและไฟล์ข้อมูลเมตาที่เกี่ยวข้องลงในดิสก์ภายในเครื่อง
     8. อัปโหลดไฟล์ข้อมูลเมตาของโมเดลและโมเดลไปยัง central_storage (ในกรณีนี้ เป็นเพียงการทำสำเนาไปยังตำแหน่ง central_storage นี่คือขั้นตอนที่คุณสามารถเปลี่ยนเป็นการอัปโหลดไฟล์ไปยังที่เก็บข้อมูลบนคลาวด์)
     9. สร้างเครื่องตรวจจับดริฟท์ตามโมเดลที่ผ่านการฝึกอบรมและส่วน model/drift_detection ในการกำหนดค่า
     10. บันทึกและอัปโหลดเครื่องตรวจจับดริฟท์ไปยัง central_storage
     11. สร้างข้อมูลอ้างอิงโดยใช้เครื่องตรวจจับดริฟท์และชุดข้อมูล
     12. บันทึกข้อมูลอ้างอิงใน .parquet และอัปโหลดไปยัง central_storage
     13. คืนเส้นทางไปยังโมเดลที่อัปโหลดและไฟล์ข้อมูลเมตาของโมเดลสำหรับโฟลว์ถัดไป
  2. กระแสการประเมินผล
     1. โหลดโมเดลที่บันทึกไว้และไฟล์ข้อมูลเมตาของโมเดล
     2. เตรียมชุดข้อมูลสำหรับการทดสอบ (นำงานเดิมมาใช้ซ้ำในโฟลว์ของรถไฟ)
     3. สร้างตัวโหลดข้อมูลจากการกำหนดค่าและประเมินโมเดล
     4. บันทึกผลลัพธ์ไปที่ MLflow
  3. ขั้นตอนการปรับใช้
     1. คำขอ PUT เพื่อทริกเกอร์บริการที่ทำงานอยู่ (เสิร์ฟพร้อมกับ FastAPI + Uvicorn + Gunicorn + Nginx ) เพื่อดึงโมเดลที่ได้รับการฝึกอบรมใหม่จาก central_storage (นี่เป็นข้อกังวลประการหนึ่งที่กล่าวถึงในวิดีโอสาธิตการสอน โปรดดูรายละเอียดเพิ่มเติม)
     2. สร้างหรืออัปเดต (หากมี) ตัวแปรพรีเฟ็คสำหรับการตรวจสอบการกำหนดค่า ตัวแปรส่วนใหญ่ 2 ตัว ได้แก่ current_model_metadata_file ที่จัดเก็บชื่อไฟล์ข้อมูลเมตาของโมเดลที่ลงท้ายด้วย .yaml และ monitor_pool_name จัดเก็บชื่อพูลงานสำหรับการปรับใช้ Prefect worker และโฟลว์
     3. ปรับใช้โฟลว์การตรวจสอบ Prefect ซึ่งจะดึงข้อมูลจาก PostgreSQL ภายใน และใช้ Evidently เพื่อคำนวณรายงานและเกณฑ์ชี้วัดที่เกี่ยวข้องกับการเคลื่อนตัวของข้อมูล โดยทางโปรแกรม cd ใส่เข้าไปใน deployments/prefect-deployments และรัน prefect --no-prompt deploy --name {deploy_name} โดยใช้อินพุตจากส่วน deploy/prefect ในการกำหนดค่า
     4. โฟลว์มอนิเตอร์ถูกกำหนดให้ทำงานทุกสัปดาห์หรือที่เรียกว่าสัปดาห์ละครั้ง แต่คุณสามารถเรียกใช้โฟลว์ที่ปรับใช้ด้วยตนเองได้จาก Prefect UI ตรวจสอบเอกสารอย่างเป็นทางการเกี่ยวกับวิธีการทำเช่นนี้ (ค่อนข้างง่ายและตรงไปตรงมา)
     5. คุณยังสามารถดูแดชบอร์ดดริฟท์ข้อมูลบน Evidently UI (พอร์ต 8000 ตามค่าเริ่มต้น)

จากภายในองค์กรสู่บนคลาวด์

เนื่องจากทุกอย่างได้รับการเชื่อมต่อและบรรจุในคอนเทนเนอร์ใน Repo นี้แล้ว การแปลงบริการจากภายในองค์กรไปเป็นบนคลาวด์จึงค่อนข้างตรงไปตรงมา เมื่อคุณพัฒนาและทดสอบ API บริการของคุณเสร็จแล้ว คุณสามารถแยก services/dl_service ออกไปได้โดยการสร้างคอนเทนเนอร์จาก Dockerfile และพุชไปยังบริการรีจิสทรีคอนเทนเนอร์บนคลาวด์ (เช่น AWS ECR) แค่นั้นแหละ!
หมายเหตุ: มีปัญหาที่อาจเกิดขึ้นอย่างหนึ่งในรหัสบริการ หากคุณต้องการใช้ในสภาพแวดล้อมการใช้งานจริง ฉันได้กล่าวถึงมันในวิดีโอเชิงลึกแล้วและขอแนะนำให้คุณใช้เวลาดูวิดีโอทั้งหมด

สคีมาฐานข้อมูล

เรามีฐานข้อมูลสามฐานข้อมูลภายใน PostgreSQL: หนึ่งฐานข้อมูลสำหรับ MLflow หนึ่งฐานข้อมูลสำหรับ Prefect และอีกหนึ่งฐานข้อมูลที่เราสร้างขึ้นสำหรับบริการโมเดล ML ของเรา เราจะไม่เจาะลึกสองรายการแรก เนื่องจากเครื่องมือเหล่านั้นจัดการด้วยตนเอง ฐานข้อมูลสำหรับบริการโมเดล ML ของเราเป็นฐานข้อมูลที่เราออกแบบเอง

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

น่าสังเกต: input_img , raw_hm_img และ overlaid_img เป็นภาพที่เข้ารหัส base64 ซึ่งจัดเก็บเป็นสตริง uae_feats และ bbsd_feats เป็นอาร์เรย์ของฟีเจอร์การฝังสำหรับอัลกอริธึมการตรวจจับดริฟท์ของเรา

การแก้ไขปัญหา

• หากคุณเผชิญกับ ImportError: /lib/aarch64-linux-gnu/libGLdispatch.so.0: cannot allocate memory in static TLS block ให้ลอง export LD_PRELOAD=/lib/aarch64-linux-gnu/libGLdispatch.so.0 จากนั้นรันใหม่ สคริปต์