Organizing Literature in Batches: Workspace and Context Design for LLM Assistants

Chat-based assistants in the browser handle single question-and-answer exchanges well, but they struggle to process dozens of papers reliably. The bottleneck is usually not whether one answer sounds human. It lies in the interaction boundary: materials cannot get in, the conversation cannot remember them, and local files are not visible. If you move the work from an ever-longer chat log to a local workspace that you can reopen at any time, literature review preparation changes from manual copying into a pipeline you can inspect.

Separate three types of constraints first

Entry constraints

Browser sessions often limit how many files you can submit at once, along with their size and format, and processing may queue. Fifty papers mean repeated exporting, waiting, and retrying. After a failure, if the session cannot carry over content it already parsed, you have to paste the large blocks of text again. Your time goes to moving files, not to deciding whether a paper is worth citing.

Memory constraints

Conversational products have a context window, which is the amount of text the model can “see” in the current turn. It is measured in tokens, roughly corresponding to a certain number of words and symbols, not to a count of papers. The window is shared by the system prompt, earlier questions and answers, the text you just pasted, and the assistant’s own long replies. The longer the conversation and the more you paste, the more likely early content is to be truncated or compressed.

This produces a typical kind of forgetting. You ask, “What did the earlier paper on representation learning conclude?” The assistant can only answer from fragments that remain, or it may state that it has not seen the paper. This is not a matter of attitude. It is the expected result of a full context. When a long conversation starts giving empty, vague, or contradictory answers, suspect the context first. Do not keep adding instructions like “remember all the papers I gave you,” because they cannot be fulfilled.

Accessibility constraints

A web session normally runs on a remote page and cannot see the folders on your desktop. It can only work with the part you pasted or uploaded successfully. If your machine holds hundreds or thousands of files, the assistant cannot traverse directories, and it cannot write summaries back to the original location under a consistent file name. Organizing folders, reading office documents, and cleaning spreadsheets all require you to convert them manually into inputs the assistant accepts. A manual interface sits between the assistant and your materials. At scale, that interface becomes the main cost.

Taken together, these three constraints mean that files cannot all be uploaded, the assistant forgets what has been uploaded, and it cannot go back to the original text on its own.

A workspace matters more than a longer chat

A better approach is not to stretch one conversation indefinitely. Instead, let the assistant work inside a directory you have authorized: read the original files, write intermediate results, and continue from those results next time. The assistant then acts more like a local collaborator with tools than a web page that only receives pasted text. The limits of that role should also be clear. It can speed up extraction, summarizing, and formatting. It cannot replace your own check of the original text, your judgment of journal requirements, or your academic responsibility.

For a thesis literature review, keep all the work under a single root directory so materials do not end up scattered across download folders and chat histories. Split the directory by function, not by “paper number”:

• raw/ contains only the original files. Nothing here is overwritten or renamed during processing, so you can always return to the source.
• text/ contains plain text extracted from the original files, which makes search and chunking easier. Extraction failures get their own marker rather than being treated as fully read.
• notes/ contains one structured card per paper.
• index/ contains the master table: title, year, topic tags, whether the paper has been read, and the path to its card.
• synthesis/ contains draft review paragraphs merged by topic, with each sentence noting the card it came from.

Separating original files from generated outputs keeps the work verifiable. Any sentence that enters the thesis should be traceable backward through “draft, card, plain text, original file.” If that chain breaks, the notes cannot be cited, however quickly they were produced.

Use external memory to work within a limited context

The context window suits the current step. It is not a database for a whole literature review. The engineering answer is external memory: write information that must persist across turns into files, and load only the fragments each step needs into the window.

Keep each card short and fixed in structure. Do not let the assistant write free-form essays. Useful fields usually include: research question, data or materials, key methods, main results, limitations the authors acknowledge, relation to your own topic, the location of quotable passages (page or section, not a sentence the assistant rewrote), and your decision (cite, alternative, or exclude). Keep method names and metrics in the original wording, and put translations only in notes. This reduces drift when you later write an English abstract or compare against the source.

Do not expect a single prompt to “summarize all fifty papers.” Break the work into small steps that can resume after interruption. First, generate a card for each paper. Then, group the papers by topic. Finally, write the review paragraphs. The input to each step is a file produced by the previous step, not the full conversation history. If one paper fails extraction or a reply is cut off, rerun only that paper and do not paste everything again.

When a batch of cards still does not fit in the window, lossy compression needs clear rules. Keep the conclusions, methods, and limitations. Remove background sections and repetitive lists of related work. Store the compressed version separately, with the compression date and the card version it came from. Never overwrite a card with a compressed version, or the lost details cannot be recovered.

