Key takeaways
I am building SatsunicGo so customers can ask about a product, work out the costs, and continue with a purchase request in the same conversation. Ask is still being improved, especially around context and knowledge. This is a look at the product and the design I am working from.English · Tiếng Việt bên dưới
Taking one of my AI projects all the way
After a lot of AI experiments, unfinished prototypes, and more burned tokens than I would like to count, I wanted to take one personal product all the way: build it, put it in front of customers, run the service, and see whether it can earn real money.
That product is SatsunicGo. It is a shopping and purchase assistance service for people in Vietnam who want to buy from the US, Japan, or Korea. I am working toward its rollout now, and sharing the design while I work through the parts that still need attention.
One thing I kept thinking about was how much a customer has to figure out before buying. They find an item they like, then look for the right service page, read the shipping policy, fill in a form, and message someone about the details. If they change the size or quantity, the conversation starts moving back and forth again.
On HunpeoLabs.com, I built Ask Anything so visitors could ask about me and my work. With SatsunicGo, I wanted to take that idea further. Someone should be able to say what they need, ask a few questions, and continue with the purchase from the same place.
SatsunicGo during development. Ask sits alongside the usual pages for products, fees, and purchase assistance.
“Can you help me buy this?”
A customer might have a link and know exactly what they want: “Can you get these shoes from the US? I usually wear size 38.” Someone else might be buying for their family: “What milk would you suggest for my mum? She's over sixty.” Or: “My child is four. Do you have any calcium supplements that are easy to take?”
People ask like that. They do not always know the product name, the right category, or which page will answer their question. I want Ask to be useful from that first sentence.
Take the shoes. The customer can ask about the size, the purchase process, and the cost of getting them to Vietnam. If they decide to go ahead, Ask should help collect the remaining details and show the request for them to check. If they say, “Actually, get two pairs,” it should carry that change forward without making them explain the whole thing again.
The same goes for “How much for two bottles, including shipping?” or “Has my order from last week reached Vietnam?” A customer should not have to know which part of the system holds the answer.
With skincare or supplements, I want the conversation to help people read product information and work out what they still need to ask. Questions about treating freckles or giving a supplement to a child need care; Ask should leave medical advice to a doctor or pharmacist.
A look at the Ask panel: product results appear inside the conversation. I am building out the steps that follow.
Getting from a conversation to an actual request
This is where the project gets interesting for me. Answering a question is one thing. Helping someone submit the right request, with the right item and quantity, takes quite a bit more work.
A customer may ask several questions before deciding, change their mind halfway through, or come back later. The product needs to keep track of that without losing the details. Before anything is submitted, they should be able to see what they are sending and confirm it.
Then there is the work behind the screen: reviewing the request, quoting, purchasing, checking the goods, packing, and shipping. Those steps still have to happen. Ask gives the customer an easier way into that process and a way to ask what is happening along the way.
I am keeping the important distinctions clear in the implementation. A prepared request is still a draft until the customer submits it. A payment is confirmed by the payment system. Order progress comes from the order record. Those details matter when the conversation involves someone's money.
The Lego pieces behind Ask
This is the design I am working from. It includes the pieces I have started building and the ones I plan to add as the product grows.
The architecture I am building toward for SatsunicGo Ask Anything.
I think of it as a few Lego pieces that need to fit together. The LLM helps make sense of a question. Knowledge gives it the product and service information to work with. Tools let it look something up or help prepare the next step. The application checks the customer's access and handles the actual business action.
So when someone asks where their order is, Ask needs to look up their order. When they ask about shipping, it needs the relevant fee policy, and it needs to say when the team still has to provide a quote. I want the answer to come from something the service can stand behind.
Confirmations are part of that design too. If a customer approves one pair of shoes, that approval cannot quietly become permission to order two. When the details change, the customer gets to check them again.
I also need to keep the runner under control: a limit on steps, time, and model usage; a way to stop; and a record of what happened. If a lookup fails, the conversation should say so and leave the customer with a sensible next step.
Ask still needs work
At the moment, Ask can still be a little clumsy. It sometimes misses what I mean, asks an unnecessary question, or gets too much background to work with. Context and knowledge retrieval are taking a lot of my attention.
Chunking is a good example. Suppose a shipping policy gives a rate, followed by a condition about which goods it applies to. If I split those into separate chunks and retrieve only the rate, the model is missing half the story. The answer may read well, but the customer could walk away with the wrong expectation.
I am working on how to keep useful sections together, find the relevant ones, and preserve their sources. I also need to distinguish information that can sit in the knowledge collection from information that changes. A service explanation can be retrieved from a document; an order's status needs a fresh lookup.
For longer chats, older discussion can be summarised. The item being selected, a draft request, and a pending confirmation still need to be stored properly by the application. I do not want a long conversation to lose the thing the customer came to do.
And no, I am not using a vector DB yet. I am starting with a small, bounded knowledge collection and targeted retrieval, keeping the first version simple and the costs manageable. I will add semantic retrieval when I can see what it would improve. There is plenty to get right with the pieces already on the table.
Next: put it in front of people
My first priority is to make the everyday tasks dependable: finding a product, understanding the fees, preparing a purchase request, confirming it, and checking an order. I want to see where people get stuck and what they ask that I have not thought of.
Later, the customer activity part of the design could help the team spot questions that come up repeatedly or places where people give up. That needs its own work around permitted data and privacy. For now, I am focused on making Ask useful enough that someone can get through their shopping task without having to repeat themselves.
I am looking forward to this part. A prototype gives me something to try; running the product will give me a lot more to learn. SatsunicGo is the first personal applied AI product I am taking toward that kind of rollout.
If you are building something similar, feel free to message me. I would be happy to compare notes on fitting the LLM, knowledge, and tools together—and on the bits that only start causing trouble after the demo. 🙂
Tiếng Việt — Lần này mình muốn làm tới nơi
Sau một thời gian thử AI, làm đủ kiểu bản nháp và đốt token như rơm, mình muốn chọn một dự án cá nhân để làm tới nơi: code xong, đưa ra cho khách dùng, tự vận hành và xem có kiếm được tiền thật không.
Dự án đó là SatsunicGo, một website mua hàng và mua hộ từ Mỹ, Nhật, Hàn về Việt Nam. Mình đang hoàn thiện để triển khai trong thời gian tới. Nhân lúc thiết kế đã rõ hơn, mình chia sẻ một chút về sản phẩm, cách mình đang ghép các phần với nhau và những chỗ vẫn còn phải sửa.
Khi làm, mình hay nghĩ tới chuyện rất bình thường: một người thấy món đồ mình thích và muốn mua. Nhưng để mua được, họ lại phải tìm trang dịch vụ, đọc cách tính phí, điền form, rồi nhắn hỏi thêm. Đổi size, thêm số lượng hay chưa rõ tiền gửi hàng thì lại qua lại vài lượt nữa.
Trước đây, mình làm Ask Anything trên HunpeoLabs.com để mọi người hỏi về mình và những gì mình đang làm. Với SatsunicGo, mình muốn đi thêm một đoạn: khách hỏi xong, thấy hợp thì có thể tiếp tục nhờ mua, chuẩn bị yêu cầu và theo dõi việc đó ngay trong cuộc trò chuyện.
Giao diện SatsunicGo mình đang làm. Ask nằm cạnh các trang sản phẩm, biểu phí và mua hộ quen thuộc.
Khách chỉ muốn hỏi: “Mua giúp mình cái này được không?”
Có người đưa sẵn link rồi hỏi: “Đôi này mua bên Mỹ được không? Mình hay đi size 38.” Có người mua cho người nhà: “Mua sữa cho mẹ ngoài sáu mươi thì chọn loại nào?” Hoặc: “Bé nhà mình bốn tuổi, có loại canxi nào dễ uống không?”
Người ta hỏi như vậy. Không phải ai cũng biết tên sản phẩm, biết nó thuộc mục nào, hay biết phải vào trang nào để tìm câu trả lời. Mình muốn Ask bắt đầu giúp được từ chính những câu đó.
Lấy chuyện đôi giày làm ví dụ. Khách có thể hỏi size, hỏi mua hộ thế nào, hỏi tính cả tiền về Việt Nam thì hết khoảng bao nhiêu. Nếu muốn mua, Ask hỏi thêm phần còn thiếu rồi hiện lại yêu cầu để khách kiểm tra. Khách nói “À lấy hai đôi nhé” thì sửa tiếp trên việc đang làm, đỡ phải kể lại từ đầu.
Những câu như “Hai chai này gửi về hết bao nhiêu?” hay “Đơn tuần trước của mình về tới đâu rồi?” cũng vậy. Khách không cần biết hệ thống chia dữ liệu ở đâu. Họ chỉ cần hỏi được và nhận câu trả lời có ích.
Với những câu hỏi về đồ trị tàn nhang, vitamin hay canxi cho trẻ nhỏ, mình muốn Ask giúp khách đọc thông tin sản phẩm và biết còn điều gì cần hỏi thêm. Chuyện điều trị hoặc dùng gì cho trẻ vẫn cần bác sĩ, dược sĩ tư vấn khi phù hợp.
Một góc Ask hiện tại: tìm sản phẩm và xem kết quả ngay trong chat. Mình đang hoàn thiện các bước tiếp theo từ đây.
Từ hỏi chuyện đến gửi được yêu cầu mua hàng
Đây là đoạn mình thấy thú vị, cũng là đoạn tốn công. Trả lời một câu hỏi thì còn tương đối dễ. Giúp khách gửi đúng món, đúng size, đúng số lượng lại là chuyện khác.
Khách có thể hỏi vài câu mới quyết định, đổi ý giữa chừng hoặc hôm sau quay lại. Sản phẩm cần giữ được những chi tiết đó. Tới lúc gửi yêu cầu, khách phải nhìn lại được mình đang gửi gì và xác nhận rồi mới đi tiếp.
Sau màn hình vẫn còn việc của đội vận hành: xem yêu cầu, báo giá, mua hàng, kiểm hàng, đóng gói và gửi về. Mình muốn Ask giúp khách đi vào quy trình này dễ hơn, rồi có chỗ để hỏi tiếp khi cần biết tình hình.
Những việc liên quan tới đơn và tiền thì phải rõ. Chuẩn bị xong bản nháp chưa phải đã gửi yêu cầu. Thanh toán phải có kết quả từ hệ thống thanh toán. Hỏi đơn hàng thì phải xem dữ liệu của đơn đó. Mình đang giữ những mốc này trong cách triển khai, để khách biết việc của mình thực sự đang tới đâu.
Lắp mấy cục Lego phía sau ô chat
Đây là thiết kế mình đang làm theo, gồm những phần đã bắt đầu xây và những phần sẽ bổ sung dần khi sản phẩm lớn hơn.
Kiến trúc mình đang hướng tới cho Ask Anything của SatsunicGo.
Mình hình dung như lắp Lego. Cục LLM hiểu khách đang hỏi gì. Cục knowledge đưa thông tin sản phẩm và dịch vụ cho nó đọc. Tools giúp tra cứu hoặc chuẩn bị việc tiếp theo. Còn ứng dụng kiểm tra khách được xem gì và xử lý thao tác thực tế.
Ví dụ hỏi “đơn mình tới đâu?” thì phải đi lấy đơn của đúng người đang hỏi. Hỏi phí gửi hàng thì phải tìm đúng biểu phí; chỗ nào còn cần đội vận hành báo giá thì nói rõ. Mình muốn câu trả lời có thông tin để đối chiếu, để khách dùng nó mà quyết định được.
Xác nhận cũng là một phần của thiết kế. Khách đã duyệt một đôi giày thì không thể tự nhiên thành hai đôi. Sửa thông tin thì cho khách xem và xác nhận lại.
Agent runner còn cần giới hạn số bước, thời gian, mức dùng model, có cách dừng và ghi lại những gì đã làm. Nếu tra cứu lỗi thì nói chỗ đó chưa xem được, để khách biết nên làm gì tiếp. Mấy phần này làm demo thì dễ bỏ qua, nhưng đưa ra dùng thật là phải tính.
Ask vẫn còn hơi ngáo, mình đang sửa tiếp
Hiện Ask chưa tự nhiên như mình muốn. Có lúc hiểu lệch ý, hỏi lại điều không cần hỏi, hoặc được nhét quá nhiều thông tin nên trả lời lan man. Mình đang dành khá nhiều thời gian cho context và cách lấy knowledge.
Chẳng hạn chunking. Một đoạn trong bảng phí ghi mức tiền, ngay dưới là điều kiện áp dụng. Nếu cắt hai phần ra xa nhau rồi chỉ lấy được mức tiền, LLM đã thiếu mất nửa câu chuyện. Nó vẫn có thể viết rất trôi chảy, nhưng khách lại hiểu sai.
Mình đang sửa cách chia tài liệu, giữ những phần cần đọc cùng nhau ở gần nhau và tìm đúng đoạn cho câu hỏi. Nguồn của thông tin cũng phải giữ lại. Mô tả dịch vụ có thể lấy từ tài liệu; trạng thái đơn thì phải tra dữ liệu mới. Hai thứ đó cần xử lý khác nhau.
Chat dài cũng có chuyện của nó. Phần trao đổi cũ có thể tóm tắt, nhưng món khách đang chọn, bản nháp đang sửa và việc đang chờ xác nhận thì ứng dụng phải lưu cho chắc. Mình không muốn nói chuyện một hồi rồi mất dấu việc khách đang cần làm.
À, mình chưa dùng vector DB. Bản đầu có lượng knowledge còn gọn, nên mình bắt đầu với cách tìm thông tin đơn giản, giới hạn phạm vi và kiểm soát chi phí. Khi thấy tìm kiếm theo ngữ nghĩa giúp giải được vấn đề cụ thể nào thì mình thêm. Những cục đang có cũng còn đủ việc để làm rồi. 😄
Sắp tới là đưa ra cho khách dùng
Trước mắt, mình muốn làm chắc những việc khách hay cần: tìm món hàng, hỏi phí, chuẩn bị yêu cầu mua hộ, xác nhận và xem đơn. Đưa ra dùng rồi mới biết khách mắc ở đâu, hay hỏi gì mà mình chưa nghĩ tới.
Phần customer behavior ở cuối sơ đồ là hướng mình muốn làm sau đó. Nếu khách cứ hỏi đi hỏi lại một khoản phí, hoặc nhiều người dừng ở cùng một bước, đội vận hành có thêm thông tin để xem nên sửa gì. Phần này cần làm riêng, tính tới quyền sử dụng dữ liệu và riêng tư của khách.
Còn lúc này, mình tập trung làm Ask đủ hữu ích để khách hỏi, hiểu và tiếp tục mua hàng mà bớt phải tự lần mò. Đồng thời phải xem một lượt hỗ trợ như vậy tốn bao nhiêu, có vận hành lâu dài được không.
Mình khá mong tới đoạn này. Làm nháp thì có thứ để thử; làm sản phẩm cho người khác dùng sẽ có thêm rất nhiều thứ để học. SatsunicGo là dự án applied AI cá nhân đầu tiên mình muốn đi tới một đợt triển khai và kinh doanh thật như vậy.
Anh em đang làm sản phẩm tương tự thì nhắn mình trao đổi chơi. Mình thích nghe chuyện ghép LLM, knowledge với tools, và cả những chỗ demo chạy ngon mà tới lúc dùng thật mới bắt đầu đấm đá nhau. 🙂
In closing
I am building SatsunicGo so customers can ask about a product, work out the costs, and continue with a purchase request in the same conversation. Ask is still being improved, especially around context and knowledge. This is a look at the product and the design I am working from.
Sources
Discussion
Newest firstLoading comments…
Spam checks run automatically. Some comments may be held for review.