How to Add Web Search and Local Memory to Your AI Data-Analysis Script

If you want an AI model to explain TXT data using up-to-date technical information, there are two separate problems to solve: web access and memory.

The safest way to add web search

Your script uses an OpenAI-compatible client with a custom base_url. That does not guarantee that the provider or the deepseek-v4-flash model supports OpenAI's native web-search tools. OpenAI's built-in web search is primarily exposed through the Responses API, while third-party compatible endpoints may implement only part of that interface. 5

A more portable design is therefore:

1. Read the TXT file.
2. Generate or define a small list of technical search queries.
3. Send those queries to Tavily.
4. Collect the titles, URLs and summaries returned by Tavily.
5. Pass the search context and the relevant TXT data to the model.
6. Require the model to distinguish measured data from general web-based explanations.

Tavily authenticates requests with an API key and returns structured search results, making it suitable for this kind of retrieval-before-analysis workflow. 13

The key configuration in the script is:

ENABLE_WEB_SEARCH = True
TAVILY_SEARCH_URL = "https://api.tavily.com/search"
SEARCH_RESULTS_PER_QUERY = 5
MAX_SEARCH_QUERIES = 4
SEARCH_DEPTH = "advanced"

Store the credentials as environment variables rather than hard-coding them in the source file:

$env:AI_API_KEY="your AI API key"
$env:AI_BASE_URL="your compatible base URL"
$env:TAVILY_API_KEY="your Tavily API key"

The search results are then formatted with identifiers such as [W1], [W2] and [W3]. The analysis prompt tells the model to use those identifiers only when making claims based on web material. This is important: a general explanation of MOSFET behaviour should not be presented as if it were a direct conclusion from the current TXT file.

Does the model remember what you previously fed it?

Not automatically. With chat.completions.create(), using the same client object or the same model name does not create a persistent personal memory. The application must preserve the relevant context and send it again in a later request. 26

In practice, you have three choices:

• No memory: each run analyses only the current TXT file.
• Conversation history: save previous messages and include selected turns in the next request.
• Project memory: save useful summaries, reports or metadata in a database or local file, then retrieve only what is relevant to the current task.

The supplied script takes the third, lightweight approach. It defines:

MEMORY_FILE = Path("analysis_memory.txt")
ENABLE_PERSISTENT_MEMORY = False

When ENABLE_PERSISTENT_MEMORY is changed to True, the program reads the existing memory file at startup and sends it as background context. After the current analysis finishes, it appends the final report to the same file. The script limits both the amount read into the prompt and the maximum size of the memory file, helping prevent unbounded growth.

That memory is only a file-based record controlled by your program. It is not the model independently remembering your data, and it will not automatically know which parts of an old report are still relevant. If you analyse different devices or projects, leaving memory disabled—or maintaining a separate memory file for each project—can prevent old conclusions from contaminating new results.

Recommended workflow in the script

The overall pipeline is:

TXT data
   ↓
Split into manageable chunks
   ↓
Generate technical search queries
   ↓
Search Tavily
   ↓
Send each data chunk + web context + optional memory to the model
   ↓
Save intermediate reports
   ↓
Combine the reports into a final result
   ↓
Optionally append the final report to local memory

The prompt also includes several useful safeguards:

• x and X are treated as missing or invalid values, not as zero.
• The model must not invent values that do not appear in the data.
• Web information and conclusions drawn from the TXT file must be kept separate.
• Conflicts between web guidance and the observed data must be reported explicitly.
• Insufficient evidence must be labelled as such.

These instructions are especially valuable when analysing semiconductor data, where missing values, measurement limits and trade-offs can easily be mistaken for physical trends.

One correction required before running

There is a response-access typo in the supplied code. This line:

content = response.choices.message.content

should be:

content = response.choices.message.content

choices is a list, so the first returned choice must be selected before accessing its message content.

Bottom line

For a custom OpenAI-compatible endpoint, do not assume that native web search will work simply because the client library looks compatible. Use Tavily as a separate search layer, attach the resulting source summaries to the model prompt, and require source markers such as [W1] for web-derived claims. 135

And for memory, remember the practical rule: the Chat Completions API does not remember for you; your code does. Save only the context you need, keep projects separated, and pass that context explicitly in future requests. 26