improvement(knowledge): keep the default scan for a walk that asks the document per tuple

Author: waleedlatif1

apps/sim/lib/knowledge/search/queries.test.ts

@@ -2299,6 +2299,12 @@ describe('filters on a resolved scope', () => {
     /** The mock renders a nested condition into the params; the date test is the only `gte`. */
     const datesDocument = (statement: unknown) => JSON.stringify(statement).includes('"type":"gte"')
     expect(datesDocument(walks[0])).toBe(true)
+    /** A walk that asks the document per tuple keeps the default scan cap, not the on-row one. */
+    const scanCaps = () =>
+      statements()
+        .filter((query) => query.sql.includes('hnsw.max_scan_tuples'))
+        .map((query) => query.params.find((param) => param === '20000' || param === '100000'))
+    expect(scanCaps().at(-1)).toBe('20000')
     resetDbChainMock()
     queueTableRows(schemaMock.embedding, rerankRows)
     dbChainMockFns.execute.mockImplementation(async (query) => {
@@ -2313,6 +2319,7 @@ describe('filters on a resolved scope', () => {
       accessPlan: plan(),
     })
     expect(datesDocument(statements().filter((query) => isWalk(query.sql))[0])).toBe(false)
+    expect(scanCaps().at(-1)).toBe('100000')
   })
 
   it('leaves the keyword leg short when its deadline passes before the ranking is resolved', async () => {

apps/sim/lib/knowledge/search/queries.ts

@@ -89,6 +89,18 @@ const CANDIDATE_HNSW_MAX_SCAN_TUPLES = '20000'
  * left with what the neighbourhood happened to hold.
  */
 const ON_ROW_WALK_SCAN_TUPLES = 100_000
+
+/**
+ * How far a walk may go when readability is on the row: the on-row cap, unless the walk still
+ * has to ask the document about each tuple — a tag or date filter — in which case a tuple costs
+ * what it did before the columns were mirrored, and the default cap keeps a walk through a
+ * mostly-excluded neighbourhood at a short answer rather than a missed deadline.
+ */
+function onRowWalkScanTuples(documentCondition: SQL | undefined): number {
+  return documentCondition === undefined
+    ? ON_ROW_WALK_SCAN_TUPLES
+    : Number(CANDIDATE_HNSW_MAX_SCAN_TUPLES)
+}
 /**
  * Beam width per iteration. A beam is the granularity of cancellation: pgvector calls
  * `CHECK_FOR_INTERRUPTS` only while building an index, never inside `hnswgettuple`, so neither
@@ -1475,7 +1487,7 @@ async function selectSourceVectorCandidates(input: {
             ORDER BY ${input.candidateDistance} LIMIT ${input.candidateLimit}`),
         input.budget,
         'vector.source_walk',
-        ON_ROW_WALK_SCAN_TUPLES
+        onRowWalkScanTuples(input.documentCondition)
       )
   const walks: Array<() => RankedChunks> = sources.walked.map((connectorId) =>
     walk(eq(embeddingSearch.connectorId, connectorId))
@@ -1594,7 +1606,9 @@ async function selectVectorResults(params: SearchParams): Promise<SearchResult[]
    * date filter, which the row does not carry. A bounded set never walks, so this only runs when
    * the filtered documents were too many to enumerate.
    */
-  const documentCondition = and(documentTagCondition, dateFilterCondition(params.filters))
+  const dateCondition = dateFilterCondition(params.filters)
+  const documentCondition =
+    documentTagCondition || dateCondition ? and(documentTagCondition, dateCondition) : undefined
   /**
    * Candidate selection ignores the page offset — only the rerank pages over the pool — so a
    * refill reuses the pool it already has. Excluding another source is the only thing that
@@ -1754,7 +1768,7 @@ async function selectVectorResults(params: SearchParams): Promise<SearchResult[]
               ),
             params.budget,
             'vector.candidate_search',
-            plan ? ON_ROW_WALK_SCAN_TUPLES : undefined
+            plan ? onRowWalkScanTuples(documentCondition) : undefined
           )
           /**
            * A full traversal is already the nearest permitted chunks, so nothing else is worth