Open-Source Models for Mobile Chat Archive and Knowledge Base Integration

1. Background and Goals

Chat records on mobile phones are scattered across devices over long periods and often contain information such as work arrangements, technical discussions, meeting conclusions, and project requirements. Over time, this content becomes difficult to retrieve and reuse effectively. Many developers want to export chat records and automatically convert them into structured notes, task lists, or knowledge entries, then sync the results to a personal work assistant or knowledge management system.

This article discusses a localized processing solution based on open-source large language models. The core goals are:

1. Clean and segment chat records exported from mobile devices;
2. Use the long-context and long-horizon task capabilities of open-source large language models to automatically extract key information;
3. Generate structured content such as meeting minutes, to-do items, and technical conclusions;
4. Write the results into directories that common note-taking tools or intelligent work assistants can read.

The entire process can run locally or in a private environment, avoiding the upload of sensitive chat data to external services and meeting data privacy requirements.

2. Overall Approach and Pipeline Design

Before automated processing, the boundaries of input, processing, and output must be clearly defined.

2.1 Input: Exported Chat Record Files

Mobile chat tools typically support exporting chat records as text files or database backups. The exported content generally includes:

• Timestamps;
• Sender nicknames or remarks;
• Message body;
• Placeholder markers for multimedia messages such as images and files.

Raw export files often contain a large amount of irrelevant information, such as system prompts, recalled message records, repeated emojis, and consecutive meaningless replies. This content needs preliminary cleaning before entering model processing.

2.2 Processing: Segmentation and Semantic Extraction

Although large language models have made significant progress in long-context handling, processing thousands of messages at once can still cause attention dispersion and degraded output quality. Therefore, segmentation by time window or topic is recommended.

Common segmentation strategies include:

• Splitting by day: suitable for daily record archiving;
• Splitting by message count: keeping each segment within a few hundred messages;
• Topic clustering: first using a lightweight model for topic division, then processing segment by segment.

When each segment is fed to the model, the task objective and output format must be clearly specified.

2.3 Output: Structured Knowledge Entries

Model output should be as structured as possible to facilitate subsequent writing into the knowledge base. The recommended output format is Markdown, containing the following fields:

• Topic summary;
• Key discussion points;
• Confirmed conclusions;
• To-do items and owners;
• Risks or open issues;
• Associated time range.

Structured output can be directly recognized by common note-taking tools and is also convenient for further processing by intelligent work assistants.

3. Prompt Strategy and Task Decomposition

The performance of open-source large language models on complex tasks depends heavily on prompt design and task decomposition. Directly asking the model to “organize chat records” usually yields poor results; the task needs to be split into multiple stages.

3.1 Stage One: Create a Plan

First, ask the model to read a chat record fragment and output a processing plan. The plan should include:

• The main topics identified;
• The participating roles and their approximate positions;
• Possible action items;
• Information that needs further confirmation.

Example prompt:

You are a technical documentation assistant. Below is a conversation exported from a mobile chat tool.
Do not summarize directly yet. Instead, output an organization plan including:
1. The main topics covered in this conversation;
2. Which subsections it can be divided into;
3. What types of information each subsection might yield;
4. Whether there is missing information or unclear semantics.
Conversation content:
<paste chat records here>

The purpose is to let the model build an overall understanding of the content first, while avoiding producing lengthy and vaguely focused output without planning.

3.2 Stage Two: Segmented Execution

Based on the plan returned in stage one, information extraction can be executed segment by segment. For each segment, require the model to output only structured results, not the analysis process.

Example prompt:

Extract structured information from the following conversation and output strictly in Markdown format:
- Topic summary
- Key discussion points
- Confirmed conclusions
- To-do items and owners
- Risks or open issues
Conversation content:
<paste the corresponding fragment here>

3.3 Stage Three: Result Merging and Validation

After all fragments are processed, the results need to be merged into a complete document. At this point, the model can be called again for global validation to check:

• Whether there are duplicate to-do items across fragments;
• Whether conclusions are consistent;
• Whether any important decisions are missing;
• Whether the format is uniform.

The merge prompt can ask the model to output the final document and also provide a “validation change notes” section.

4. Resource Consumption and Stability in Practice

During long-horizon task execution, the model needs to be called multiple times, and the context window and output length of each call affect resource consumption. In actual tests, several hours of continuous processing noticeably consumes API quota or local inference resources.

To control resource consumption, the following measures can be taken:

4.1 Control Single Input Length

Chat record fragments should not be too long. It is recommended to keep a single input between 30% and 50% of the model’s context window, leaving enough room for output and reasoning.

4.2 Limit Output Length

