-
Notifications
You must be signed in to change notification settings - Fork 15
Feat/adding recency score #274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
WalkthroughThe Changes
Sequence DiagramsequenceDiagram
participant Main as Stage 2 Evaluation
participant BuildCP as buildCandidatePairs()
participant CalcRW as calculateRecencyWeight()
participant Rank as rankIntentPairs()
participant Output as User Output
Main->>+BuildCP: (awaited)
loop For each candidate pair
BuildCP->>+CalcRW: Get recencyWeight for intent(s)
CalcRW-->>-BuildCP: Promise<number>
BuildCP->>BuildCP: Attach recencyWeight to pair
end
BuildCP-->>-Main: Promise<CandidatePair[]> with recencyWeight
Main->>+Rank: candidatePairs (with recencyWeight)
Rank->>Rank: Account for recencyWeight in ranking
Rank-->>-Main: Ranked pairs
Main->>+Output: Top 3 pairs + Recency Weight
Output->>Output: Display recency-aware guidance
Output-->>-Main: User-facing results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Caution Docstrings generation - FAILED No docstrings were generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
protocol/src/agents/context_brokers/semantic_relevancy/index.ts (1)
197-228: Cache intent recency lookups to avoid N+1 queries.Each call to
calculateRecencyWeightperforms its owngetIntentfetch, so building candidates can issue two fresh DB reads per existing stake and one per mutual result. In dense matches this becomes an avoidable N+1 pattern (the same intent ID can be looked up repeatedly across stakes), adding latency before we even reach the LLM. Please memoize/batch the recency lookups (e.g., keep aMapkeyed by intentId or prefetch the unique IDs up front) so every intent row is retrieved at most once during this pass.
Summary by CodeRabbit
New Features
Refactor