feat(semantic): nominate Global Ask evidence candidates - #637
Conversation
…ing-pool-release # Conflicts: # docs/adr/README.md # docs/operability/http-concurrency-evidence.md # docs/product-technical-gap-baseline.md # scripts/k6_http_e2e.js
…lease' into fix/global-ask-embedding-pool-release # Conflicts: # backend/app/post_chat_ingestion.py
…lease' into fix/global-ask-embedding-pool-release # Conflicts: # backend/app/post_chat_ingestion.py # tests/test_global_ask_sources.py
…lease' into fix/global-ask-embedding-pool-release
…lease' into fix/global-ask-embedding-pool-release
* fix(backend): make the similar-VOC SQL audit reason adjacent (hotfix main) The similar-VOC candidate fetch already carried a suppression, but its Safe SQL reason sat three lines above the audited call while the review contract requires the immediately preceding line. Collapse the comment to one adjacent line; the counted total stays 36 because this repairs an existing site rather than adding one. * perf: keep authenticated web reads responsive * docs: record authenticated capacity comparison --------- Co-authored-by: seonghobae <seonghobae@users.noreply.github.com>
…bal-ask-semantic-candidates
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
6b99489
into
fix/global-ask-graph-fact-provenance
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| try: | ||
| fused = build_rankweave_client().fuse_rankings(channels, titles_by_id) |
There was a problem hiding this comment.
🔍 Global Ask candidate fusion ignores RANKWEAVE_DISABLED
_fuse_global_candidate_ids in post_chat_ingestion.py calls build_rankweave_client() with no disabled flag, so it always uses the live fusion transport. The Rankings port honors settings.rankweave_disabled. An operator disabling RankWeave still gets live RRF fusion inside Global Ask retrieval. It fails closed to embedding-only when the library is absent, so behavior is safe, but the config is applied inconsistently.
Was this helpful? React with 👍 or 👎 to provide feedback.
| async def _fetch_lineage_landing_rows( | ||
| conn: asyncpg.Connection, | ||
| corporate_entity_ids: Sequence[str], | ||
| process_unit_ids: Sequence[str], | ||
| limit: int, | ||
| ): | ||
| """Fetch only the authorized, bounded landing projection in PostgreSQL.""" | ||
| posts = await conn.fetch( | ||
| "select post_id, post_title, voc_type_code, visibility_code, " | ||
| "corporate_entity_id, process_unit_id, thread_group_key, created_at " | ||
| "from source_post where " | ||
| f"{SOURCE_POST_ELIGIBILITY_SQL.format(alias='source_post')} and " | ||
| "(visibility_code = 'public' or (corporate_entity_id::text = any($1::text[]) " | ||
| "and (cardinality($2::text[]) = 0 or process_unit_id::text = any($2::text[])))) " | ||
| "order by created_at desc, post_id desc limit $3", | ||
| list(corporate_entity_ids), | ||
| list(process_unit_ids), | ||
| limit + 1, | ||
| ) | ||
| visible = list(posts[:limit]) | ||
| visible_ids = [str(row["post_id"]) for row in visible] | ||
| edge_rows = ( | ||
| await conn.fetch( | ||
| "select parent_post_id, child_post_id, fused_score, interval_relation_code " | ||
| "from post_lineage_edge where parent_post_id = any($1::uuid[]) " | ||
| "and child_post_id = any($1::uuid[])", | ||
| visible_ids, | ||
| ) | ||
| if visible_ids | ||
| else [] | ||
| ) | ||
| return visible, edge_rows, len(posts) > limit |
There was a problem hiding this comment.
📝 Info: Landing lineage SQL filter duplicates _can_see_post
_fetch_lineage_landing_rows replaces the can_see_post callback with an in-SQL ABAC predicate for the landing projection. It currently matches _can_see_post (backend/app/main.py:525-535): public always visible, private needs the corporate entity in scope, and cardinality($2)=0 or process_unit_id = any($2) mirrors the process-unit clause. The landing path no longer runs the callback, so any future drift between the two definitions would silently change /api/lineage visibility.
Was this helpful? React with 👍 or 👎 to provide feedback.
| corporate_entity_ids, | ||
| process_unit_ids, | ||
| question=question_text, | ||
| question_embedding=question_embedding, | ||
| today=today, | ||
| embedding_client=embedding_client, | ||
| embedding_client=NullEmbeddingClient(), |
There was a problem hiding this comment.
📝 Info: Transient embedding failure degrades to evidence-only retrieval
compute_global_ask_answer resolves the embedding before acquiring the pool and forces embedding_client to Null. If embed() raises a transient OSError/RuntimeError/ValueError, prepare_global_question_embedding returns None, supplied_question_embedding is False, and gather_global_chat_sources proceeds with the evidence channel only rather than failing. This aligns with ADR 0047, but a transient provider blip now silently switches a single request to evidence-only retrieval.
(Refers to this code)
Was this helpful? React with 👍 or 👎 to provide feedback.
| try: | ||
| hits = rw.weighted_reciprocal_rank_fuse( | ||
| usable, | ||
| active_weights, | ||
| limit=DEFAULT_RANKING_LIMIT, | ||
| rank_constant_eta=DEFAULT_RANK_CONSTANT_ETA, | ||
| ) | ||
| except TypeError: | ||
| try: | ||
| if all(weight == 1.0 for weight in active_weights.values()): | ||
| hits = rw.reciprocal_rank_fuse( | ||
| usable, | ||
| limit=DEFAULT_RANKING_LIMIT, | ||
| rank_constant_eta=DEFAULT_RANK_CONSTANT_ETA, | ||
| ) | ||
| else: | ||
| hits = rw.weighted_reciprocal_rank_fuse( | ||
| usable, | ||
| active_weights, | ||
| limit=DEFAULT_RANKING_LIMIT, | ||
| rank_constant_eta=DEFAULT_RANK_CONSTANT_ETA, | ||
| ) |
There was a problem hiding this comment.
🔍 RankWeave transport now requires reciprocal_rank_fuse
LibraryRankWeaveTransport calls rw.reciprocal_rank_fuse when every active weight is 1.0, else weighted_reciprocal_rank_fuse. If an installed RankWeave build lacks reciprocal_rank_fuse, the AttributeError is caught by the outer handler and becomes RankWeaveNotAvailable (fail-closed), whereas the previous code succeeded via weighted_reciprocal_rank_fuse. This assumes the pinned RankWeave exposes reciprocal_rank_fuse; worth confirming against the locked version.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Closes #272.
Adds authorized index-backed candidate nomination from normalized project, R&R, Keyman, Knowledge Graph, endpoint-label, and canonical ontology-IRI evidence. Each channel is bounded after ABAC, eligibility, and event-time filtering; RankWeave parameter-free RRF combines present channels without local weights. Evidence-only retrieval remains available when embeddings are unavailable.
Validation: 116 passed, 2 skipped across focused retrieval, queue, schema, migration replay, docstring, and documentation gates, including live PostgreSQL project, graph endpoint, and canonical ontology IRI retrieval.