What was released / announced
DeepSeek just opened up Search & Fetch, a hosted web‑search‑plus‑retrieval endpoint that returns the most relevant snippets for a query. The service is priced at $0.75 per 1,000 successful requests, which is dramatically cheaper than many competing search‑as‑a‑service offerings. In practice you send a plain text query, DeepSeek crawls the web, ranks the results with their LLM, and returns a JSON payload with titles, URLs, and extracted snippets.
Why it matters
1️⃣ Cost‑effective grounding for LLMs
When you build a chat‑bot or an autonomous agent, the biggest hidden cost is the retrieval layer. OpenAI’s Retrieval API, Azure Cognitive Search, or even self‑hosted Elastic can easily run $5‑$10 per 1k queries once you factor in storage, compute, and scaling. DeepSeek’s $0.75 rate slashes that by ~90 %, making it feasible to add fresh web knowledge to every user interaction without blowing the budget.
2️⃣ Zero‑ops deployment
The endpoint is fully managed – no clusters, no index sharding, no API‑gateway tricks. For DevOps teams that already juggle Kubernetes clusters for model serving, this removes a whole stack of operational overhead. You just hit a REST endpoint, handle the JSON, and you’re good to go.
3️⃣ Real‑time freshness
Because DeepSeek crawls the public web on demand (subject to their crawl policies), the results are much newer than a static vector store you pre‑populate once a week. For use‑cases like news summarisation, compliance monitoring, or dynamic product recommendation, that freshness is a competitive edge.
How to use it
Below is a minimal Python example that shows how to call the Search & Fetch API, handle errors, and extract the top‑3 snippets. The same pattern works in any language that can make HTTP calls.
import os
import requests
API_KEY = os.getenv("DEEPSEEK_API_KEY") # get it from https://deepseek.com/account
ENDPOINT = "https://api.deepseek.com/v1/search"
def search_fetch(query: str, top_k: int = 3):
payload = {
"query": query,
"top_k": top_k,
"include_snippets": True,
}
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
response = requests.post(ENDPOINT, json=payload, headers=headers, timeout=10)
response.raise_for_status()
data = response.json()
# data format: {"results": [{"title": ..., "url": ..., "snippet": ...}, ...]}
return data["results"]
if __name__ == "__main__":
queries = [
"latest advancements in quantized LLM inference",
"how to configure autoscaling in GKE for GPU workloads",
]
for q in queries:
print(f"\n🔎 Query: {q}")
try:
hits = search_fetch(q)
for i, hit in enumerate(hits, 1):
print(f"{i}. {hit['title']} ({hit['url']})")
print(f" {hit['snippet'][:200]}…\n")
except Exception as e:
print(f"❗️ Failed: {e}")
Quick checklist before you run the script
-
Create an API key on the DeepSeek dashboard and export it as
DEEPSEEK_API_KEY. - Install the
requestslibrary (pip install requests). - Adjust
top_kbased on your latency budget – more results mean a larger payload and a slightly higher latency. - Monitor usage via the DeepSeek console; the dashboard shows request count, success rate, and cost in real time.
Integrating with an existing LLM pipeline
If you already have a LangChain or LlamaIndex workflow, you can plug the Search & Fetch call into the retriever interface:
from langchain.schema import Document
from langchain.retrievers import BaseRetriever
class DeepSeekRetriever(BaseRetriever):
def __init__(self, api_key: str, top_k: int = 5):
self.api_key = api_key
self.top_k = top_k
def get_relevant_documents(self, query: str) -> list[Document]:
results = search_fetch(query, top_k=self.top_k)
return [Document(page_content=r["snippet"], metadata={"source": r["url"]}) for r in results]
Now your LLM can call retriever.get_relevant_documents(prompt) and receive fresh web snippets without spinning up a separate Elasticsearch cluster.
My take
From the trenches of building AI‑infrastructure at Griffin AI Tech, the biggest friction point has always been cost‑predictability. We run multi‑tenant inference clusters on GKE, and every extra HTTP call to a third‑party search service shows up as a line item that can double our monthly spend if we’re not careful.
DeepSeek’s pricing model is refreshing because it aligns directly with successful requests. That means failed calls (timeouts, rate‑limit hits) don’t eat into the budget, which encourages you to build robust retry logic instead of silently swallowing failures.
Operationally, I love the no‑ops nature. In the past, we allocated a dedicated namespace, tuned shard counts, and wrote custom health‑checks just to keep a vector search service alive. With Search & Fetch, I can retire that whole stack, cut down on Terraform modules, and focus on the parts that actually differentiate our product – model orchestration, request routing, and observability.
That said, there are a couple of caveats:
- Rate limits – the free tier caps at 5 k requests per day. For production workloads you’ll need to request a higher quota or fall back to a cached fallback.
- Content policy – DeepSeek respects robots.txt and filters out adult or copyrighted material. If your use‑case requires crawling the deep web or private docs, you’ll still need a self‑hosted retriever.
Overall, I see Search & Fetch as a great entry point for startups that want to add “real‑time knowledge” to their LLM products without the heavy lifting of search infrastructure. It’s cheap enough to experiment, stable enough for production, and simple enough to drop into an existing LangChain or LlamaIndex pipeline with a few lines of code.
If you’re already wrestling with the cost of keeping a vector DB fresh, give DeepSeek a spin. The ROI you’ll see in reduced ops overhead and lower per‑query spend can be reinvested into better model fine‑tuning or more aggressive A/B testing.
Happy hacking!
Top comments (0)