Kiến trúc mới cho các ứng dụng LLM
(a16z.com)- Kiến trúc tham chiếu cho "ngăn xếp ứng dụng LLM" được a16z tổng hợp
Emerging LLM App Stack
Contextual Data
- Data Pipelines: Databricks, Airflow, Unstructured,..
- Embedding Model: OpenAI, Cohere, Hugging Face
- Vector Database: Pinecone, Weaviate, Chroma, pgvector
Prompt Few-shot Examples
- Playground: OpenAI, nat.dev, Humanloop
- Orchestration: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
- APIs/Plugins: Serp, Wolfram, Zapier,...
Query & Output
- App Hosting: Vercel, Steamship, Streamlit, Modal
- LLM Cache: Redis, SQLite, GPTCache
- Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
- Validation: Guardrails, Rebuff, Guidance, LMQL
LLM APIs and Hosting
- Proprietary API: OpenAI, Anthropic
- Open API: Hugging Face, Replicate
- Cloud Provider: AWS, GCP, Azure, Coreweave
- Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...
Design Pattern: In-context Learning
- In-Context Learning: sử dụng nguyên trạng LLM mà không fine-tuning, thay vào đó dùng prompt thông minh và các điều kiện dựa trên một phần dữ liệu "contextual"
- Ví dụ: khi tạo chatbot trả lời về các tài liệu pháp lý, cách làm ngây thơ là đưa toàn bộ tài liệu vào ChatGPT rồi đặt câu hỏi, nhưng cách này chỉ khả thi với tập dữ liệu nhỏ. Ngay cả model lớn nhất của ChatGPT cũng chỉ xử lý được khoảng 50 trang
Trong In-Context Learning, chỉ các tài liệu liên quan mới được gửi đi và câu trả lời được lấy từ đó - Vì vậy, nó được cấu thành từ quy trình làm việc 3 bước như sau
- Step 1. tiền xử lý dữ liệu / embedding
- Step 2. tạo prompt / truy xuất tài liệu liên quan từ vector DB
- Step 3. thực thi prompt / suy luận
- Trông có vẻ nhiều việc, nhưng vẫn dễ hơn rất nhiều so với việc huấn luyện và fine-tuning chính LLM
Step 1. [Data preprocessing / embedding]
→ Contextual Data đi qua Data Pipeline, sau đó qua Embedding Model rồi được lưu vào Vector Database
Contextual Data
- Tài liệu văn bản, PDF, CSV và các bảng SQL
- Phần lớn việc nạp và chuyển đổi dữ liệu vẫn dùng nguyên các công cụ ETL sẵn có (Databricks, Airflow)
- Một phần sử dụng document loader tích hợp trong các framework orchestration như LangChain, LlamaIndex
- Tác giả cho rằng phần này của stack vẫn còn tương đối kém phát triển, và vẫn có cơ hội cho các giải pháp sao chép dữ liệu được xây riêng cho ứng dụng LLM
Embeddings
- Phần lớn nhà phát triển sử dụng OpenAI API (model
text-embedding-ada-002)- Dễ dùng, cho kết quả đủ tốt một cách hợp lý, và ngày càng rẻ hơn
- Một số công ty lớn đang thử nghiệm Cohere. Nó cho hiệu năng tốt hơn trong một số kịch bản cụ thể
- Các nhà phát triển ưa chuộng mã nguồn mở xem thư viện Sentence Transformers của Hugging Face là tiêu chuẩn
- Ngoài ra còn có thể tạo nhiều loại embedding khác nhau phù hợp với từng use case
- Đây là mảng ngách nhưng là lĩnh vực nghiên cứu đầy hứa hẹn
Vector Database
- Phần quan trọng nhất trong pipeline tiền xử lý là vector database
- Nó đảm nhiệm việc lưu trữ, so sánh và tìm kiếm hiệu quả tối đa hàng chục tỷ embedding (vector)
- Lựa chọn phổ biến nhất trên thị trường là Pinecone
- Được host hoàn toàn trên cloud nên rất dễ bắt đầu
- Có nhiều tính năng mà doanh nghiệp lớn cần cho production (hiệu năng tốt, SSO, SLA uptime, v.v.)
- Tuy nhiên, số lượng vector database khả dụng là rất lớn. Đặc biệt là:
- Mã nguồn mở như Weaviate, Vespa, Qdrant
- Cung cấp hiệu năng đơn nút rất tốt và có thể tinh chỉnh theo từng ứng dụng cụ thể
- Phổ biến với các đội AI giàu kinh nghiệm thích tự xây nền tảng tùy biến
- Các thư viện quản lý vector cục bộ như Chroma, Faiss
- Trải nghiệm nhà phát triển rất tốt
- Dễ vận hành cho ứng dụng nhỏ và thử nghiệm phát triển
- Không nhằm thay thế cơ sở dữ liệu quy mô lớn hoàn chỉnh
- Các extension OLTP như pgvector
- Là giải pháp tốt để bổ sung hỗ trợ vector cho những nhà phát triển muốn nhét mọi nhu cầu cơ sở dữ liệu vào Postgres hoặc cho các doanh nghiệp mua phần lớn hạ tầng dữ liệu từ một nhà cung cấp cloud duy nhất
- Về lâu dài, chưa rõ việc ghép chặt vector workload với scalar workload có thực sự hợp lý hay không
- Mã nguồn mở như Weaviate, Vespa, Qdrant
- Nhìn xa hơn, phần lớn các công ty vector database mã nguồn mở đang phát triển sản phẩm cloud
- Theo nghiên cứu của tác giả, việc đạt hiệu năng xuất sắc trên cloud cho nhiều use case khác nhau là rất khó
- Vì vậy, các lựa chọn này có thể chưa thay đổi trong ngắn hạn, nhưng khả năng cao sẽ thay đổi về dài hạn
- Câu hỏi cốt lõi là liệu vector database có hợp nhất thành một hoặc hai hệ thống nổi tiếng như trường hợp OLTP & OLAP hay không
- Một câu hỏi khác là embedding và vector database sẽ phát triển như thế nào khi context window khả dụng trong hầu hết model ngày càng lớn hơn
- Có thể bị cám dỗ để nói rằng embedding sẽ không còn cần thiết vì có thể đưa toàn bộ dữ liệu ngữ cảnh vào prompt,
- Nhưng phản hồi từ các chuyên gia cho thấy pipeline embedding có thể sẽ ngày càng quan trọng hơn
- Context window lớn là công cụ mạnh mẽ nhưng đi kèm chi phí tính toán đáng kể. Vì vậy ưu tiên là sử dụng nó một cách hiệu quả
- Giờ đây ta sẽ thấy nhiều loại embedding model khác nhau được phổ biến rộng rãi, được huấn luyện trực tiếp với tính liên quan theo model, cùng các vector database có thể kích hoạt và khai thác chúng hiệu quả
Step 2. [Prompt construction / retrieval]
- Chiến lược tích hợp LLM prompting với dữ liệu phù hợp theo ngữ cảnh đang ngày càng phức tạp và ngày càng quan trọng như một nguồn tạo khác biệt sản phẩm
- Phần lớn nhà phát triển bắt đầu dự án mới bằng prompt đơn giản gồm chỉ dẫn trực tiếp (zero-shot prompting) hoặc kèm một vài ví dụ (few-shot prompting)
- Những prompt này đôi khi cho kết quả tốt, nhưng chưa đạt mức độ chính xác cần thiết để triển khai production
- Bước tiếp theo của prompting là thiết kế để câu trả lời của model có cơ sở từ một nguồn sự thật nào đó, đồng thời cung cấp ngữ cảnh bên ngoài mà model chưa được huấn luyện
- Prompt Engineering Guide tổng hợp 12 chiến lược prompting nâng cao
- Đây là lúc các framework orchestration như LangChain/LlamaIndex tỏa sáng
- Chúng trừu tượng hóa nhiều chi tiết của prompt chaining
- Bao gồm tích hợp API bên ngoài, tìm kiếm dữ liệu ngữ cảnh trong vector database, duy trì bộ nhớ giữa nhiều lần gọi LLM, v.v.
- Đồng thời cung cấp template cho nhiều chương trình phổ biến
- Đầu ra của chúng là prompt hoặc nhiều prompt để gửi tới language model
- Trong giới startup và lập trình viên sở thích, LangChain được dùng nhiều nhất
- LangChain vẫn là dự án còn mới (phiên bản hiện tại 0.0.220)
- Nhưng đã bắt đầu xuất hiện các ứng dụng production dùng nó
- Một số nhà phát triển, đặc biệt là những người dùng LLM sớm, thích chuyển sang Python thuần trong production để loại bỏ phụ thuộc
- Tuy nhiên tác giả cho rằng cách DIY này sẽ dần giảm đi, giống như trong web app stack (đa số rồi cũng sẽ dùng framework)
- Những độc giả tinh ý có thể đã thấy ChatGPT nằm trong ô orchestration
- Thông thường ChatGPT là ứng dụng chứ không phải công cụ cho nhà phát triển, nhưng có thể truy cập qua API
- Ở một góc độ nào đó, nó thực hiện các hành vi tương tự các framework orchestration này (trừu tượng hóa prompt, duy trì trạng thái, tìm kiếm dữ liệu ngữ cảnh qua plugin, v.v.)
- Dù không phải đối thủ cạnh tranh trực tiếp với các công cụ ở đây, ChatGPT có thể được xem như một giải pháp thay thế. Nó có thể là lựa chọn đơn giản để cấu hình và sử dụng nhanh chóng
Step 3. [Prompt execution / inference]
- Hiện tại OpenAI là bên dẫn đầu trong các language model
- Gần như mọi nhà phát triển đều bắt đầu xây ứng dụng LLM với GPT-4 và GPT-4-32k
- Chúng dễ dùng, áp dụng được cho nhiều lĩnh vực và không cần fine-tuning hay self-hosting
- Khi đi vào production và mở rộng quy mô, nhiều lựa chọn khác nhau trở nên khả thi
- Chuyển sang
gpt-3.5-turbo:- Rẻ hơn hơn 50 lần và nhanh hơn GPT-4 rất nhiều
- Phù hợp khi không cần độ chính xác ở mức GPT-4, khi cần thời gian phản hồi nhanh hoặc cần hỗ trợ người dùng miễn phí với chi phí hiệu quả
- Thử nghiệm model của nhà cung cấp khác (đặc biệt là model Claude của Anthropic)
- Claude cung cấp suy luận nhanh, độ chính xác ở mức GPT-3.5, nhiều tùy chọn tùy biến hơn và context window lên đến 100k (nhưng độ chính xác giảm khi quá dài)
- Chuyển hướng một số request sang model mã nguồn mở
- Có thể hiệu quả với các use case B2C quy mô lớn như tìm kiếm/chat, nơi độ phức tạp truy vấn rất đa dạng hoặc cần phục vụ người dùng miễn phí với chi phí thấp
- Chuyển sang
- Các model mã nguồn mở hiện vẫn đang đuổi theo các sản phẩm độc quyền, nhưng khoảng cách đã bắt đầu thu hẹp
- Model LLaMA của Meta đã đặt ra tiêu chuẩn mới về độ chính xác của mã nguồn mở và kéo theo nhiều biến thể khác nhau
- LLaMA chỉ được cấp phép cho nghiên cứu, nhưng nhiều nhà cung cấp đã tham gia huấn luyện các base model thay thế (Together, Mosaic, Falcon, Mistral)
- Meta đang được cho là thảo luận để phát hành model LLaMa 2 mã nguồn mở thực sự
- Nếu LLM mã nguồn mở đạt độ chính xác tương đương GPT-3.5, ta có thể kỳ vọng một "Stable Diffusion Moment" cho văn bản
- Thử nghiệm quy mô lớn, chia sẻ, đưa các model fine-tuned vào production, v.v.
- Các công ty hosting như Replicate đã bổ sung công cụ để giúp nhà phát triển dùng các model này dễ dàng hơn
- Niềm tin của nhà phát triển rằng các model nhỏ hơn nhưng được fine-tuning có thể đạt độ chính xác ngang các model tối tân đang ngày càng tăng
- Phần lớn nhà phát triển mà tác giả trao đổi cùng chưa đi quá sâu vào các công cụ vận hành cho LLM
- Caching là phổ biến, thường dùng Redis (vì cải thiện thời gian phản hồi và chi phí)
- Các công cụ như Weights & Biases, MLFlow, PromptLayer, Helicone cũng được dùng nhiều
- Có thể log, theo dõi và đánh giá đầu ra LLM để tạo prompt nhanh hơn, tinh chỉnh pipeline và chọn model
- Các công cụ kiểm chứng đầu ra LLM (Guardrails) hoặc phát hiện prompt injection (Rebuff) cũng đang xuất hiện nhiều
- Phần lớn các công cụ vận hành này khuyến nghị dùng Python client riêng để thực hiện gọi LLM, vì vậy cũng sẽ rất thú vị khi theo dõi cách chúng cùng tồn tại về sau
- Cuối cùng, phần tĩnh của LLM (mọi thứ ngoài model) cũng cần được host ở đâu đó
- Giải pháp phổ biến nhất là Vercel hoặc các nhà cung cấp cloud lớn
- Tuy nhiên đang xuất hiện hai danh mục mới
- Steamship cung cấp hosting end-to-end cho ứng dụng LLM, bao gồm các tính năng như orchestration (LangChain), data context đa tenant, tác vụ bất đồng bộ, vector store, quản lý khóa, v.v.
- Anyscale và Modal cho phép nhà phát triển host đồng thời model và mã Python
Còn Agent thì sao?
- Yếu tố quan trọng nhất còn thiếu trong kiến trúc tham chiếu này là AI Agent Framework
- AutoGPT là "thử nghiệm mã nguồn mở nhằm biến GPT-4 thành hoàn toàn tự chủ" và đã là GitHub repo tăng trưởng nhanh nhất trong lịch sử vào mùa xuân năm nay
- Ngày nay, hầu như mọi dự án AI đều có agent dưới một hình thức nào đó
- Phần lớn nhà phát triển mà tác giả trò chuyện cùng đều rất hào hứng với tiềm năng của agent
- Mô hình in-context learning được mô tả trong bài này hỗ trợ tốt hơn cho các tác vụ tạo nội dung, đồng thời giúp giải quyết vấn đề hallucination và độ mới của dữ liệu
- Trong khi đó, agent mang đến những khả năng mới mang tính nền tảng cho ứng dụng AI
- Giải quyết vấn đề phức tạp, thực hiện hành động với thế giới bên ngoài, hoặc học hỏi từ trải nghiệm ngay cả sau khi triển khai
- Chúng làm điều này thông qua sự kết hợp của suy luận/lập kế hoạch nâng cao, sử dụng công cụ, memory/recursion/self-reflection, v.v.
- Agent có thể trở thành phần trung tâm trong kiến trúc ứng dụng LLM (nếu tin vào việc tự cải thiện nhờ đệ quy, thậm chí có thể chiếm toàn bộ stack)
- Các framework như LangChain đã tích hợp khái niệm agent
- Chỉ có một vấn đề: agent vẫn chưa thực sự hoạt động tốt
- Hiện phần lớn agent framework vẫn đang ở giai đoạn PoC - có thể tạo demo ấn tượng nhưng chưa ổn định hoặc tái lập được
- Tác giả đang tiếp tục theo dõi cách chúng phát triển
Nhìn về phía trước
- Các model AI được pretrain là thay đổi kiến trúc quan trọng nhất của phần mềm kể từ Internet
- Nhờ đó, mỗi nhà phát triển đều có thể xây trong vài ngày những ứng dụng AI vượt qua các dự án machine learning supervised mà các đội lớn phải mất hàng tháng để thực hiện
- Các công cụ và mẫu thiết kế được giới thiệu ở đây có lẽ không phải trạng thái cuối cùng, mà nhiều khả năng chỉ là điểm khởi đầu cho việc tích hợp LLM
6 bình luận
Đây là một bài viết cho thấy chiều sâu và góc nhìn sắc sảo.
Có vẻ nó sẽ là trợ giúp rất lớn khi thiết kế kiến trúc ứng dụng LLM dựa trên nội dung này.
Vì trong hệ sinh thái vẫn chưa có người chiến thắng rõ ràng theo từng lĩnh vực nên hiện có rất nhiều giải pháp đang cùng tồn tại lẫn lộn,
khiến vấn đề lựa chọn trở nên nhiều hơn, và dường như đây là thời điểm mà khả năng tìm ra tổ hợp phù hợp với yêu cầu của bạn trở thành một năng lực quan trọng.
Bài này thật sự rất đầy đặn. Tôi đang đọc kỹ từng chút một.
Nếu cho LLM học GN thì Guru-nim cũng sẽ đỡ vất vả hơn chăng? ^^;
Xin cảm ơn.
À, ra là bạn đã tạo GN+ rồi :-o
Có vẻ sẽ tiện hơn thật, nhưng mình chắc vẫn sẽ tiếp tục đọc những bài như thế này như một cách để học. haha
Nếu GN⁺ xử lý hết các tin khác, cũng có thể tạo ra hiệu ứng là những bài như thế này sẽ còn nhiều hơn nữa!
Cảm ơn vì bài viết và phần tóm tắt rất hay.