kbot3是一款支持以oracle为底座的知识库产品。前端APEX，后端Python。

本文分享一次常见的问题诊断，kbot3 中新增的模型开始进入测试阶段。但在 APEX 前端点击 LLM 配置的 Test 按钮时，请求 /api/model/test 返回 500，前端提示：AxiosError: Request failed with status code 500。

这类问题表面是接口 500，实际往往要顺着前端请求、主服务查询、下游服务查询一路看参数是否一致。

01 | 问题现象

APEX 前端点击 LLM 配置的 Test 按钮，请求 /api/model/test，返回 500。

已确认 APEX 侧鉴权正常，如果前后端联通有问题，会报错 401，此外，前后端没问题，页面右上角的锁头会是绿色。

继续排查500问题，发现当前请求体只发送了两个字段：

• model_id
• model_category

也就是说，APEX page 43 的 JS 没有发送 app_id。

后端主服务会先按 model_id 查询 kbot_md_models，这一步是正常的。随后 llm-service 会继续按 display_name + app_id 查询模型配置。

从 v$sql_bind_capture 抓到的实际绑定值是：

• display_name = deepseek-v4-flash
• app_id = 1

但数据库中这条模型记录实际为：

• app_id = 1001
• category = 1

当同名模型被临时复制一份到 app_id = 1 后，测试不再报 “not found”。

02 | 根因判断与排查方向

和后端研发同事确认：数据库没有找到记录，本质是因为 base 配置文件中需要配置 APEX 的应用程序 ID 才可以读到，例如：

app_id=1001

结合实际链路中的参数表现，还可以看到一个明显信号：llm-service 查询时拿到的 app_id=1，正好说明需要参数指定这个apex应用程序ID值。

DB中捕获到的 SQL 形态如下：

SELECT ... FROM kbot_md_models
WHERE kbot_md_models.display_name = :display_name_1
AND kbot_md_models.app_id = :app_id_1

绑定值为：

:DISPLAY_NAME_1 = deepseek-v4-flash
:APP_ID_1 = 1

这次排查的关键点是：不要只看 500 本身，而要把接口请求体、数据库记录、SQL 绑定值放在一起对齐。当前问题的核心不是模型不存在，而是后续查询使用了错误的 app_id，导致同名模型在目标应用下查不到。而正确的ID只需要设置一个后端的参数来指定即可，笔者认为，这也是合理的设计，因为apex程序导入支持指定不同的ID，后端需要适配实际的app_id，这样反而更灵活。

关注我，和AI一起成长~