fix: improve numeric knowledge retrieval ranking

[EDDIWARD]

Summary

This revision keeps the Bug2 fix intentionally lightweight: when the caller has not configured a hybrid-search weight, digit-containing queries use a higher accurate-search weight. Explicit caller weights are preserved.

The previous numeric phrase boost and extra exact-query processing have been removed.

Root cause

For an identifier-like query such as an alert number or IP address, semantic ranking can place a nearby-but-wrong record above the requested record. In the original flow, searching alert 01999 returned 记录01699.

Change

• SDK hybrid search: use 0.7 accurate-search weight for digit-containing queries only when weight_accurate is omitted; non-numeric queries retain the SDK default of 0.3.
• REST hybrid-search endpoint: retain its ordinary-query default of 0.5; use 0.7 only for digit-containing queries with no explicit weight.
• Frontend: omit weight_accurate when the user has not configured it, so the backend/SDK can select the appropriate default.
• No index mapping changes, no additional Elasticsearch requests, and no numeric phrase boost.

Before

With the same reproduction knowledge base and alert-number query for 01999, the agent reported the unrelated 记录01699.

After

With the lightweight routing enabled, the first retrieved result and final answer are the requested 记录01999.

Validation

• Focused SDK regression suite: 106 passed.
• Manual local reproduction using DeepSeek-V4-Flash and the same 1,999-row alert knowledge base: 01999 now retrieves 记录01999 first.
• Additional identifier checks (00001, 01000, 01500, 01999, and 192.168.19.33) improved from the former 0.3 default to the intended record with the adaptive 0.7 weight.
• Explicit caller weights and non-numeric default behavior are covered by regression tests.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[WMC001]

if weight_accurate is not None 能否改成 if weight_accurate，这样更简单易懂，等于0也不会影响判断