Explicitly require concise output in the prompt to prevent the model from repeatedly quoting large chunks of the original text. For example:

Keep the output body under 800 words. Do not copy large portions of the original text; retain only necessary conclusions.

4.3 Set Up Checkpoint and Resume

Long-horizon tasks may be interrupted by network fluctuations, service rate limiting, or insufficient local resources. It is recommended to save each segment’s processing result independently and record completed segment identifiers in the task script. This allows resuming from the checkpoint after an interruption, avoiding duplicate processing.

4.4 Use Batch Processing and Caching

For recurring fixed prompt templates, separate the template from variable content to reduce prompt encoding overhead. For already-processed segment results, write them to a local cache so that subsequent repeated runs can skip them.

5. Error Handling and Quality Optimization

During long-running automated processing, the model occasionally produces format errors, missing fields, or duplicated content. In such cases, the entire task should not be rerun directly; instead, a local repair mechanism should be designed.

5.1 Format Validation

The script can check whether the output conforms to the expected structure. For example, check whether each segment output contains headings such as “Topic Summary” and “To-do Items.” If required fields are missing, the model can be called again separately to fill in that field.

5.2 Duplicate Detection

The merge stage needs to detect content duplication. A simple approach is to hash each to-do item or conclusion, or use text similarity for deduplication. The model can also be asked to mark duplicate entries during the global validation stage.

5.3 Manual Spot Checking

Even if automated processing works well, manual spot checking of important segments is recommended. This is especially true for dates, amounts, names, and technical parameters, which are prone to deviations due to speech-to-text errors or export format issues.

6. Integration with Local Knowledge Bases

The processed structured content needs to enter a system that supports long-term storage and retrieval. A common approach is to write Markdown files into a local note repository, or automatically ingest them through a watched directory of an intelligent work assistant.

6.1 Directory Structure Design

It is recommended to build directory hierarchies by time or topic. For example:

chat-archive/
├── 2025/
│   ├── 01/
│   │   ├── 2025-01-12-project-discussion.md
│   │   └── 2025-01-15-meeting-minutes.md
│   └── 02/
├── topics/
│   ├── architecture-design.md
│   └── data-migration.md
└── index.md

Time-based directories facilitate retrospection, while topic-based directories facilitate viewing by project.

6.2 Index Construction

To improve retrieval efficiency, a metadata block can be added at the beginning of each organized document, for example:

---
date: 2025-01-12
participants: Zhang San, Li Si
tags: [architecture, caching, performance]
summary: Discussion of caching strategy and performance optimization plan
---

This metadata can be recognized by the retrieval systems of common note-taking tools and can also be parsed by custom scripts.

6.3 Intelligent Work Assistant Integration

If a local intelligent work assistant is used, its knowledge base directory can be pointed to the archive path above. Then, when a user asks “What was the caching plan we discussed last month?”, the work assistant can retrieve and answer from the structured documents.

Note that during integration, document permissions and index scope should be kept controllable to avoid including historical discussions that should not be exposed in the default retrieval scope.

7. Data Privacy and Security Considerations

Chat records are highly sensitive data. Even with local models, file permissions, backup strategies, and access control must be carefully designed.

• Export files should be stored in encrypted directories;
• After processing, intermediate plaintext files should be deleted promptly or converted to an archive format that retains only necessary information;
• If cloud resources are used for inference, data transmission and storage policies should be confirmed;
• In multi-user environments, it should be clearly defined which chat records can be automatically archived and which require manual confirmation.

For enterprise scenarios, a compliance assessment before execution is also recommended to ensure that automated chat record processing complies with internal security policies and relevant laws and regulations.

8. Extensibility

The above pipeline can be further extended to various scenarios:

1. Customer service conversation archiving: automatically organize customer communication records into ticket summaries and follow-up items;
2. Project discussion tracking: extract requirement changes, risk items, and owners from group chats;
3. Personal knowledge accumulation: distill scattered technical discussions into reusable notes;
4. Multilingual conversation organization: require the model in the prompt to output uniformly in a specified language.

As open-source model capabilities improve, the proportion of manual intervention can be further reduced, achieving a higher degree of automation and more stable output quality.

9. Conclusion

Converting mobile chat records into retrievable and reusable structured knowledge is an important part of developer knowledge management. Through staged processing with open-source large language models, reasonable prompt design, and localized integration, archiving efficiency and retrieval experience can be significantly improved while protecting data privacy.

The key is not to attempt to have the model complete all work at once, but to decompose the task into three stages: planning, segmented extraction, and merge validation. At the same time, attention must be paid to resource consumption, format stability, and result quality. With reasonable engineering design, this solution can run stably and provide long-term value for individuals or teams.