Repository navigation
Conversation
…s with native citations
|
👀 very interested in this functionality - we are currently patching the anthropic provider to support citing tool call results |
4 tasks done
Author
|
I’ve merged the latest main branch, resolved the conflicts, and rerun the Anthropic tests and repository-wide checks. Everything passes. We’re currently using this functionality through a local patch, so we’d really appreciate having it supported upstream. I’d appreciate a review when you have a chance. |
…ch-result-blocks # Conflicts: # packages/anthropic/src/anthropic-api.ts
…t responses Since inbound citations are now normalized onto text parts (`citations`), drop the duplicate source-part mapping for `search_result_location` and `content_block_location`. This PR now only adds sending search result blocks (in tool results and as file parts) and custom content documents.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
Anthropic's search result blocks (
search_resultcontent blocks) are generally available and let Claude cite specific passages from RAG results with the same citation quality as web search. The docs describe two ways to provide them — from tool calls ("the most powerful use case", enabling dynamic RAG) and as top-level message content — and note that they "eliminate the need for document-based workarounds". The AI SDK currently supports neither, so RAG applications fall back to exactly that workaround:documentblocks injected as extra message content.That workaround breaks down in turns that mix server tools and client tools: per Anthropic's mixed-turn rules, the follow-up user message must contain nothing except
tool_resultblocks, so any injecteddocumentblock leaves a deferredweb_searchcall unresolved and the request fails with a 400 (`web_search` tool use ... was found without a corresponding `web_search_tool_result` block). Search results inside the tool result avoid this entirely.#11968 (credit to @lithdew) proposed file-part support for search results, but has been stuck in review and now conflicts with
mainafter the provider file renames. This PR re-implements that scope on currentmainand additionally supports search results inside tool results.Summary
This implements both methods from Anthropic's Search Results documentation:
contenttool output (e.g. viatoModelOutput) whose text parts carryproviderOptions.anthropic.type: 'search_result'(source,title, optionalcontentblocks,citations). The blocks are emitted inside thetool_result, which makes RAG tool output directly citable and works in mixed server-tool/client-tool turns. Options are validated with a zod schema; invalid options fall back to plain text with a warning instead of sending a malformed block.search_resultblocks in the user message.source: { type: 'content', content: [...] }sends pre-chunked text as a citabledocumentblock (content_block_locationcitations).search_result_locationandcontent_block_locationare parsed (response + streaming) and returned assourceparts with provider metadata (citedText,source,searchResultIndex,startBlockIndex,endBlockIndex).extractCitationDocumentsexcludes search result parts sodocument_indexstays aligned: per the API contract, search results are counted separately viasearch_result_index"across all messages and tool results". Covered by an alignment test with mixed search results and documents.Manual Verification
Verified end-to-end against the live Anthropic Messages API (via a Microsoft Foundry Anthropic endpoint,
claude-sonnet-5):generateText): response contained asearch_result_locationcitation, returned as asourcepart withcitedText/source/searchResultIndex/ block range metadata. With two search results,search_result_index0 and 1 were attributed correctly.generateText+ custom tool withtoModelOutput): the model called the tool, the tool result carriedsearch_resultblocks, and the answer cited them natively (both included examples were run against the live API).anthropic.tools.webSearch_20250305in one request. The deferred web search resolved without a 400, and the final answer contained bothurlsources (web search) anddocumentsources (tool-result search results).pnpm testinpackages/anthropic: 451 tests pass (node + edge).Checklist
pnpm changesetin the project root)Future Work
stringand image-block variants of custom content documentsource.content(currently text blocks only, same scope as feat(anthropic): search result blocks and custom content documents #11968).Related Issues
Supersedes #11968 (conflicts with
mainafter the provider file renames; scope is included here). Related: #4497 (Anthropic Citations API support).