TE
テックエコー
ホーム24時間トップ最新ベスト質問ショー求人
GitHubTwitter
ホーム

テックエコー

Next.jsで構築されたテクノロジーニュースプラットフォームで、グローバルなテクノロジーニュースとディスカッションを提供します。

GitHubTwitter

ホーム

ホーム最新ベスト質問ショー求人

リソース

HackerNews APIオリジナルHackerNewsNext.js

© 2025 テックエコー. すべての権利を保有。

Web search on the Anthropic API

262 ポイント投稿者: cmogni1約24時間前

13 comments

cmogni1約23時間前
I think the most interesting thing to me is they have multi-hop search &amp; query refinement built in based on prior context&#x2F;searches. I&#x27;m curious how well this works.<p>I&#x27;ve built a lot of LLM applications with web browsing in it. Allow&#x2F;block lists are easy to implement with most web search APIs, but multi-hop gets really hairy (and expensive) to do well because it usually requires context from the URLs themselves.<p>The thing I&#x27;m still not seeing here that makes LLM web browsing particularly difficult is the mismatch between search result relevance vs LLM relevance. Getting a diverse list of links is great when searching Google because there is less context per query, but what I really need from an out-of-the-box LLM web browsing API is reranking based on the richer context provided by a message thread&#x2F;prompt.<p>For example, writing an article about the side effects of Accutane should err on the side of pulling in research articles first for higher quality information and not blog posts.<p>It&#x27;s possible to do this reranking decently well with LLMs (I do it in my &quot;agents&quot; that I&#x27;ve written), but I haven&#x27;t seen this highlighted from anyone thus far, including in this announcement.
评论 #43920807 未加载
评论 #43921935 未加载
minimaxir約24時間前
The web search functionality is also available in the backend Workbench (click the wrench Tools icon) <a href="https:&#x2F;&#x2F;console.anthropic.com&#x2F;workbench&#x2F;" rel="nofollow">https:&#x2F;&#x2F;console.anthropic.com&#x2F;workbench&#x2F;</a><p>The API request notably includes the exact text it cites from its sources (<a href="https:&#x2F;&#x2F;docs.anthropic.com&#x2F;en&#x2F;docs&#x2F;build-with-claude&#x2F;tool-use&#x2F;web-search-tool" rel="nofollow">https:&#x2F;&#x2F;docs.anthropic.com&#x2F;en&#x2F;docs&#x2F;build-with-claude&#x2F;tool-us...</a>), which is nifty.<p>Cost-wise it&#x27;s interesting. $10&#x2F;1000 queries is much cheaper for heavy use than Google&#x27;s Gemini (1500 free per day then $35&#x2F;1000) when you&#x27;d expect Google to be the cheaper option. <a href="https:&#x2F;&#x2F;ai.google.dev&#x2F;gemini-api&#x2F;docs&#x2F;grounding" rel="nofollow">https:&#x2F;&#x2F;ai.google.dev&#x2F;gemini-api&#x2F;docs&#x2F;grounding</a>
评论 #43921179 未加载
评论 #43920445 未加载
jarbus約22時間前
Is search really that costly to run? $10&#x2F;1000 searches seems really pricey. I&#x27;m wondering if these costs will come down in a few years.
评论 #43921238 未加载
评论 #43921789 未加载
评论 #43921328 未加载
评论 #43924723 未加载
评论 #43921139 未加载
benjamoon約24時間前
Good that it has an “allowed domain” list, makes it really useable. The OpenAI Responses api web search doesn’t let you limit domains currently so can’t make good use of it for client stuff.
omneity約22時間前
Related: For those who want to build their own AI search for free and connect it to any model they want, I created a browser MCP that interfaces with major public search engines [0], a SERP MCP if you want, with support for multiple pages of results.<p>The rate limits of the upstream engines are fine for personal use, and the benefit is it uses the same browser you do, so results are customized to your search habits out-of-the-box (or you could use a blank browser profile).<p>0: <a href="https:&#x2F;&#x2F;herd.garden&#x2F;trails&#x2F;@omneity&#x2F;serp" rel="nofollow">https:&#x2F;&#x2F;herd.garden&#x2F;trails&#x2F;@omneity&#x2F;serp</a>
potlee約22時間前
If you use your own search tool, you would have to pay for input tokens again every time the model decides to search. This would be a big discount if they only charging once for all output as output tokens but seems unclear from the blog post
评论 #43922544 未加载
simonw約23時間前
I couldn&#x27;t see anything in the documentation about whether or not it&#x27;s allowed to permanently store the results coming back from search.<p>Presumably this is using Brave under the hood, same as Claude&#x27;s search feature via the Anthropic apps?
评论 #43920495 未加载
aaronscott約23時間前
It would be nice if the search provider could be configured. I would like to use this with Kagi.
评论 #43920783 未加载
simianwords約15時間前
Can any one answer this question: are they using custom home made web index? Or are they using bing&#x2F;google api?<p>Also I&#x27;m quite sure that they don&#x27;t use vector embeddings for web search, its purely on text space. I think the same holds for all LLM web search tools. They all seem to work well -- maybe we don&#x27;t need embeddings for RAG and grepping works well enough?
elisson22約10時間前
Regarding the costs, do we have a clear indication as to how much it costs to the company to perform tasks from a power consumption perspective? Or is it negligible?
lemming約23時間前
I&#x27;m also interested to know if there are other limitations with this. Gemini, for example, has a built-in web search tool, but it can&#x27;t be used in combination with other tools, which is a little annoying. o3&#x2F;o4-mini can&#x27;t use the search tool at all over the API, which is even more annoying.
metalrain約16時間前
It&#x27;s a good reminder that AI chats won&#x27;t make web searches obsolete, just embed them at deeper in the stack.<p>Maybe Google search revenue moves from ads to more towards B2B deals for search API use.
zhyder約22時間前
Now all the big 3 LLM providers provide web search grounding in their APIs, but how do they compare in ranking quality of the retrieved web search results? Anyone run benchmarks here?<p>Clearly web search ranking is hard after decades of content spam that&#x27;s been SEO optimized (and we get to look forward to increasing AI spam dominating the web in the future). The best LLM provider in the future could be the one with just the best web search ranking, just like what allowed Google to initially win in search.
评论 #43922586 未加载