Những tiến bộ gần đây trong AI là rất thú vị. Mọi người đang sử dụng nó theo mọi cách mới lạ, từ trải nghiệm hỗ trợ khách hàng, mã, đến nhạc mới và thậm chí công nghệ hình ảnh y tế. cải thiện viết và chạy tạo tăng tốc Nhưng trong quá trình này, một xu hướng đáng lo ngại đã xuất hiện: cộng đồng AI dường như đang phát minh lại chuyển động dữ liệu (hay còn gọi là ETL). Cho dù họ gọi chúng là trình kết nối, trình trích xuất, tích hợp, trình tải tài liệu hay cái gì khác, thì mọi người đang viết cùng một mã để trích xuất dữ liệu từ cùng một API, định dạng tài liệu và cơ sở dữ liệu, sau đó tải chúng vào DB vector hoặc chỉ mục cho LLM của họ. Vấn đề là việc xây dựng và duy trì các đường ống khai thác và tải mạnh mẽ từ đầu là một cam kết rất lớn. Và có quá nhiều nghệ thuật trước đây trong lĩnh vực đó đối với hầu hết các kỹ sư hoặc công ty trong lĩnh vực AI, việc xây dựng lại nó là một sự lãng phí rất lớn về thời gian. Trong một không gian mà tin nóng hổi xuất hiện gần như mỗi giờ, trọng tâm chính nên là làm cho sản phẩm cốt lõi của bạn trở nên đáng kinh ngạc đối với người dùng, chứ không phải thực hiện các nhiệm vụ phụ. Và đối với hầu hết mọi người, sản phẩm cốt lõi không phải là chuyển động dữ liệu; đó là nước sốt ma thuật do AI cung cấp mà bạn đang pha chế. Rất nhiều điều đã được viết ( , ) về những thách thức liên quan đến việc xây dựng các quy trình Trích xuất, Chuyển đổi và Tải (ETL) mạnh mẽ, nhưng hãy bối cảnh hóa nó trong AI. 1 2 Tại sao AI cần chuyển động dữ liệu? LLM được đào tạo về dữ liệu công khai là tuyệt vời, nhưng bạn biết điều gì thậm chí còn tốt hơn không? AI có thể trả lời các câu hỏi dành riêng cho chúng tôi, công ty của chúng tôi và người dùng của chúng tôi. Tất cả chúng tôi đều thích nếu ChatGPT có thể tìm hiểu toàn bộ wiki của công ty chúng tôi, đọc tất cả email, tin nhắn Slack, ghi chú cuộc họp và bản ghi, cắm vào môi trường phân tích của công ty chúng tôi và sử dụng tất cả các nguồn này khi trả lời câu hỏi của chúng tôi. Hoặc khi tích hợp AI vào sản phẩm của chính chúng tôi (ví dụ: với Notion AI , chúng tôi muốn mô hình AI của ứng dụng biết tất cả thông tin chúng tôi có về người dùng khi trợ giúp họ. ) Di chuyển dữ liệu là điều kiện tiên quyết cho tất cả điều đó. Cho dù bạn đang tinh chỉnh một mô hình hay Thế hệ tăng cường truy xuất (RAG), bạn cần trích xuất dữ liệu từ bất cứ nơi nào nó tồn tại, chuyển đổi nó thành định dạng mà mô hình của bạn có thể tiêu hóa được, sau đó tải nó vào kho dữ liệu mà ứng dụng AI của bạn có thể truy cập để phục vụ trường hợp sử dụng của bạn. sử dụng Sơ đồ trên minh họa điều này trông như thế nào khi sử dụng RAG, nhưng bạn có thể tưởng tượng rằng ngay cả khi bạn không sử dụng RAG, các bước cơ bản sẽ không thay đổi: bạn cần Trích xuất, Chuyển đổi và Tải dữ liệu hay còn gọi là ETL để xây dựng các mô hình AI biết thông tin riêng tư dành riêng cho bạn và trường hợp sử dụng của bạn. Tại sao di chuyển dữ liệu khó? Xây dựng một MVP chức năng cơ bản để trích xuất dữ liệu từ API hoặc cơ sở dữ liệu thường – mặc dù không phải lúc nào – cũng có thể thực hiện được khi có thông báo nhanh (<1 tuần). Phần thực sự khó khăn là làm cho nó sẵn sàng sản xuất và giữ nguyên như vậy. Hãy xem xét một số thách thức tiêu chuẩn xuất hiện trong đầu khi xây dựng đường ống khai thác. Chiết khấu gia tăng và quản lý nhà nước Nếu bạn có bất kỳ khối lượng dữ liệu có ý nghĩa nào, bạn sẽ cần triển khai trích xuất gia tăng sao cho quy trình của bạn chỉ trích xuất dữ liệu mà nó chưa thấy trước đây. Để làm được điều này, bạn cần có một lớp kiên trì để theo dõi dữ liệu mà mỗi kết nối đã trích xuất. Xử lý lỗi tạm thời, dự phòng, tiếp tục khi lỗi, lỗ hổng không khí Nguồn dữ liệu ngược dòng mọi lúc, đôi khi không có lý do rõ ràng. Các quy trình của bạn cần phải linh hoạt với điều này và thử lại với các chính sách dự phòng phù hợp. Nếu lỗi không phải là tạm thời (nhưng vẫn không phải lỗi của bạn) thì quy trình của bạn cần phải đủ linh hoạt để ghi nhớ nơi nó đã dừng lại và tiếp tục từ cùng một nơi sau khi sửa lỗi ngược dòng. Và đôi khi, vấn đề đến từ thượng nguồn đủ nghiêm trọng (chẳng hạn như API loại bỏ một số trường quan trọng khỏi bản ghi) khiến bạn muốn tạm dừng toàn bộ quy trình cho đến khi bạn kiểm tra điều gì đang xảy ra và quyết định việc cần làm theo cách thủ công. Xác định & chủ động sửa lỗi cấu hình Nếu bạn đang xây dựng các quy trình trích xuất dữ liệu để trích xuất dữ liệu của khách hàng, thì bạn sẽ cần thực hiện một số kiểm tra phòng thủ để đảm bảo rằng tất cả cấu hình mà khách hàng đã cung cấp cho bạn để trích xuất dữ liệu thay mặt họ là chính xác và nếu không, hãy nhanh chóng cung cấp cho họ thông báo lỗi có thể hành động. Hầu hết các API không làm điều này dễ dàng vì chúng không công bố các bảng lỗi toàn diện và ngay cả khi chúng làm vậy, chúng hiếm khi cung cấp cho bạn các điểm cuối mà bạn có thể sử dụng để kiểm tra các quyền được gán cho ví dụ: mã thông báo API, vì vậy bạn phải tìm cách cân bằng toàn diện kiểm tra với phản hồi nhanh chóng cho người dùng. Xác thực & quản lý bí mật Các API có phạm vi đơn giản từ xác thực mã thông báo mang đơn giản đến triển khai “sáng tạo” của mã thông báo phiên hoặc OAuth mã thông báo sử dụng một lần. Bạn sẽ cần triển khai logic để thực hiện xác thực cũng như quản lý các bí mật có thể được làm mới mỗi giờ một lần, có khả năng điều phối các lần làm mới bí mật trên nhiều nhân viên đồng thời. Tối ưu hóa tốc độ trích xuất & tải, đồng thời và giới hạn tốc độ Và nói về các công nhân đồng thời, bạn có thể sẽ muốn triển khai đồng thời để đạt được thông lượng cao cho quá trình trích xuất của mình. Mặc dù điều này có thể không quan trọng đối với các tập dữ liệu nhỏ, nhưng nó cực kỳ quan trọng đối với các tập dữ liệu lớn hơn. Mặc dù các API công bố giới hạn tốc độ chính thức, nhưng theo kinh nghiệm, bạn sẽ cần tìm ra các tham số song song tốt nhất để tăng tối đa giới hạn tốc độ mà API cung cấp cho bạn mà không khiến IP bị đưa vào danh sách đen hoặc bị giới hạn tốc độ vĩnh viễn. Thích ứng với các thay đổi API ngược dòng Các API luôn thay đổi và tiếp nhận các hành vi hoặc hành vi không có giấy tờ mới. Nhiều nhà cung cấp xuất bản các phiên bản API mới hàng quý. Bạn sẽ cần theo dõi xem tất cả các bản cập nhật này có thể ảnh hưởng đến công việc của bạn như thế nào và dành thời gian kỹ thuật để cập nhật tất cả. Các điểm cuối mới luôn xuất hiện và một số thay đổi hành vi của chúng (và không phải lúc nào bạn cũng được thông báo trước). Lập kế hoạch, giám sát, ghi nhật ký và khả năng quan sát Ngoài mã trích xuất dữ liệu từ các API cụ thể, bạn cũng có thể cần xây dựng một số khả năng theo chiều ngang được tất cả các trình trích xuất dữ liệu của bạn tận dụng. Bạn sẽ muốn có một số lịch trình cũng như ghi nhật ký và giám sát khi lịch trình không hoạt động hoặc khi có sự cố khác xảy ra và bạn cần phải điều tra. Bạn cũng có thể muốn có một số khả năng quan sát, chẳng hạn như có bao nhiêu bản ghi được trích xuất ngày hôm qua, hôm nay, tuần trước, v.v... và chúng đến từ điểm cuối API hoặc bảng cơ sở dữ liệu nào. Chặn hoặc băm dữ liệu Tùy thuộc vào nơi bạn lấy dữ liệu từ đó, bạn có thể cần một số tính năng bảo mật để chặn hoặc băm cột trước khi gửi chúng xuống hạ lưu. Rõ ràng, điều trên không áp dụng nếu bạn chỉ muốn di chuyển một vài tệp như một việc một lần. Nhưng nó áp dụng khi bạn đang xây dựng các sản phẩm yêu cầu di chuyển dữ liệu. Sớm hay muộn, bạn sẽ cần phải giải quyết hầu hết các mối quan tâm này. Và mặc dù không có công việc nào trong số đó là khoa học tên lửa không thể vượt qua, nhưng khi kết hợp chúng lại với nhau, chúng có thể nhanh chóng tạo thành một hoặc nhiều công việc toàn thời gian, hơn nữa, bạn càng thu được nhiều nguồn dữ liệu hơn. Và đó chính xác là khó khăn trong việc duy trì khai thác dữ liệu & đường ống: phần lớn chi phí của nó đến từ khoản đầu tư gia tăng liên tục cần thiết để giữ cho các đường ống đó hoạt động và mạnh mẽ. Đối với hầu hết các kỹ sư AI, đó không phải là công việc mang lại nhiều giá trị nhất cho người dùng của họ. Thời gian của họ được dành tốt nhất ở nơi khác. Vậy một kỹ sư AI phải làm gì để di chuyển một số dữ liệu quanh đây? Nếu bạn thấy mình cần khai thác dữ liệu và tải đường ống, hãy thử các giải pháp đã có sẵn thay vì tự động xây dựng giải pháp của riêng bạn. Rất có thể họ có thể giải quyết rất nhiều nếu không muốn nói là tất cả các mối quan tâm của bạn. Nếu không, xây dựng của riêng bạn như là một phương sách cuối cùng. Và ngay cả khi các nền tảng hiện có không hỗ trợ mọi thứ bạn cần, bạn vẫn có thể đạt được hầu hết các cách đó với một khung di động và có thể mở rộng. Bằng cách này, thay vì xây dựng mọi thứ từ đầu, bạn có thể hoàn thành 90% công việc với các tính năng có sẵn trong nền tảng và chỉ xây dựng và duy trì 10% cuối cùng. Ví dụ phổ biến nhất là tích hợp đuôi dài: nếu nền tảng không cung cấp tích hợp với API mà bạn cần, thì một nền tảng tốt sẽ giúp bạn dễ dàng viết một số mã hoặc thậm chí là giải pháp không cần mã để xây dựng tích hợp đó và vẫn nhận được tất cả các tính năng hữu ích được cung cấp bởi nền tảng. Ngay cả khi bạn muốn sự linh hoạt của việc chỉ nhập trình kết nối dưới dạng gói python và kích hoạt nó theo cách bạn muốn từ mã của mình, bạn có thể sử dụng một trong nhiều công cụ EL nguồn mở như trình kết nối Airbyte hoặc Singer. Để rõ ràng, chuyển động dữ liệu không được giải quyết hoàn toàn. Có những tình huống mà các giải pháp hiện có thực sự thiếu sót và bạn cần xây dựng các giải pháp mới. Nhưng đây không phải là phần lớn dân số kỹ thuật AI. Hầu hết mọi người không cần phải xây dựng lại các tích hợp giống nhau với Jira, Confluence, Slack, Notion, Gmail, Salesforce, v.v... nhiều lần. Hãy chỉ sử dụng các giải pháp đã được thử nghiệm thực tế và mở cho mọi người sử dụng để chúng ta có thể tiếp tục bổ sung giá trị mà người dùng của chúng ta thực sự quan tâm. Cũng xuất hiện . ở đây

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

AI không cần lãng phí thời gian để phát minh lại ETL

dài quá đọc không nổi

John Lafleur

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Vested Interest

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...