Tự build AI bot và những thứ mình học được về Generative AI

Có một giai đoạn mình cứ đọc paper về LLM, xem demo ChatGPT, rồi gật gù "ừ hay đấy" nhưng thực ra chẳng hiểu gì sâu cả. Cái cảm giác đó giống như đọc docs của một thư viện mà chưa bao giờ chạy thử một dòng code. Cho đến khi mình quyết định tự build một AI bot từ đầu, mọi thứ mới bắt đầu click.

Không phải bot xịn hay gì đâu chỉ là một chatbot đơn giản tích hợp với OpenAI API, có thêm một chút context về domain cụ thể. Nhưng chính cái quá trình đó mới là thứ dạy mình nhiều nhất.

Generative AI không phải là "tra Google thông minh hơn"

Trước khi build, mình nghĩ LLM về cơ bản là một search engine siêu xịn bạn hỏi, nó tìm, rồi trả lời. Sai hoàn toàn.

Generative AI sinh ra text dựa trên xác suất. Mỗi token được predict dựa trên context phía trước, không phải lookup từ một database cố định. Điều này giải thích tại sao model có thể viết thơ, generate code, hay thậm chí hallucinate một cách rất tự tin vì nó đang "đoán" cái gì có khả năng đúng nhất, chứ không phải "nhớ" một câu trả lời chính xác.

Khi mình debug cái bot của mình và thấy nó trả lời sai một thông tin rất cơ bản, mình mới thực sự hiểu điều này. Model không biết nó sai nó chỉ đang làm đúng việc của nó là predict token tiếp theo.

Prompt là code, không phải là câu hỏi

Đây là cái mình underestimate nhất lúc mới bắt đầu. Mình cứ nghĩ prompt chỉ là "hỏi cho rõ ràng" là xong. Thực ra prompt engineering phức tạp hơn nhiều, và nó ảnh hưởng trực tiếp đến output quality.

Một vài thứ mình học được qua thực tế:

System prompt quyết định "tính cách" của bot. Nếu bạn không define rõ role, tone, và constraints trong system prompt, model sẽ tự suy ra và thường không phải thứ bạn muốn. Mình mất cả buổi chiều để tune system prompt cho bot không bị "quá formal" khi trả lời câu hỏi kỹ thuật.

Few-shot examples mạnh hơn instruction. Thay vì viết "hãy trả lời ngắn gọn và technical", mình thêm 2-3 ví dụ Q&A mẫu vào prompt output ngay lập tức consistent hơn hẳn.

Temperature và các parameter khác không phải decoration. Temperature cao → creative nhưng unpredictable. Temperature thấp → deterministic nhưng có thể boring. Với bot support kỹ thuật, mình để temperature khoảng 0.3-0.4, còn nếu build creative writing tool thì có thể đẩy lên 0.8-0.9.

Context window cái bẫy mà ai cũng gặp

Mình build bot với tính năng "nhớ lịch sử conversation" và gặp ngay vấn đề này. Sau một hồi chat, bot bắt đầu "quên" những gì được nói ở đầu cuộc trò chuyện, hoặc tệ hơn là bị confused bởi quá nhiều context.

Vấn đề là context window có giới hạn (tính bằng tokens), và khi conversation dài, bạn phải quyết định cái gì được giữ lại, cái gì bị drop. Đây là lúc mình hiểu tại sao các production chatbot cần có conversation summarization, memory management, hay RAG (Retrieval-Augmented Generation).

Mình implement một giải pháp đơn giản: giữ lại N message gần nhất + một summary của phần conversation trước. Không hoàn hảo, nhưng đủ để bot hoạt động reasonable trong hầu hết use case.

Theo kinh nghiệm của mình, đây là một trong những chỗ mà nhiều người build chatbot hay bỏ qua lúc đầu cứ thấy demo ngắn chạy ngon là xong, đến khi user thực sự dùng mới phát hiện vấn đề.

RAG không phải magic, nhưng nó rất thực dụng

Bot của mình cần trả lời câu hỏi về một domain cụ thể (internal docs của team). Mình có hai lựa chọn: fine-tune model, hoặc dùng RAG. Mình chọn RAG vì đơn giản hơn nhiều để setup và maintain.

Flow cơ bản:

