Skip to content
Thoughts on creatin...
 
Notifications
Clear all

Thoughts on creating a shared repo for test scripts and configs?

2 Posts
2 Users
0 Reactions
4 Views
(@llm_eval_curious_42)
Estimable Member
Joined: 4 months ago
Posts: 57
Topic starter   [#2553]

Having spent considerable time evaluating various large language models, both proprietary and open-source, across coding, RAG, and general reasoning tasks, I've noticed a significant inefficiency in our community's workflow. Each of us, when conducting benchmarks or systematic tests, inevitably ends up crafting a bespoke collection of scripts, environment configurations, and prompt templates. This leads to duplicated effort and, more critically, makes direct comparison of results across different researchers' findings difficult due to inconsistencies in methodology.

I propose we establish a shared repository dedicated to standardized evaluation scripts and configurations. This would serve as a central hub for reproducible LLM testing. The primary benefits I foresee are:

* **Methodological Consistency:** A canonical set of test harnesses for common tasks (e.g., HumanEval for code, a standardized RAG triplet test, MMLU prompt templates) would allow us to compare "apples to apples." Did Model A truly outperform Model B, or was it a difference in temperature settings, few-shot examples, or post-processing logic?
* **Reduced Overhead:** New members or those exploring a new model category could clone the repo and immediately run a battery of established tests, rather than spending days assembling their own tooling.
* **Collaborative Improvement:** The community could iteratively improve the test suites, add new benchmarks, and fix bugs in evaluation logic collectively. This is far more efficient than siloed efforts.

A potential structure for such a repository could be:

```bash
shared-llm-eval/
├── configs/
│ ├── coding/
│ │ ├── humaneval.yaml # Contains exact prompt template, stop sequences, temperature
│ │ └── mbpp.yaml
│ ├── knowledge/
│ │ ├── mmlu.yaml
│ │ └── hellaswag.yaml
│ └── rag/
│ ├── test_retrieval.yaml # Config for chunk size, overlap, retrieval k
│ └── test_generation.yaml
├── scripts/
│ ├── run_eval.py # Generic runner that takes a model API/config and a task config
│ ├── score_coding.py # Specific scoring logic for pass@k
│ └── score_rag.py # Scoring for answer relevance, faithfulness
└── results/
└── templates/
└── results_template.json # Standardized output format for easy aggregation
```

The key challenge would be designing the harness to be model-agnostic. It would need to abstract the API calls for OpenAI, Anthropic, together.ai, and local models (via LMStudio or Ollama). A lightweight adapter pattern could work:

```python
# Example adapter concept
class ModelAdapter:
def generate(self, prompt, config):
pass

class OpenAIModelAdapter(ModelAdapter):
def generate(self, prompt, config):
# Calls OpenAI API with config.temperature, config.max_tokens, etc.
return response

# The eval script would use the adapter, so the core logic never changes.
```

My questions to the community are:
* Is there sufficient interest to merit the initial effort in setting this up?
* What specific benchmarks or test types should be prioritized in the first iteration?
* How should we manage versioning and contributions? A simple GitHub repo with a clear CONTRIBUTING.md file might suffice initially.
* Are there existing open-source projects we should fork or collaborate with instead of starting from scratch?

The goal is not to enforce a single "correct" way to evaluate, but to provide a common foundation that makes our individual findings more credible, comparable, and buildable upon by others.


Prompt engineering is engineering


   
Quote
(@sarahj)
Active Member
Joined: 1 week ago
Posts: 4
 

Sounds like a huge time saver, honestly. But how do you handle different API formats? Like, if I'm testing a model from OpenAI vs Anthropic vs a local Ollama instance, the scripts would need totally different config sections, right?



   
ReplyQuote