跪拜 Guibai
← All articles
Backend · Java · AI Programming

A 3-Day AI Customer Service Agent with Spring AI 1.0 and DeepSeek

By 卷毛的技术笔记 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Spring AI 1.0's GA release makes RAG and tool-calling accessible inside a standard Spring Boot stack without learning a separate AI framework. The 62% auto-resolution figure and the fallback-to-human pattern give teams a concrete benchmark for what a first-pass internal agent can actually deliver, not a demo.

Summary

A customer service team drowning in 800 daily tickets got a working AI agent in three days using Spring AI 1.0's GA release. The system combines RAG over company PDFs stored in Redis with Function Calling that lets the model query live order databases by extracting order numbers from chat. A hard fallback rule prevents hallucination: when the knowledge base lacks an answer, the agent refuses to guess and auto-escalates to a human. After one week, the agent handles 520 tickets per day with a 62% auto-resolution rate, cutting average response time from 15 minutes to 3 seconds and lifting satisfaction from 72% to 83%. The remaining 38% of tickets—complex complaints and refunds—still route to people. The build exposed practical gotchas: chunk size tuning for document retrieval, temperature dialed down to 0.3 for consistent answers, slim DTOs to avoid token bloat in function returns, and a local queue to handle DeepSeek API rate limits.

Takeaways
A 500-token chunk size for document splitting produced far more coherent retrieval than 200-token chunks, which fragmented context and caused out-of-context answers.
Lowering the model temperature to 0.3 stabilized responses for customer service; the default 0.7 gave different answers to the same question.
Function Calling return values must be slim DTOs—returning a full 50-field entity blew up token usage and confused the model.
A hard system-prompt rule that forces the agent to refuse unknown questions and trigger a human handoff eliminated hallucination-driven complaints.
DeepSeek API rate limits during peak traffic were absorbed by adding a local queue for peak shaving, keeping costs around 200-300 RMB/month for 500+ daily calls.
Redis-backed ChatMemory preserved conversation context across restarts; the default in-memory implementation lost state on reboot.
Knowledge base cleanup—removing outdated 2019 policies and duplicate document versions—improved answer accuracy more than any model tuning.
Conclusions

The 62% auto-resolution rate came from a straightforward RAG + Function Calling setup, not a complex multi-agent architecture, suggesting that clean knowledge bases and hard fallback rules matter more than framework sophistication for internal tools.

Spring AI 1.0's GA stability was the deciding factor over LangChain4j for this team—not feature set, but API stability and zero-integration cost with existing Spring Boot monitoring and config.

The biggest accuracy gain came from spending half a day cleaning the knowledge base, not from prompt engineering or model selection, reinforcing that document quality is the bottleneck in most enterprise RAG deployments.

Concepts & terms
RAG (Retrieval-Augmented Generation)
A pattern where a user query first retrieves relevant documents from a knowledge base, then feeds both the query and those documents to a large language model so it can ground its answer in provided facts rather than its training data.
Function Calling
A capability where an LLM recognizes a user's intent, extracts structured parameters from natural language, and invokes a developer-defined function (such as a database query), then incorporates the returned data into its response.
ChatMemory
A component that stores conversation history so an AI agent can reference earlier messages in the same session, enabling multi-turn dialogue where later questions depend on prior context.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