Cross-paper questions, such as “Which studies used the same evaluation metric?”, should be answered by checking the master table and cards first, not by pasting all the original text into the conversation again. This follows the same logic as retrieval-augmented generation (RAG): locate a small set of relevant passages first, then generate the answer. Without a dedicated retrieval component, a master table and clear file names already reduce misreadings considerably.

A repeatable pipeline

The pseudocode below describes the dependencies between steps. It is not a command or interface from any particular product.

for each file in raw/:
    text = extract_text(file)          # on failure, record it in the index error column
    chunks = split(text, by_section)   # split by section or fixed length, keep sequence numbers
    partials = []
    for chunk in chunks:
        partials.append(summarize(chunk, schema=card_fields))
    card = merge(partials)             # discard assertions that cannot be traced to a chunk
    write(notes/id.md, card)
    append(index/table, metadata(file, card))
clusters = group(index, by=topic_tags)
for cluster in clusters:
    draft = synthesize(read_cards(cluster), cite_keys=required)
    write(synthesis/cluster.md, draft)

The summarize prompt should require the assistant to rely only on the current chunk. When the text does not say something, it should write “not stated in the original text.” It must not invent page numbers, sample sizes, experimental settings, or reference entries. When merge finds conflicting conclusions between chunks, it should keep both and point to each one’s sequence number, rather than letting the assistant reconcile them on its own. synthesize may cite only judgments already recorded in the cards, and every sentence should end with a consistent marker that includes the paper’s identifier. A sentence without a marker counts as unfinished and should not enter the thesis.

Give topic tags a small predefined set, such as “data, model, experiment, application, review.” Otherwise, each paper may invent near-synonymous tags, and clustering becomes impossible later. Tags can be multi-select, but they must come from that set.

Batch processing also has to handle exceptions: scanned files without a text layer, tables extracted in the wrong order, lost formulas, and encrypted files that cannot be opened. Record these in a status column of the master table, not mix them in with “summarized.” Scanned files need optical character recognition (OCR) first. Spot-check the recognized text, especially numbers, units, and proper nouns. Keep the recognized text alongside the original file. Do not keep only the recognized version.

Academic ground rules

An assistant’s summary is a working draft, not a citation source. Before writing anything into a thesis, check at least three things: that each claim really comes from that paper and not from a neighboring one, that data, years, and method names match the original, and that each reference entry comes from your own bibliography records and not from text the model filled in. Models can attribute findings to papers that do not exist or to the wrong paper. In batch work, that error can spread across many paragraphs.

Citation formatting, university templates, and plagiarism requirements are not model capabilities. A safe approach is to store only facts and locations on the cards, and export the formatted reference list from your reference management workflow. If your university prohibits unlabeled machine-generated body text, treat the review paragraphs as an outline and write the final wording yourself.

Also limit the scope of materials. A workspace may contain unpublished data, a classmate’s draft, or internal reports. Authorizing an assistant to read a directory means that its contents will enter that processing session. Do not put confidential or unauthorized materials into raw/, and do not scan an entire home directory just to save effort. In this setting, least privilege means the smallest possible directory.

How local processing and cloud services divide the work

At the scale of most theses, a single-machine workspace is enough. Files, cards, and the process can all stay local and be reviewed offline. When you need to work across devices or the original files become very large, separate archiving from retrieval. Original files can be backed up to object storage. If structured cards need to be searched across devices, you can use a knowledge base or retrieval service and pull back only the relevant cards when needed, rather than syncing the entire conversation history.

If you use general-purpose services on Baidu AI Cloud, such as object storage, retrieval, or knowledge base services, upload only materials you are authorized to process, and confirm the access controls and retention period yourself. Activation steps, quotas, interfaces, and billing are subject to the official documentation at the time of use. Do not assume a hidden parameter exists that automatically reads every paper on a disk. Cloud services handle storage and recall. They do not change the requirement to check every conclusion against the original text.

Do not keep your only copy in a single web session. Sessions can be cleared, accounts can be switched, and context windows can be truncated. The raw/, notes/, and index/ folders in the workspace are the portable results. A conversation is, at most, scratch paper used to generate those files.

How to tell whether the method works

Do not use the assistant’s confident tone as the acceptance test. Use observable results instead. Can you open the original location for any card within a minute? If you randomly sample five review sentences, can each one be traced back to a card field rather than a vague phrase like “research shows”? After an interruption, can you tell from the master table alone which papers are still unfinished? When you search the full text for a method name, does the search hit the master table and then a small number of cards, instead of requiring you to upload every file again?

If these checks fail, tighten the card fields and the directory structure first. Do not simply lengthen the prompt. A prompt affects the quality of a single generation. The directory, status table, and citation markers determine whether the workflow still holds at fifty papers. Web chat is useful for testing: use one paper to settle the fields. Once the fields are stable, move the batch work into the workspace. Then the limits of context, upload size, and local file access stop being surprises during writing and become boundaries you design for from the start.