Trải qua hai năm chuyển đổi số cho sản phẩm hiện có và phát triển sản phẩm AI gốc từ đầu, nhóm kỹ thuật đã gặp nhiều thách thức đáng kể. Dưới đây là tổng hợp kinh nghiệm thực tế.

1. Góc độ sản phẩm

1.1 Tích hợp vào quy trình làm việc sẵn có

Việc thuyết phục người dùng nội bộ chấp nhận công cụ mới đã khó, chưa nói đến việc yêu cầu khách hàng chi trả để học cách sử dụng công cụ hoàn toàn mới. Khi bạn chỉ ra rằng "công cụ AI có thể tối ưu 30% thời gian ở khâu X trong quy trình hiện tại", khách hàng mới thực sự quan tâm. Chỉ khi người dùng quen thuộc với lợi ích từ việc áp dụng AI ở từng bước nhỏ, họ mới sẵn sàng thử nghiệm các tính năng phức tạp hơn.

Vấn đề này sẽ giảm dần khi thị trường được tiếp cận công nghệ nhiều hơn, nhưng thời điểm cụ thể vẫn chưa thể xác định.

1.2 Định hình kỳ vọng thực tế

Sản phẩm chúng tôi phát triển là trợ lý mã nguồn chuyên dụng cho phần mềm mô phỏng kỹ thuật, sử dụng mô hình LLM được huấn luyện chuyên sâu cho ngôn ngữ DSL đặc thù. Trong khi LLM hiện đại có thể xử lý tốt cấp độ hàm/chức năng, việc sinh toàn bộ dự án có cấu trúc (Spring/Django/React) với logic nghiệp vụ hoàn chỉnh vẫn chưa khả thi - thậm chí không đảm bảo biên dịch thành công.

Khách hàng không quan tâm đến giới hạn công nghệ, họ chỉ đánh giá sản phẩm qua kết quả đầu ra. Do đó, cần làm rõ ngay từ đầu: đây là công cụ hỗ trợ chứ không phải thay thế kỹ sư mô phỏng. Việc này ảnh hưởng trực tiếp đến chiến lược giá và tiếp thị sản phẩm.

2. Yếu tố kỹ thuật

2.1 Tránh phụ thuộc vào tiến hóa mô hình cơ sở

Khi OpenAI ra mắt mô hình o1 với khả năng suy luận chuỗi ấn tượng, chúng tôi đã phát triển giải pháp dựa trên thư viện g1 để mô phỏng tính năng này. Tuy nhiên, khi các mô hình mã nguồn mở nhanh chóng tích hợp sẵn reasoning, toàn bộ nỗ lực phát triển riêng trở nên dư thừa. Bài học: Nên tập trung vào giải pháp ứng dụng thay vì xây dựng lại tính năng nền tảng.

2.2 Đánh giá kỹ độ trưởng thành của thư viện

Hai vấn đề tiêu biểu tốn nhiều thời gian khắc phục:

• Debug API phức tạp của LangChain
• Triển khai vLLM trong môi trường offline với yêu cầu bảo vệ bản quyền mô hình

2.3 Tận dụng dữ liệu chuyên ngành

Có hai hướng tiếp cận chính:

2.3.1 Huấn luyện mô hình
Cần lưu ý rủi ro: Việc fine-tune mô hình cơ sở (SFT/continue pre-train) thường làm suy giảm khả năng tổng quát. Cần tính toán kỹ lưỡng để đảm bảo lợi ích mang lại cao hơn chi phí.

2.3.2 Xử lý ngữ cảnh
Tổ chức dữ liệu đầu vào ảnh hưởng trực tiếp đến hiệu suất:

• Nguồn dữ liệu: RAG (vector search), CSDL quan hệ (thông qua MCP), biểu thức chính quy, hoặc đồ thị tri thức
• Cấu trúc dữ liệu: Tùy thuộc vào mô hình và ngữ cảnh triển khai

Ví dụ minh họa cách định dạng JSON cho Ollama:

cau_hinh = {
    'ten_mau': ten_mau,
    'dia_chi_api': dia_chi_api,
    'do_ngau_nhien': do_ngau_nhien,
}
if yeu_cau_json:
    cau_hinh['dinh_dang'] = 'json'  # Cấu hình bắt buộc

client = OllamaChat(**cau_hinh)

Trong khi đó, với vLLM cần sử dụng Pydantic để định nghĩa cấu trúc:

class ThuocTinhPhuongTien(BaseModel):
    loai: str = Field(..., description="Mã thiết bị quân sự")
    phe: str = Field(..., pattern="^(do|xanh|trung_lap|trang)$")
    loai_phuong_tien: str = Field(..., description="air/ship/ground")
    chi_huy: str = None

# Gọi API với response_format cụ thể
client.create(
    messages=prompt,
    response_format=ThuocTinhPhuongTien
)

Lưu ý: Với mô hình Qwen3:30b trong môi trường offline, cần mô tả chi tiết kiểu dữ liệu từng trường trong prompt, khác với cách tiếp cận đơn giản hơn khi dùng Claude 3.7 Sonnet qua API.