AI-Meeting: Spring Boot 3 backend for AI mock interviews with multi-agent scoring and real-time ASR

What AI-Meeting builds and who it is written for

AI-Meeting is the server-side half of Mashan Interview (码上面试), a platform for simulated technical interview practice backed by large-language-model APIs. The back-end is built on Spring Boot 3.4.4 and Java 17, with Spring AI 1.0.0 providing the model abstraction layer. Five concerns are handled by separate modules: AI conversation with multi-model support, agent-based sessions, mock interviews with multi-turn scoring, real-time speech-to-text, and long-text voice synthesis.

The README directly addresses who this project is for. It targets two groups: developers who want a worked example of Spring AI integration with production-adjacent patterns, and developers who need a portfolio project with enough architectural complexity to discuss in a job interview. A dedicated "resume writing" section explains how to describe each engineering decision on a CV. That is an unusual inclusion for an open-source library, and it makes the scope explicit: this is a learning reference, not a product.

The front-end repository is separate, at github.com/lishuangqiang/AI-Meeting-Frontend, and is built on React 19.2 and TypeScript 5.9. The back-end and front-end are developed and deployed independently.

The five-agent mock interview pipeline and LiteFlow rule chain

The mock interview module coordinates five agents hosted on the Xingyun workflow platform: a question-generator agent, a questioner agent, a scorer agent, a follow-up decider, and a facial-expression analyzer. When a candidate uploads a PDF resume, the question-generator agent parses it, produces structured interview questions, and returns a resume score and suggestions. After the candidate answers a question, the scorer agent returns a score and feedback for that answer. The LiteFlow rule chain then evaluates whether a follow-up question is warranted and dispatches the follow-up decider accordingly.

Concurrency across multiple JVM instances is handled by a distributed single-flight mechanism. Any given evaluation request (scoring, follow-up decision, question draw, or facial analysis) executes only once across the cluster per answer round. Results are cached for replay; failure types are classified separately from timeouts so that retry logic applies to the right error category.

At the end of an interview, the pipeline writes a structured record: a per-question trace with the original question, the candidate's answer, the score and the feedback; a multi-dimensional radar chart score; and an AI summary. Facial analysis adds a separate channel that evaluates camera screenshots and contributes to the overall score.

Setting up the stack: filling .env.example before Docker Compose starts

The .env.example at the repository root lists every configuration value Docker Compose requires. Copy it to .env and fill in credentials before starting. The minimum required values are the AI model credentials and the four iFlytek keys:

SPRING_AI_OPENAI_API_KEY=your-openai-api-key
SPRING_AI_OPENAI_BASE_URL=https://api.openai.com
SPRING_AI_OPENAI_MODEL=gpt-4o-mini
XUNFEI_APP_ID=
XUNFEI_API_KEY=
XUNFEI_API_SECRET=
XUNFEI_RTA_API_KEY=

The default value for `MYSQL_PASSWORD` in .env.example is 123456. Change it before running. Docker Compose brings up MySQL 8.4, MongoDB 7.0 and Redis 7.2 alongside the application container. The back-end image uses a multi-stage Dockerfile: the build stage runs maven:3.9.11-eclipse-temurin-17, and the runtime stage is eclipse-temurin:17-jre-jammy. The final container runs under a non-root user named `xunzhi` and exposes port 8002, not the default Spring Boot port 8080.

To run the Maven build and tests locally without Docker, use the wrapper:

./mvnw -B -ntp clean verify

This mirrors what the GitHub Actions CI workflow at .github/workflows/backend-ci.yml checks: Maven build, JDK 17 baseline, and metadata validation.

MongoDB for session snapshots, Redis for live state: why the project needs both

Session state in the mock interview module lives in two layers. Redis holds the live running state: it is read and updated on every evaluation pass and queried to check the current status of pending requests. MongoDB holds periodic state snapshots; each one records enough context to resume an interview from the last confirmed state.

The recovery path is what justifies both databases. If Redis fails or restarts mid-interview, the application reads the latest MongoDB snapshot on reconnection and replays forward from that point. An interview in progress survives a Redis outage that would terminate it if the project used Redis alone.

