feat: Auto-adjust chunk recall weights based on user feedback

[MkDev11]

What problem does this PR solve?

Implements automatic adjustment of knowledge base chunk recall weights based on user feedback (upvotes/downvotes). When users upvote or downvote a response, the system locates the corresponding knowledge snippets and adjusts their recall weight to improve future retrieval quality.

Closes #12670

How it works:

1. User upvotes/downvotes a response via POST /thumbup
2. System extracts chunk IDs from the conversation reference
3. For each referenced chunk:
   • Reads current pagerank_fea value from document store
   • Increments (+1) for upvote or decrements (-1) for downvote
   • Clamps weight to [0, 100] range
   • Updates chunk in ES/Infinity/OceanBase
4. Future retrievals score these chunks higher/lower based on accumulated feedback

Files changed:

• api/db/services/chunk_feedback_service.py - New service for updating chunk pagerank weights
• api/apps/conversation_app.py - Integrated feedback service into thumbup endpoint
• test/testcases/test_web_api/test_chunk_feedback/ - Unit tests

Type of change

• New Feature (non-breaking change which adds functionality)

[KevinHuSh]

Appreciations!
Boosting some certain of chunks' pagerank score by thumbuping some conversation sessions, I don't know, might cause some side effects in one way or another.
Pagerank score is a very sensitive score, once these chunks are up, they're probabaly to be on top anyway. Unless we have a lot of users and the feadback data is dense enough.

[MkDev11]

@KevinHuSh Thanks for your feedback! You raise valid concerns about pagerank sensitivity.

I've added safeguards to address this:

1. Feature is disabled by default - requires CHUNK_FEEDBACK_ENABLED=true to activate, so no impact unless explicitly opted in
2. Reduced weight increments from 1 to 0.1 - a single vote now has 10x less impact, requiring many votes before meaningfully affecting rankings

This way, deployments with sparse feedback won't see unintended side effects, while those with dense user activity can opt in and benefit from the learning signal. Happy to adjust the increment further or add additional safeguards (like requiring N votes before applying, or time-based decay) if you think it's needed.

[MkDev11]

@ZhenhangTung could you please let your members review the PR?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.52%. Comparing base (b1d28b5) to head (303222c).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12689      +/-   ##
==========================================
- Coverage   96.72%   96.52%   -0.21%     
==========================================
  Files          10       10              
  Lines         703      690      -13     
  Branches      112      108       -4     
==========================================
- Hits          680      666      -14     
- Misses          5        8       +3     
+ Partials       18       16       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[yingfeng]

Thanks, please fix the CI error:

==================================== ERRORS ====================================
_ ERROR collecting test/testcases/test_web_api/test_chunk_feedback/test_chunk_feedback_service.py _
ImportError while importing test module '/home/infiniflow/runners_work/inf29-ac7fd0784ffe/ragflow/ragflow/test/testcases/test_web_api/test_chunk_feedback/test_chunk_feedback_service.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/home/alice/.local/share/uv/python/cpython-3.12.12-linux-x86_64-gnu/lib/python3.12/importlib/__init__.py:90: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
test/testcases/test_web_api/test_chunk_feedback/test_chunk_feedback_service.py:21: in <module>
    from api.db.services.chunk_feedback_service import (
api/db/services/__init__.py:19: in <module>
    from .user_service import UserService as UserService
api/db/services/user_service.py:24: in <module>
    from api.db.db_models import DB, UserTenant
api/db/db_models.py:53: in <module>
    from api.utils.configs import deserialize_b64, serialize_b64
api/utils/configs.py:21: in <module>
    from common.config_utils import get_base_config
E   ModuleNotFoundError: No module named 'common.config_utils'; 'common' is not a package
=========================== short test summary info ============================
ERROR test/testcases/test_web_api/test_chunk_feedback/test_chunk_feedback_service.py
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
======================= 176 deselected, 1 error in 1.61s =======================

[MkDev11]

@KevinHuSh @yingfeng sorry to bother you, can you let me know what I need to fix or update?

[yingfeng]

This design feels a bit simplistic; we might want to explore a feedback-driven weighting approach instead.

[MkDev11]

@yingfeng can you review the changes again?

[MkDev11]

@yingfeng @Magicbook1108 can you help me finish the PR?

[yingfeng]

Waiting for a PR on the Infinity issue to be resolved. This PR hasn't yet applied the necessary changes to Infinity, which will serve as a built-in retrieval engine going forward.

To update a single row in Infinity, the internal _row_id is required—a field that is currently absent from Infinity's response. Once that PR is submitted, you can proceed with applying the thumb updating logic to Infinity as well.

[MkDev11]

which PR do you mean?

[yingfeng]

which PR do you mean?

#13901

Please note that _row_id can be obtained from the retrieval results returned by Infinity. You can use chunk_id to retrieve the corresponding _row_id, and then use this _row_id to update the specific row.

However, if multiple users attempt to update the same chunk concurrently, only one operation will succeed. This is because a successful update modifies the _row_id associated with that chunk_id, while other users are still using the now-stale old _row_id. The Python code should handle this scenario gracefully.