1. Chunk documents thành các đoạn nhỏ
2. Embed chúng thành vector và lưu vào vector database (mình dùng Chroma vì free và easy)
3. Khi user hỏi, embed câu hỏi → tìm các chunk relevant nhất → nhét vào prompt cùng với câu hỏi
4. Model trả lời dựa trên context được cung cấp

Cái hay của RAG là model không cần "biết" thông tin trước bạn cung cấp cho nó real-time. Nhưng cũng có trade-off: chất lượng phụ thuộc nhiều vào quality của retrieval. Nếu tìm sai chunk, model sẽ trả lời dựa trên thông tin sai hoặc không liên quan.

Mình mất khá nhiều thời gian để tune chunking strategy chunk quá nhỏ thì mất context, chunk quá lớn thì retrieval kém precision. Cuối cùng settle với overlapping chunks (mỗi chunk 512 tokens, overlap 50 tokens) và kết quả khá ổn.

Hallucination không thể loại bỏ hoàn toàn, chỉ có thể giảm thiểu

Cái này mình phải accept sau một thời gian. Không có cách nào làm model không bao giờ hallucinate bản chất của generative model là vậy. Nhưng có một số kỹ thuật giúp giảm đáng kể:

• Grounding với retrieved context: Thay vì để model tự trả lời từ training data, cung cấp context cụ thể và yêu cầu model chỉ dùng thông tin đó.
• Explicit uncertainty instruction: Trong system prompt, mình thêm "nếu bạn không chắc chắn, hãy nói rõ" không hoàn toàn loại bỏ hallucination nhưng model bắt đầu hedge nhiều hơn.
• Output validation: Với các thông tin critical (số liệu, dates, tên cụ thể), mình add một bước verify trước khi show ra user.

Anh em lưu ý: đừng trust blindly vào output của model trong production, đặc biệt với domain-specific knowledge. RAG giúp nhiều, nhưng vẫn cần có layer validation phù hợp.

Latency và cost hai thứ dễ bị ignore lúc prototype

Khi build demo, mình không quan tâm mấy đến latency. Nhưng khi thực sự cho người dùng thử, phản hồi sau 3-5 giây mỗi lần là trải nghiệm không tốt chút nào.

Một số thứ mình làm để cải thiện:

• Streaming response: Thay vì đợi full response rồi mới show, stream từng token ra ngay cảm giác nhanh hơn nhiều dù total latency không đổi
• Cache common queries: Một số câu hỏi lặp lại nhiều, cache response lại thay vì call API mỗi lần
• Model selection: GPT-4 xịn hơn GPT-3.5 nhưng chậm hơn và đắt hơn ~10-20x. Với nhiều use case, GPT-3.5 hoặc các model nhỏ hơn là đủ

Về cost, mình bị shock lần đầu xem bill API sau một tuần test. Tokens cộng dồn nhanh hơn bạn nghĩ, đặc biệt khi có RAG context dài. Mình phải implement token counting và set hard limit để tránh surprise.

Thứ mình không ngờ: UX quan trọng không kém gì model

Bot của mình technically hoạt động tốt, nhưng user feedback ban đầu không như kỳ vọng. Vấn đề không phải ở model mà ở cách mình present thông tin.

Một số cải thiện nhỏ nhưng impact lớn:

• Thêm loading indicator với streaming
• Format response tốt hơn (markdown rendering, code blocks)
• Suggest follow-up questions để guide user
• Clear error messages thay vì generic "có lỗi xảy ra"

Generative AI mạnh đến đâu cũng cần một UX tốt để người dùng thực sự thấy giá trị. Đây là thứ mình thấy nhiều demo AI bỏ qua cứ focus vào model capability mà quên mất người dùng cuối.

Nhìn lại, cái project nhỏ đó dạy mình nhiều hơn hàng chục bài blog về Generative AI mà mình từng đọc. Không phải vì nó phức tạp mà vì khi tự tay build, bạn buộc phải đối mặt với những vấn đề thực tế mà tutorial không bao giờ cover hết.

Nếu bạn đang muốn hiểu sâu hơn về Generative AI, mình thực sự recommend: đừng chỉ đọc hãy build một cái gì đó, dù nhỏ. Bạn sẽ học được nhiều thứ mà không có paper nào dạy được.