Two consistency mechanisms protect concurrent writes. CAS (compare-and-swap) at the Redis layer prevents simultaneous writes from corrupting session state. An async compensation path handles CAS failures caused by timeouts or network partitions: a background process retries the failed write with an idempotent key, so the compensation does not apply the same state change twice. This combination is what the project calls the basis for "interrupt recovery" support in long sessions.

Real-time ASR via iFlytek WebSocket and the TreeMap segment deduplication

The speech-to-text module opens a JSR 356 `@ServerEndpoint` WebSocket connection per session. Binary audio frames arrive from the client browser and are passed to iFlytek's AST service. iFlytek returns segmented results in overlapping windows; each result carries a `seg_id`, a `pgs` flag, and `rg` / `bg` / `ed` position markers that describe the segment boundaries.

Without deduplication, those overlapping windows produce repeated text or delete the beginning of earlier segments. The implementation uses a TreeMap keyed by `seg_id` to order received segments. Entries identified as overlapping by the `pgs` flag are removed before the text is assembled. Three text variants are maintained per session in parallel: `committedText` (finalized segments), `liveText` (the current incomplete segment) and `displayText` (what the UI renders). Keeping three separate streams prevents the prefix-deletion artifact that appears when a single text buffer is updated in place during overlapping segment delivery.

The long-text TTS module integrates iFlytek's async interface in three modes: create-and-poll, synchronous wait, and status-check only. Voice, speed, volume and audio encoding format are configurable.

Dependencies the project cannot work without: iFlytek credentials and the Xingyun platform

AI-Meeting has two external dependencies that have no documented substitution path. First, the speech module requires four iFlytek credentials (`XUNFEI_APP_ID`, `XUNFEI_API_KEY`, `XUNFEI_API_SECRET`, `XUNFEI_RTA_API_KEY`) for AST and TTS. These are commercial credentials from iFlytek, a Chinese AI voice company. If these are absent, the ASR and TTS features do not work, and the facial-analysis agent also uses iFlytek's service.

Second, the five-agent interview pipeline depends on workflow IDs from the Xingyun platform (星辰大模型工作流). A developer without a Xingyun account cannot run the mock interview flow without replacing the agent integration layer.

LangChain4j is the main Java alternative for AI application development. It provides explicit chain, agent and memory abstractions modeled after the Python LangChain library. Spring AI, which AI-Meeting uses, follows Spring Boot's autoconfiguration model instead: models are wired as Spring beans via starters, which integrates into an existing Spring application without additional abstractions, but exposes fewer built-in agent primitives than LangChain4j. Teams already deep in the Spring ecosystem will find Spring AI a lower-friction path; teams building agent-first applications may prefer LangChain4j's more explicit tooling.

Port 8002, MIT legal terms, and the pending security cleanup the README flags

The back-end container exposes port 8002; reverse proxy configurations and firewall rules must reference that port rather than 8080. AI-Meeting is MIT licensed; the repository has no GitHub releases, and the last push was on 2026-08-03.

The README contains a section titled "发布说明" (Release Notes) that explicitly warns: "The current repository still retains the development configuration structure; true key desensitization and final security cleanup before public release will be handled separately in subsequent phases." This is a direct flag to audit configuration files before deploying any fork. The .env.example with `MYSQL_PASSWORD=123456` as the default is one example of the development-phase defaults the note refers to. Anyone cloning this project for use beyond local learning should audit the configuration files, the SQL init scripts mounted at docker-compose startup, and any stored credentials before exposing the application to external traffic.

Editorial conclusion

AI-Meeting is a good fit for Java developers studying Spring AI, distributed session patterns, or multi-agent orchestration on a project complex enough to discuss in a technical interview. It is not ready for production deployment: the README explicitly states that configuration files still contain development-phase structure and security cleanup has not been completed. Before cloning and deploying, verify that iFlytek AST and TTS credentials are available and that the team has access to the Xingyun workflow platform the mock interview pipeline requires. Check the Dockerfile's JAVA_OPTS default of `-Xms512m -Xmx2g` if the target host has limited memory.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lishuangqiang/AI-Meeting on GitHub
4. README